mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-09 10:53:34 +08:00
chore: checkpoint hermes-generated ops skills
This commit is contained in:
Affaan Mustafa
@@ -5,5 +5,5 @@ This directory is reserved for skills distilled from Hermes session data, repeat
|
||||
Rules:
|
||||
- keep skills specific and evidence-backed
|
||||
- prefer reusable operational patterns over one-off tasks
|
||||
- mirror from `~/.hermes/skills/generated/` only after the pattern is stable
|
||||
- mirror from `$HERMES_HOME/skills/generated/` only after the pattern is stable
|
||||
- do not overwrite unrelated ECC skills
|
||||
|
||||
45
skills/hermes-generated/SKILL.md
Normal file
45
skills/hermes-generated/SKILL.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: hermes-generated
|
||||
description: Index skill for Hermes-generated workflow packs. Use when the task clearly belongs to a Hermes-derived operator pattern and you need to choose the right generated subskill before acting.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Hermes Generated
|
||||
|
||||
This skill is the entrypoint for the Hermes-generated skill bucket.
|
||||
|
||||
Use it when the user is operating in a Hermes-style workflow and the task appears to map to one of the generated operator packs in this directory.
|
||||
|
||||
## Purpose
|
||||
|
||||
- route the request to the right Hermes-generated subskill
|
||||
- avoid inventing a new workflow when a stable Hermes pattern already exists
|
||||
- keep Hermes-derived operational behavior discoverable in the public ECC surface
|
||||
|
||||
## Available Subskills
|
||||
|
||||
- `automation-audit-ops`
|
||||
- `content-crosspost-ops`
|
||||
- `ecc-tools-cost-audit`
|
||||
- `email-ops`
|
||||
- `finance-billing-ops`
|
||||
- `knowledge-ops`
|
||||
- `messages-ops`
|
||||
- `research-ops`
|
||||
- `terminal-ops`
|
||||
|
||||
## Routing Guidance
|
||||
|
||||
Choose the narrowest matching subskill first:
|
||||
|
||||
- content and distribution -> `content-crosspost-ops`
|
||||
- ECC Tools burn, PR recursion, quota bypass, or premium-model leakage -> `ecc-tools-cost-audit`
|
||||
- inbox, triage, cleanup, and email sequencing -> `email-ops`
|
||||
- billing, revenue, and payments -> `finance-billing-ops`
|
||||
- memory and prior-session recovery -> `knowledge-ops`
|
||||
- Telegram, chat, or messaging triage -> `messages-ops`
|
||||
- research and source-backed investigation -> `research-ops`
|
||||
- shell execution and terminal workflows -> `terminal-ops`
|
||||
- cron, overlap, or automation hygiene -> `automation-audit-ops`
|
||||
|
||||
If no generated subskill fits cleanly, fall back to the closest standard ECC skill instead of forcing a Hermes-specific pattern.
|
||||
88
skills/hermes-generated/automation-audit-ops/SKILL.md
Normal file
88
skills/hermes-generated/automation-audit-ops/SKILL.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: automation-audit-ops
|
||||
description: Evidence-first automation audit workflow for Hermes. Use when auditing cron jobs, tooling, connectors, auth wiring, MCP surfaces, local-system parity, or automation overlap before fixing or pruning anything.
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [generated, automation, cron, tooling, workflow, audit, verification, parity, auth, mcp]
|
||||
---
|
||||
|
||||
# Automation Audit Ops
|
||||
|
||||
Use this when the user asks what automations are live, which jobs are broken, where overlap exists, or what tooling and connectors Hermes is actually benefiting from right now.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these skills into the workflow when relevant:
|
||||
- `continuous-agent-loop` for multi-step audits that cross cron, tooling, and config surfaces
|
||||
- `agentic-engineering` for decomposing the audit into verifiable units with a clear done condition
|
||||
- `terminal-ops` when the audit turns into a concrete local fix or command run
|
||||
- `research-ops` when local inventory has to be compared against current docs, platform support, or missing-capability claims
|
||||
- `search-first` before inventing a new helper, wrapper, or inventory path
|
||||
- `eval-harness` mindset for exact failure signatures, proof paths, and post-fix verification
|
||||
|
||||
## When To Use
|
||||
|
||||
- user asks `what automations do i have set up?`
|
||||
- user asks to audit cron overlap, redundancy, broken jobs, or job coverage
|
||||
- user asks which tools, connectors, auth surfaces, MCP servers, or wrappers are actually live
|
||||
- user asks what is ported from another local agentic system, what is still missing, or what should be wired next
|
||||
- the task spans both local inventory and a small number of high-impact fixes
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Start from prepared evidence when it exists:
|
||||
- read the prepared failure summary, request patterns, docs scan, and skill-sync notes before opening raw logs
|
||||
- if the prepared failure summary says there is no dominant cluster, do not spray-read raw log bundles anyway
|
||||
2. Inventory the live local surface before theorizing:
|
||||
- for cron work, inspect `$HERMES_HOME/cron/jobs.json`, the latest relevant `$HERMES_HOME/cron/output/<job>/...` files, and matching `$HERMES_HOME/cron/delivery-state/*.json`
|
||||
- for tooling or connector parity, inspect live config, plugins, helper scripts, wrappers, auth files, and verification logs before claiming something is missing
|
||||
- when the user names another local system or repo, inspect that live source too before saying Hermes lacks or already has the capability
|
||||
3. Classify each finding by failure class:
|
||||
- active broken logic
|
||||
- auth or provider outage
|
||||
- stale error that has not rerun yet
|
||||
- MCP or schema-level infrastructure break
|
||||
- overlap or redundancy
|
||||
- missing or unported capability
|
||||
4. Classify each surfaced integration by live state:
|
||||
- configured
|
||||
- authenticated
|
||||
- recently verified
|
||||
- stale or broken
|
||||
- missing
|
||||
5. Answer inventory questions with proof, not memory:
|
||||
- group automations by surface such as cron, messaging, content, GitHub, research, billing, or health
|
||||
- include schedules, current status, and the proof path behind each claim
|
||||
- for parity audits, separate `already ported`, `available but not wired`, and `missing entirely`
|
||||
- for overlap audits, end with `keep`, `merge`, `cut`, or `fix next`, plus the evidence path behind each call
|
||||
6. Freeze audit scope before changing anything:
|
||||
- if the user asked for an inventory, audit table, comparison, or otherwise kept the task read-only, stay read-only until the user explicitly asks for fixes
|
||||
- collect evidence with config reads, logs, status files, and non-writing proving steps first
|
||||
- do not rewrite cron, config, wrappers, or auth surfaces just because a likely fix is visible
|
||||
7. Fix only the highest-impact proved issues:
|
||||
- keep the pass bounded to one to three changes
|
||||
- prefer durable config, instruction, or helper-script fixes over one-off replies
|
||||
- if the prepared evidence shows a failure happened before a later config change, record that as stale-runtime or stale-status risk instead of rewriting the config blindly
|
||||
8. Verify after any change:
|
||||
- rerun the smallest proving step
|
||||
- regenerate any affected context artifacts
|
||||
- record exact remaining risks when runtime state is outside the scope of the current pass
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not treat `last_status=error` as proof of a current bug if the job has not rerun since recovery
|
||||
- do not conflate a provider outage or MCP schema error with job-specific prompt logic
|
||||
- do not claim a tool or connector is live just because a skill references it
|
||||
- do not treat `present in config` as the same thing as `authenticated` or `recently verified`
|
||||
- do not say Hermes is missing a capability before comparing the named local system or repo the user pointed at
|
||||
- do not answer `what automations do i have set up?` from memory without reading the current local inventory
|
||||
- do not open broad raw log bundles when the prepared summary already says there is no dominant cluster
|
||||
- do not turn an audit-only inventory pass into config or cron edits unless the user expands scope
|
||||
- do not fix low-value redundancy before resolving the concrete broken path the user actually asked about
|
||||
|
||||
## Verification
|
||||
|
||||
- each important claim points to a live file, log, config entry, or exact failure signature
|
||||
- each surfaced integration is labeled `configured`, `authenticated`, `recently verified`, `stale/broken`, or `missing`
|
||||
- each fix names the proving command, regenerated artifact, or re-read output that confirmed it
|
||||
- remaining risks clearly distinguish stale status, runtime drift, and unresolved infrastructure blockers
|
||||
@@ -31,8 +31,8 @@ Pull these imported skills into the workflow when relevant:
|
||||
## Support Source Of Truth
|
||||
|
||||
Treat these live sources as authoritative for destination support:
|
||||
- `/Users/affoon/.hermes/workspace/content/postbridge_publish.py`
|
||||
- `/Users/affoon/.hermes/workspace/content/crosspost-verification-latest.md`
|
||||
- `$HERMES_WORKSPACE/content/postbridge_publish.py`
|
||||
- `$HERMES_WORKSPACE/content/crosspost-verification-latest.md`
|
||||
|
||||
Examples in this skill are destination patterns, not a promise that every destination is live right now. If a destination has no current wrapper path or no recent verified publish record, report `unverified capability` or `blocked by unsupported capability` until checked.
|
||||
|
||||
@@ -52,12 +52,13 @@ Do not flatten these into one label. `PostBridge unsupported` can still mean `br
|
||||
- if the user pasted thread requirements, comply with those requirements before drafting
|
||||
2. If the request depends on platform capability, API support, or quota behavior, verify it before answering.
|
||||
- if the user asks whether PostBridge can handle a destination or format, inspect the real wrapper, configs, or recent publish logs before promising support
|
||||
- treat `/Users/affoon/.hermes/workspace/content/postbridge_publish.py` plus recent verification records as the source of truth for current support
|
||||
- treat `$HERMES_WORKSPACE/content/postbridge_publish.py` plus recent verification records as the source of truth for current support
|
||||
- separate the destination question from the transport question, and answer both
|
||||
- if there is no current wrapper path or recent proof, report `unverified capability` before drafting
|
||||
- if PostBridge is unsupported but a browser path exists, say `PostBridge unsupported, browser path available` instead of flattening the whole destination to `unsupported`
|
||||
- if the destination itself is unsupported, say `blocked by unsupported capability` and give the next viable path
|
||||
- if the task started as a support question or `did you do it?`, settle that capability or verification answer before drafting or scheduling other destinations
|
||||
- if a budget warning is active or there are 3 or fewer tool turns left, stop expanding capability checks, answer from the current wrapper or verification proof first, then use at most one high-confidence proving step
|
||||
3. Extract one core idea and a few specifics. Split multiple ideas into separate posts.
|
||||
4. Write native variants instead of reusing the same copy:
|
||||
- X: fast hook, minimal framing
|
||||
@@ -86,9 +87,10 @@ Do not flatten these into one label. `PostBridge unsupported` can still mean `br
|
||||
- capture a returned post ID, URL, API response, or an updated verification log
|
||||
- when the user asks `did you do it?`, answer with the exact status for each platform: posted, queued, drafted, uploaded-only, blocked, or awaiting verification
|
||||
- when the user interrupts with `are you working?`, answer in one sentence with the exact current step or blocker on the explicitly asked destination before more tool use
|
||||
- if a budget warning is already active, do not make another exploratory call before replying to `did you do it?` or `are you working?`
|
||||
- lead with the explicitly asked destination first, and include the proof or blocker on that destination before mentioning any secondary platform work
|
||||
- if the asked destination is still unresolved, say that first instead of leading with successful side work on other platforms
|
||||
- record every attempt with `/Users/affoon/.hermes/workspace/content/log_crosspost.py` or `/Users/affoon/.hermes/workspace/content/postbridge_publish.py`
|
||||
- record every attempt with `$HERMES_WORKSPACE/content/log_crosspost.py` or `$HERMES_WORKSPACE/content/postbridge_publish.py`
|
||||
- if the state is only drafted, uploaded-only, queued, blocked, or pending manual action, report that exact status
|
||||
|
||||
## Pitfalls
|
||||
@@ -105,10 +107,11 @@ Do not flatten these into one label. `PostBridge unsupported` can still mean `br
|
||||
- do not hide an unresolved asked destination behind progress on other supported destinations
|
||||
- do not answer `did you do it?` by leading with successful secondary platforms while the explicitly asked destination is still unresolved
|
||||
- do not keep scheduling or verifying secondary destinations after a status interrupt while the explicitly asked destination is still unresolved
|
||||
- do not keep expanding capability checks after a budget warning when the current wrapper state or verification log already supports a precise status answer
|
||||
- do not ignore the user's preference for screenshots or native media over raw links
|
||||
|
||||
## Verification
|
||||
|
||||
- `/Users/affoon/.hermes/workspace/content/crosspost-verification-latest.md` reflects the latest attempts
|
||||
- `$HERMES_WORKSPACE/content/crosspost-verification-latest.md` reflects the latest attempts
|
||||
- each destination has an ID, URL, or explicit failure reason
|
||||
- the copy and media logged match what was actually sent
|
||||
|
||||
104
skills/hermes-generated/ecc-tools-cost-audit/SKILL.md
Normal file
104
skills/hermes-generated/ecc-tools-cost-audit/SKILL.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: ecc-tools-cost-audit
|
||||
description: Evidence-first ECC Tools burn and billing audit workflow. Use when investigating runaway PR creation, quota bypass, premium-model leakage, or GitHub App cost spikes in the ECC Tools repo.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# ECC Tools Cost Audit
|
||||
|
||||
Use this when the user suspects the ECC Tools GitHub App is burning cost, over-creating PRs, bypassing usage limits, or routing free users into premium analysis paths.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these imported skills into the workflow when relevant:
|
||||
- `continuous-agent-loop` for scope freezes, recovery gates, and cost-aware tracing when audits are long or failure signatures repeat
|
||||
- `terminal-ops` for repo-local inspection, narrow edits, and proving commands
|
||||
- `finance-billing-ops` when customer-impact math has to be separated from repo behavior
|
||||
- `agentic-engineering` for tracing entrypoints, queue paths, and fix sequencing
|
||||
- `plankton-code-quality` for safer code changes and rerun behavior
|
||||
- `eval-harness` mindset for exact root-cause evidence and post-fix verification
|
||||
- `search-first` before inventing a new helper or abstraction
|
||||
- `security-review` when auth, secrets, usage gates, or entitlement paths are touched
|
||||
|
||||
## When To Use
|
||||
|
||||
- user says ECC Tools burn rate, PR recursion, over-created PRs, usage-limit bypass, or expensive model routing
|
||||
- the task is an audit or fix in `$PRIMARY_REPOS_ROOT/ECC/skill-creator-app`
|
||||
- the answer depends on webhook handlers, queue workers, usage reservation, PR creation logic, or paid-gate enforcement
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Freeze repo scope first:
|
||||
- use `$PRIMARY_REPOS_ROOT/ECC/skill-creator-app`
|
||||
- check branch and local diff before changing anything
|
||||
2. Freeze audit mode before tracing:
|
||||
- if the user asked for `report only`, `audit only`, `review only`, or explicitly said `do not modify code`, keep the pass read-only until the user changes scope
|
||||
- gather evidence with reads, searches, git status/diff, and other non-writing proving commands first
|
||||
- do not patch `src/index.ts`, run generators, install dependencies, or stage changes during an audit-only pass
|
||||
3. Trace ingress before suggesting fixes:
|
||||
- inspect webhook entrypoints in `src/index.ts`
|
||||
- search every `ANALYSIS_QUEUE.send(...)` or equivalent enqueue
|
||||
- map which triggers share a job type
|
||||
4. Trace the queue consumer and its side effects:
|
||||
- inspect `handleAnalysisQueue(...)` or the equivalent worker
|
||||
- confirm whether queued analysis always ends in PR creation, file writes, or premium model calls
|
||||
5. Audit PR multiplication:
|
||||
- inspect PR helpers and branch naming
|
||||
- check dedupe, branch skip logic, synchronize-event handling, and reuse of existing PRs
|
||||
- treat app-generated branches such as `ecc-tools/*` or timestamped branches as red-flag evidence paths
|
||||
6. Audit usage and billing truth:
|
||||
- inspect rate-limit check and increment paths
|
||||
- if quota is checked before enqueue but incremented only in the worker, mark it as a real race
|
||||
- separate overrun risk, customer billing impact, and entitlement truth
|
||||
7. Audit model routing:
|
||||
- inspect analyzer `fastMode` or equivalent flags, free-vs-paid tier branching, and actual provider/model calls
|
||||
- confirm whether free queued work can still hit Anthropic or another premium path when keys exist
|
||||
8. Audit rerun safety and file updates:
|
||||
- inspect file update helpers for existing-file `sha` handling or equivalent optimistic concurrency
|
||||
- if reruns can spend analysis cost and then fail on PR or file creation, mark it as burn-with-broken-output
|
||||
9. Fix in priority order only if the user asked for code changes:
|
||||
- stop automatic PR multiplication first
|
||||
- stop quota bypass second
|
||||
- stop premium leakage third
|
||||
- then close rerun/update safety gaps and missing entitlement gates
|
||||
10. Answer status interrupts before more tracing:
|
||||
- if the user asks `did you do it?`, `are you working?`, or the session is near the tool budget, reply from the current verified repo state before more searching
|
||||
- lead with whether root causes are `found`, fixes are `changed locally`, `verified locally`, `pushed`, or still `blocked`
|
||||
- if the asked burn path is still unresolved, say that before side findings or lower-priority issues
|
||||
11. Verify with the smallest proving commands:
|
||||
- rerun only the focused tests or typecheck that cover changed paths
|
||||
- report `changed locally`, `verified locally`, `pushed`, `deployed`, or `blocked` exactly
|
||||
|
||||
## High-Signal Failure Patterns
|
||||
|
||||
### 1. One queue type for all triggers
|
||||
If pushes, PR syncs, and manual audits all enqueue the same analyze job and the worker always calls the PR-creation path, analysis equals PR spam.
|
||||
|
||||
### 2. Post-enqueue usage increment
|
||||
If usage is reserved only inside the worker, concurrent requests can all pass the front-door check and exceed quotas.
|
||||
|
||||
### 3. Free tier on premium model path
|
||||
If free queued jobs still set `fastMode: false` or equivalent while premium provider keys exist, free users can burn premium spend.
|
||||
|
||||
### 4. App-generated branches re-entering the webhook
|
||||
If `pull_request.synchronize` or similar runs on `ecc-tools/*` branches, the app can analyze its own output and recurse.
|
||||
|
||||
### 5. Update-without-sha reruns
|
||||
If generated files are updated without passing the existing file `sha`, reruns can fail after the expensive work already happened.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not start with broad repo wandering, settle webhook -> queue -> worker path first
|
||||
- do not mix customer billing inference with code-backed product truth
|
||||
- do not mutate the repo during an audit-only or `do not modify code` pass
|
||||
- do not claim burn is fixed until the narrow proving command was rerun
|
||||
- do not push or deploy unless the user asked
|
||||
- do not ignore existing local changes in the repo, work around them or stop if they conflict
|
||||
- do not keep tracing lower-priority repo paths after a budget warning or status interrupt when the main root-cause state is already known
|
||||
|
||||
## Verification
|
||||
|
||||
- root causes cite exact file paths and code areas
|
||||
- fixes are ordered by burn impact, not code neatness
|
||||
- proving commands are named
|
||||
- final status distinguishes local change, verification, push, and deployment
|
||||
@@ -43,17 +43,17 @@ Pull these companion skills into the workflow when relevant:
|
||||
- read the full thread first
|
||||
- choose the sender account that matches the project or recipient
|
||||
- if the user has not explicitly approved the exact outgoing text, draft first and show the final copy before sending
|
||||
- store approval state with `python3 /Users/affoon/.hermes/scripts/email_guard.py queue ...`
|
||||
- before any send, require `python3 /Users/affoon/.hermes/scripts/email_guard.py approve --id <id>` plus `python3 /Users/affoon/.hermes/scripts/email_guard.py can-send --id <id> --account <account> --recipient <recipient> --subject <subject>`
|
||||
- before any send or reply, run `python3 /Users/affoon/.hermes/scripts/email_guard.py history --recipient <recipient> --subject <subject snippet> --days 45 --json` to catch prior outbound and accidental repeats
|
||||
- store approval state with `python3 $HERMES_HOME/scripts/email_guard.py queue ...`
|
||||
- before any send, require `python3 $HERMES_HOME/scripts/email_guard.py approve --id <id>` plus `python3 $HERMES_HOME/scripts/email_guard.py can-send --id <id> --account <account> --recipient <recipient> --subject <subject>`
|
||||
- before any send or reply, run `python3 $HERMES_HOME/scripts/email_guard.py history --recipient <recipient> --subject <subject snippet> --days 45 --json` to catch prior outbound and accidental repeats
|
||||
- if the exact Himalaya send syntax is uncertain, check `himalaya ... --help` or a checked-in helper path before trying a new subcommand
|
||||
- compose with `himalaya template send` or `himalaya message send` using file-backed content when possible, not ad hoc heredoc or inline Python raw-MIME wrappers
|
||||
- avoid editor-driven flows unless required
|
||||
5. If the request mentions attachments or images:
|
||||
- resolve the exact absolute file path before broad mailbox searching
|
||||
- keep the task on the local send-and-verify path instead of branching into unrelated web or repo exploration
|
||||
- if Mail.app fallback is needed, pass the attachment paths after the body: `osascript /Users/affoon/.hermes/scripts/send_mail.applescript "<sender>" "<recipient>" "<subject>" "<body>" "/absolute/file1" ...`
|
||||
6. If the user wants an actual send and Himalaya fails with an IMAP append or save-copy error, a CLI dead end, or a raw-message parser crash, do not immediately resend. First verify whether the message already landed in Sent using the history check or `himalaya envelope list -a <account> -f Sent ...`. If the failure was an invalid command path or a panic before Sent proof exists, report the exact blocked state such as `blocked on invalid himalaya send path` or `blocked on himalaya parser crash` and preserve the draft. Only if there is still no sent copy and the user explicitly approved the send may you fall back to `/Users/affoon/.hermes/scripts/send_mail.applescript`. If the user constrained the method to Himalaya only, report the exact blocked state instead of silently switching tools.
|
||||
- if Mail.app fallback is needed, pass the attachment paths after the body: `osascript $HERMES_HOME/scripts/send_mail.applescript "<sender>" "<recipient>" "<subject>" "<body>" "/absolute/file1" ...`
|
||||
6. If the user wants an actual send and Himalaya fails with an IMAP append or save-copy error, a CLI dead end, or a raw-message parser crash, do not immediately resend. First verify whether the message already landed in Sent using the history check or `himalaya envelope list -a <account> -f Sent ...`. If the failure was an invalid command path or a panic before Sent proof exists, report the exact blocked state such as `blocked on invalid himalaya send path` or `blocked on himalaya parser crash` and preserve the draft. Only if there is still no sent copy and the user explicitly approved the send may you fall back to `$HERMES_HOME/scripts/send_mail.applescript`. If the user constrained the method to Himalaya only, report the exact blocked state instead of silently switching tools.
|
||||
7. During long-running mailbox work, keep the loop tight: draft -> approval -> send -> Sent proof. Do the next irreversible step first, and do not branch into unrelated transports or searches while the current blocker is unresolved. If a budget warning says 3 or fewer tool calls remain, stop broad exploration and spend the remaining calls on the highest-confidence execution or verification step, or report exact status and next action.
|
||||
8. If the user wants sent-mail evidence:
|
||||
- verify via `himalaya envelope list -a <account> -f Sent ...` or the account's actual sent folder
|
||||
|
||||
@@ -29,7 +29,7 @@ Pull these imported skills into the workflow when relevant:
|
||||
|
||||
1. Start with the freshest revenue evidence available:
|
||||
- if a live Stripe pull exists, refresh it first
|
||||
- otherwise read `/Users/affoon/.hermes/workspace/business/stripe-sales.md` and `/Users/affoon/.hermes/workspace/business/financial-status.md`
|
||||
- otherwise read `$HERMES_WORKSPACE/business/stripe-sales.md` and `$HERMES_WORKSPACE/business/financial-status.md`
|
||||
- always report the snapshot timestamp if the data is not live
|
||||
2. Normalize the revenue picture before answering:
|
||||
- separate paid sales, failed attempts, successful retries, `$0` invoices, refunds, disputes, and active subscriptions
|
||||
|
||||
@@ -31,12 +31,12 @@ Pull these companion skills into the workflow when relevant:
|
||||
- do not waste turns re-reading the same files unless the summary is clearly insufficient
|
||||
2. Search in a fixed order before saying `not found`, unless the user already named the store:
|
||||
- `mcp_supermemory_recall` with a targeted query
|
||||
- grep `/Users/affoon/.hermes/workspace/memory/`
|
||||
- grep `/Users/affoon/.hermes/workspace/` more broadly
|
||||
- grep `$HERMES_WORKSPACE/memory/`
|
||||
- grep `$HERMES_WORKSPACE/` more broadly
|
||||
- `session_search` for recent Hermes conversations
|
||||
- grep `/Users/affoon/GitHub/affaans_knowledge_base/` and `/Users/affoon/.hermes/openclaw-home/hub/workspace/memory/` for historical context
|
||||
- grep `$KNOWLEDGE_BASE_ROOT/` and `$OPENCLAW_MEMORY_ROOT/` for historical context
|
||||
3. If the user says the answer is in a specific memory store, pivot there immediately after the initial targeted recall:
|
||||
- `openclaw memory` means favor `/Users/affoon/GitHub/affaans_knowledge_base/` and `/Users/affoon/.hermes/openclaw-home/hub/workspace/memory/`
|
||||
- `openclaw memory` means favor `$KNOWLEDGE_BASE_ROOT/` and `$OPENCLAW_MEMORY_ROOT/`
|
||||
- `not in this session` means stop digging through the current thread and move to persistent stores instead of re-reading current-session files
|
||||
4. Keep the search narrow and evidence-led:
|
||||
- reuse names, dates, channels, account names, or quoted phrases from the user
|
||||
|
||||
68
skills/hermes-generated/messages-ops/SKILL.md
Normal file
68
skills/hermes-generated/messages-ops/SKILL.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
name: messages-ops
|
||||
description: Evidence-first live messaging workflow for Hermes. Use when reading iMessage threads, checking X DMs, pulling recent local MFA codes, or proving which thread or message was actually reviewed.
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [generated, messages, imessage, dm, mfa, workflow, verification]
|
||||
---
|
||||
|
||||
# Messages Ops
|
||||
|
||||
Use this when the user wants Hermes to read texts or DMs, recover a recent one-time code, inspect a live thread before replying, or prove which message source was checked.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these imported skills into the workflow when relevant:
|
||||
- `continuous-agent-loop` when the task spans source resolution, retrieval, and a follow-up draft or action
|
||||
- `continuous-learning-v2` when the live message task turns into a cross-session memory or pattern-capture issue
|
||||
- `search-first` before inventing a new message lookup path or raw database query
|
||||
- `eval-harness` mindset for exact source attribution and blocked-state reporting
|
||||
|
||||
## When To Use
|
||||
|
||||
- user says `read my messages`, `check texts`, `look in iMessage`, `check DMs`, or similar
|
||||
- the task depends on a live local Messages thread, an X DM thread, or a recent code delivered to Messages
|
||||
- the user asks whether Hermes already checked a specific thread, sender, or service
|
||||
- the prompt mixes live message retrieval with a likely handoff into `email-ops` or `knowledge-ops`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Resolve the source first:
|
||||
- iMessage thread
|
||||
- recent local code in Messages
|
||||
- X DM or another browser-gated message source
|
||||
- email or persistent memory handoff
|
||||
2. For iMessage threads:
|
||||
- use `imsg chats` when the chat id is unclear
|
||||
- use `imsg history --chat-id <ID> --limit <N>` for the actual read
|
||||
- known chat ids can save turns when they match the ask, for example Alejandro=`458` and Haley/Henry=`364`
|
||||
3. For recent one-time codes from local Messages:
|
||||
- use `python3 $HERMES_HOME/scripts/messages_recent_codes.py --limit 8 --minutes 20`
|
||||
- add `--query <service>` when the sender or brand is known
|
||||
- do not jump to ad hoc `sqlite3`, `python3 -c`, or other inline database reads before the helper path is tried
|
||||
- if one focused resend plus one fresh helper check still shows no match, report `blocked on missing MFA code` and stop
|
||||
4. For X DMs or other browser-gated message sources:
|
||||
- use the logged-in browser path first
|
||||
- verify the active account before reading or drafting
|
||||
- if auth or MFA blocks access, do the focused code-check path once, then report the exact blocker instead of wandering into side work
|
||||
5. Hand off cleanly when the task is really another workflow:
|
||||
- use `email-ops` when the dominant task is mailbox triage, folder moves, replies, or Sent proof
|
||||
- use `knowledge-ops` when the user says `openclaw memory`, `not in this session`, or the prompt already provides loaded context plus a memory-retrieval hint
|
||||
6. Report exact evidence:
|
||||
- name the source tool and thread or chat id when possible
|
||||
- include sender, service, timestamp window, or blocker
|
||||
- use exact status words such as `read`, `drafted`, `blocked`, or `awaiting verification`
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not say `I can't retrieve` when `imsg`, the browser session, or the checked helper script can settle the question
|
||||
- do not confuse live message retrieval with mailbox work, hand off to `email-ops` when email is the real surface
|
||||
- do not burn turns on raw database one-liners before the checked helper path for local codes
|
||||
- do not keep re-reading the current session after the user already pointed to OpenClaw or another persistent store
|
||||
- do not claim a thread was checked without naming the source tool, thread, or service behind the claim
|
||||
|
||||
## Verification
|
||||
|
||||
- the response names the source store or tool used
|
||||
- the response includes a thread id, sender, service, or explicit blocker
|
||||
- MFA/code checks end with either a concrete match or the exact blocked status
|
||||
80
skills/hermes-generated/subscription-audit-ops/SKILL.md
Normal file
80
skills/hermes-generated/subscription-audit-ops/SKILL.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
name: subscription-audit-ops
|
||||
description: Evidence-first recurring-charge and subscription audit workflow for Hermes. Use when auditing personal spend across cards, recurring merchants, and cancellation candidates under time or cash pressure.
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [generated, finance, subscriptions, recurring-charges, credit-karma, email, verification]
|
||||
---
|
||||
|
||||
# Subscription Audit Ops
|
||||
|
||||
Use this when the user asks to audit subscriptions, recurring charges, monthly software spend, or cancellation candidates across personal cards and accounts.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these imported skills into the workflow when relevant:
|
||||
- `continuous-agent-loop` for bounded multi-step audits with explicit stop conditions when proof is partial
|
||||
- `agentic-engineering` for exact done conditions and the one-to-three-change scope discipline
|
||||
- `market-research` when the user wants vendor or plan comparisons before canceling
|
||||
- `deep-research` and `exa-search` when outside pricing, cancellation flows, or market alternatives need current verification
|
||||
- `search-first` before inventing a custom scraper, parser, or finance helper
|
||||
- `eval-harness` mindset for proof tiers, timestamps, and exact confidence labels
|
||||
|
||||
## When To Use
|
||||
|
||||
- user says `audit my subscriptions`, `what can i cancel`, `find recurring charges`, or similar
|
||||
- the user wants a ruthless keep/cancel pass before a move, budget cut, or runway review
|
||||
- direct card exports are missing and you need to assemble evidence from multiple partial sources
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Start with the freshest finance snapshot available:
|
||||
- read `/Users/affoon/.hermes/workspace/business/financial-status.md`
|
||||
- use it as the source of truth for last verified recurring-charge evidence, card balances, and snapshot timestamp
|
||||
- if it references Credit Karma or other live sources, preserve the exact timestamp in the final answer
|
||||
2. If live Credit Karma is accessible, use browser tools to confirm:
|
||||
- net worth page for balances and recent transactions
|
||||
- manage accounts page for linked institutions and account names
|
||||
- use `browser_vision` on screenshots when the DOM/snapshot truncates or hides account details
|
||||
- distinguish `visible recurring charge`, `recent transaction`, and `linked account` clearly
|
||||
3. If direct transaction exports are unavailable, use fallback evidence layers:
|
||||
- search prior session logs for saved Credit Karma findings and merchant names
|
||||
- inspect known finance files in workspace and memory for previous subscription analyses
|
||||
- use email search for billing/receipt subjects only if it is likely to surface merchant proof
|
||||
- use a passwords export only as account-existence evidence, never as billing proof
|
||||
4. Classify findings into proof tiers:
|
||||
- tier 1: live transaction or current finance snapshot with amount/date
|
||||
- tier 2: prior saved note with explicit price and service
|
||||
- tier 3: account-existence evidence only, needs billing verification
|
||||
5. Build the recommendation set:
|
||||
- `cancel now` for low-value tools with explicit prior cost evidence or obvious move-related services
|
||||
- `verify this week` for plausible subscriptions without live billing proof
|
||||
- `keep for now` for core infra or tools still likely in active use
|
||||
- call out the biggest unresolved swing item, usually the highest-cost ambiguous plan
|
||||
6. Report exact confidence:
|
||||
- say `first-pass audit` if the evidence is partial
|
||||
- never pretend you have a complete ledger unless you saw a full recurring-charge screen or statement export
|
||||
- separate `billing proof`, `account evidence`, and `inference`
|
||||
|
||||
## Heuristics That Worked
|
||||
|
||||
- `financial-status.md` may contain the freshest recurring-charge evidence even when live browser access later fails
|
||||
- prior Apple Notes / knowledge-base subscription analyses are useful for cost baselines, but they are not live proof
|
||||
- Credit Karma `Manage accounts` can expose linked institutions even when transaction detail is sparse
|
||||
- passwords export is good for finding likely paid surfaces like gym, utilities, hosting, SaaS, and media, but should never be used to claim a subscription is active
|
||||
- move-related audits should explicitly check internet, gym, phone, and location-bound services first
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not claim `every single subscription` unless you have a current recurring-charge list or statement export
|
||||
- do not turn passwords-export hits into confirmed charges
|
||||
- do not mix `recent transaction` with `recurring subscription`
|
||||
- do not hide stale timestamps
|
||||
- do not miss the biggest swing item just because it is ambiguous, flag it as the top verification priority
|
||||
|
||||
## Verification
|
||||
|
||||
- answer includes the freshest verified finance timestamp
|
||||
- each recommendation is labeled by evidence strength
|
||||
- final output separates `cancel now`, `verify this week`, and `keep for now`
|
||||
- if coverage is partial, the answer explicitly says so and names the fastest path to full certainty
|
||||
@@ -31,34 +31,44 @@ Pull these imported skills into the workflow when relevant:
|
||||
1. Resolve the exact working surface first:
|
||||
- use the user-provided absolute repo path when given
|
||||
- if the target is not a git repo, do not reach for git-only steps
|
||||
- prefer `/Users/affoon/GitHub/...` over any iCloud or Documents mirror
|
||||
- prefer `$PRIMARY_REPOS_ROOT/...` over any iCloud or Documents mirror
|
||||
2. Inspect before editing:
|
||||
- read the failing command, file, test, or CI error first
|
||||
- check current branch and local state before changing or pushing anything
|
||||
- if the prompt already includes loaded-file markers or a compaction summary, use that evidence instead of re-reading blindly
|
||||
3. Keep fixes narrow and evidence-led:
|
||||
3. Freeze execution mode before editing:
|
||||
- if the user asked for an audit, review, inspection, or explicitly said `do not modify code`, stay read-only until the user changes scope
|
||||
- use logs, diffs, git state, file reads, and other non-writing proving steps to gather evidence
|
||||
- do not apply patches, run codegen, install dependencies, format files, or stage/commit while the task is still read-only
|
||||
4. Keep fixes narrow and evidence-led:
|
||||
- solve one dominant failure at a time
|
||||
- prefer repo-local scripts, package scripts, and checked-in helpers over ad hoc one-liners
|
||||
- if a dependency or helper is needed, use `search-first` before writing custom glue
|
||||
4. Verify after each meaningful change:
|
||||
5. Verify after each meaningful change:
|
||||
- rerun the smallest command that proves the fix
|
||||
- escalate to the broader build, lint, or test only after the local failure is addressed
|
||||
- if the same proving command keeps failing with the same signature, freeze the broader loop, reduce scope to the failing unit, and stop repeating the same retry
|
||||
- review the diff before any commit or push
|
||||
5. Push only when the requested state is real:
|
||||
6. Answer status interrupts before more terminal work:
|
||||
- if the user asks `are you working?`, `did you do it?`, or a low-budget warning appears, stop discovery and answer from the current verified state before running more commands
|
||||
- lead with the explicitly asked repo, branch, or failure state first, especially when the main fix is still unresolved
|
||||
- use exact words like `changed locally`, `verified locally`, `pushed`, `blocked`, or `awaiting verification`
|
||||
7. Push only when the requested state is real:
|
||||
- distinguish `changed locally`, `verified locally`, `committed`, and `pushed`
|
||||
- if push is requested, use a non-interactive git flow and report the branch and result
|
||||
6. Report exact status words:
|
||||
8. Report exact status words:
|
||||
- drafted, changed locally, verified locally, committed, pushed, blocked, awaiting verification
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not guess the failure from memory when logs or tests can settle it
|
||||
- do not work in `/Users/affoon/Documents/...` clones when `/Users/affoon/GitHub/...` exists
|
||||
- do not turn an audit-only, review-only, or `do not modify code` request into edits because a fix seems obvious
|
||||
- do not work in `$DOCUMENTS_ROOT/...` clones when `$PRIMARY_REPOS_ROOT/...` exists
|
||||
- do not use destructive git commands or revert unrelated local work
|
||||
- do not claim `fixed` if the proving command was not rerun
|
||||
- do not claim `pushed` if the change only exists locally
|
||||
- do not keep rerunning broad verification after the same unchanged failure, narrow the loop or report the blocker
|
||||
- do not keep exploring after a budget warning or status interrupt when the current repo state can already be reported precisely
|
||||
|
||||
## Verification
|
||||
|
||||
|
||||
Reference in New Issue
Block a user