From 19755f6c52c84b2a282a42692e76389bac699927 Mon Sep 17 00:00:00 2001 From: Affaan Mustafa Date: Wed, 25 Mar 2026 02:41:08 -0700 Subject: [PATCH] feat: add hermes-generated ops skills --- .claude-plugin/marketplace.json | 2 +- scripts/codex/check-codex-global-state.sh | 25 +++++- scripts/sync-ecc-to-codex.sh | 23 +++++- skills/hermes-generated/README.md | 9 +++ .../content-crosspost-ops/SKILL.md | 80 +++++++++++++++++++ skills/hermes-generated/email-ops/SKILL.md | 70 ++++++++++++++++ .../finance-billing-ops/SKILL.md | 71 ++++++++++++++++ .../hermes-generated/knowledge-ops/SKILL.md | 57 +++++++++++++ skills/hermes-generated/research-ops/SKILL.md | 64 +++++++++++++++ skills/hermes-generated/terminal-ops/SKILL.md | 64 +++++++++++++++ 10 files changed, 459 insertions(+), 6 deletions(-) create mode 100644 skills/hermes-generated/README.md create mode 100644 skills/hermes-generated/content-crosspost-ops/SKILL.md create mode 100644 skills/hermes-generated/email-ops/SKILL.md create mode 100644 skills/hermes-generated/finance-billing-ops/SKILL.md create mode 100644 skills/hermes-generated/knowledge-ops/SKILL.md create mode 100644 skills/hermes-generated/research-ops/SKILL.md create mode 100644 skills/hermes-generated/terminal-ops/SKILL.md diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 397d788b..0bfb0544 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -13,7 +13,7 @@ { "name": "everything-claude-code", "source": "./", - "description": "The most comprehensive Claude Code plugin — 14+ agents, 56+ skills, 33+ commands, and production-ready hooks for TDD, security scanning, code review, and continuous learning", + "description": "The most comprehensive Claude Code plugin — 28+ agents, 116+ skills, 57+ commands, and production-ready hooks for TDD, security scanning, code review, and continuous learning", "version": "1.9.0", "author": { "name": "Affaan Mustafa", diff --git a/scripts/codex/check-codex-global-state.sh b/scripts/codex/check-codex-global-state.sh index f0c2242c..35856c55 100644 --- a/scripts/codex/check-codex-global-state.sh +++ b/scripts/codex/check-codex-global-state.sh @@ -12,6 +12,7 @@ CONFIG_FILE="$CODEX_HOME/config.toml" AGENTS_FILE="$CODEX_HOME/AGENTS.md" PROMPTS_DIR="$CODEX_HOME/prompts" SKILLS_DIR="$CODEX_HOME/skills" +ROLE_DIR="$CODEX_HOME/agents" HOOKS_DIR_EXPECT="${ECC_GLOBAL_HOOKS_DIR:-$CODEX_HOME/git-hooks}" failures=0 @@ -89,12 +90,14 @@ fi if [[ -f "$CONFIG_FILE" ]]; then check_config_pattern '^multi_agent\s*=\s*true' "multi_agent is enabled" check_config_absent '^\s*collab\s*=' "deprecated collab flag is absent" - check_config_pattern '^persistent_instructions\s*=' "persistent_instructions is configured" + check_config_pattern '^profile\s*=\s*"full-access"' "default profile is full-access" + check_config_pattern '^\[profiles\.full-access\]' "profiles.full-access exists" check_config_pattern '^\[profiles\.strict\]' "profiles.strict exists" check_config_pattern '^\[profiles\.yolo\]' "profiles.yolo exists" for section in \ 'mcp_servers.github' \ + 'mcp_servers.exa' \ 'mcp_servers.memory' \ 'mcp_servers.sequential-thinking' \ 'mcp_servers.context7-mcp' @@ -152,6 +155,26 @@ else fail "Skills directory missing ($SKILLS_DIR)" fi +if [[ -d "$ROLE_DIR" ]]; then + missing_roles=0 + for role_file in explorer.toml reviewer.toml docs-researcher.toml; do + if [[ -f "$ROLE_DIR/$role_file" ]]; then + : + else + printf ' - missing agent role config: %s\n' "$role_file" + missing_roles=$((missing_roles + 1)) + fi + done + + if [[ "$missing_roles" -eq 0 ]]; then + ok "Global Codex agent role configs are present" + else + fail "$missing_roles required agent role configs are missing" + fi +else + fail "Agent role config directory missing ($ROLE_DIR)" +fi + if [[ -f "$PROMPTS_DIR/ecc-prompts-manifest.txt" ]]; then ok "Command prompts manifest exists" else diff --git a/scripts/sync-ecc-to-codex.sh b/scripts/sync-ecc-to-codex.sh index 90db5caa..073d5fcf 100644 --- a/scripts/sync-ecc-to-codex.sh +++ b/scripts/sync-ecc-to-codex.sh @@ -28,6 +28,8 @@ CONFIG_FILE="$CODEX_HOME/config.toml" AGENTS_FILE="$CODEX_HOME/AGENTS.md" AGENTS_ROOT_SRC="$REPO_ROOT/AGENTS.md" AGENTS_CODEX_SUPP_SRC="$REPO_ROOT/.codex/AGENTS.md" +ROLE_CONFIG_SRC="$REPO_ROOT/.codex/agents" +ROLE_CONFIG_DEST="$CODEX_HOME/agents" SKILLS_SRC="$REPO_ROOT/.agents/skills" SKILLS_DEST="$CODEX_HOME/skills" PROMPTS_SRC="$REPO_ROOT/commands" @@ -131,6 +133,7 @@ MCP_MERGE_SCRIPT="$REPO_ROOT/scripts/codex/merge-mcp-config.js" require_path "$REPO_ROOT/AGENTS.md" "ECC AGENTS.md" require_path "$AGENTS_CODEX_SUPP_SRC" "ECC Codex AGENTS supplement" +require_path "$ROLE_CONFIG_SRC" "ECC Codex agent config directory" require_path "$SKILLS_SRC" "ECC skills directory" require_path "$PROMPTS_SRC" "ECC commands directory" require_path "$HOOKS_INSTALLER" "ECC global git hooks installer" @@ -245,6 +248,17 @@ for skill_dir in "$SKILLS_SRC"/*; do skills_count=$((skills_count + 1)) done +log "Syncing ECC Codex agent role configs" +run_or_echo "mkdir -p \"$ROLE_CONFIG_DEST\"" +role_count=0 +for role_file in "$ROLE_CONFIG_SRC"/*.toml; do + [[ -f "$role_file" ]] || continue + role_name="$(basename "$role_file")" + dest="$ROLE_CONFIG_DEST/$role_name" + run_or_echo "cp \"$role_file\" \"$dest\"" + role_count=$((role_count + 1)) +done + log "Generating prompt files from ECC commands" run_or_echo "mkdir -p \"$PROMPTS_DEST\"" manifest="$PROMPTS_DEST/ecc-prompts-manifest.txt" @@ -470,21 +484,22 @@ fi log "Installing global git safety hooks" if [[ "$MODE" == "dry-run" ]]; then - "$HOOKS_INSTALLER" --dry-run + bash "$HOOKS_INSTALLER" --dry-run else - "$HOOKS_INSTALLER" + bash "$HOOKS_INSTALLER" fi log "Running global regression sanity check" if [[ "$MODE" == "dry-run" ]]; then - printf '[dry-run] %s\n' "$SANITY_CHECKER" + printf '[dry-run] bash %s\n' "$SANITY_CHECKER" else - "$SANITY_CHECKER" + bash "$SANITY_CHECKER" fi log "Sync complete" log "Backup saved at: $BACKUP_DIR" log "Skills synced: $skills_count" +log "Agent role configs synced: $role_count" log "Prompts generated: $((prompt_count + extension_count)) (commands: $prompt_count, extensions: $extension_count)" if [[ "$MODE" == "apply" ]]; then diff --git a/skills/hermes-generated/README.md b/skills/hermes-generated/README.md new file mode 100644 index 00000000..36f04ce4 --- /dev/null +++ b/skills/hermes-generated/README.md @@ -0,0 +1,9 @@ +# Hermes Generated Skills + +This directory is reserved for skills distilled from Hermes session data, repeated Telegram asks, and self-improvement runs. + +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 +- do not overwrite unrelated ECC skills diff --git a/skills/hermes-generated/content-crosspost-ops/SKILL.md b/skills/hermes-generated/content-crosspost-ops/SKILL.md new file mode 100644 index 00000000..426fd1df --- /dev/null +++ b/skills/hermes-generated/content-crosspost-ops/SKILL.md @@ -0,0 +1,80 @@ +--- +name: content-crosspost-ops +description: Evidence-first crossposting workflow for Hermes. Use when adapting posts, threads, demos, videos, or articles across LinkedIn, Threads, Bluesky, Farcaster, and YouTube Community while keeping per-platform copy distinct and verified. +metadata: + hermes: + tags: [generated, content, crosspost, workflow, verification] +--- + +# Content Crosspost Ops + +Use this when the user wants Hermes to crosspost or repurpose content across multiple platforms, especially from Telegram-driven publishing requests. + +## Skill Stack + +Pull these imported skills into the workflow when relevant: +- `content-engine` for platform-native rewrites +- `crosspost` for sequencing and destination-specific adaptation +- `article-writing` when the source asset is long-form +- `video-editing` or `fal-ai-media` when the post should lead with a clip, frame, or visual +- `search-first` before claiming a platform or API supports a format +- `eval-harness` mindset for publish verification and status reporting + +## When To Use + +- user says `crosspost`, `post everywhere`, `put this on linkedin too`, or similar +- the source asset is an X post/thread, quote tweet, article, demo video, screenshot, or YouTube post +- the destination is a community thread or showcase channel like Discord's `built-with-claude` +- the user asks whether a new destination or post type is supported + +## Workflow + +1. Read the real source asset and any destination rules first. Do not draft from memory. + - 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 + - if the destination is unsupported, say `blocked by unsupported capability` and give the next viable path +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 + - LinkedIn: strong first line, short paragraphs, explicit lesson or takeaway + - Threads, Bluesky, Farcaster: shorter, conversational, clearly distinct wording + - YouTube Community: lead with the result or takeaway, keep it media-friendly +5. Prefer native media when the user wants engagement: + - for quote tweets, articles, or external links, prefer screenshots or media over a bare outbound link when the platform rewards native assets + - if the user says the demo itself should lead, use the video or a frame from it instead of a generic screenshot + - for community showcase threads, prefer the strongest demo clip or screenshot pair the user explicitly pointed to +6. Use link placement intentionally: + - put external links in comments or replies when engagement is the goal and the platform supports it + - otherwise use a platform-native CTA such as `comment for link` only when it matches the user's instruction +7. Resolve account and auth blockers early for browser-only destinations: + - for Discord or other browser-only community shares, verify the active account and whether the destination is reachable before spending more turns on extra asset hunting or copy polish + - verify the active account before typing into a community or social composer + - if login is blocked by MFA or a missing verification code, use the checked-in helper path instead of ad hoc inline scripting and do at most one focused resend plus one fresh helper check + - if that still returns no matching code, stop and report `blocked on missing MFA code` +8. Execute in order: + - post the primary platform first + - stagger secondary destinations when requested, defaulting to 4 hours apart unless the user overrides it + - prefer PostBridge for supported platforms, browser flows only when required +9. Verify before claiming completion: + - 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 + - record every attempt with `/Users/affoon/.hermes/workspace/content/log_crosspost.py` or `/Users/affoon/.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 + +- do not post identical copy cross-platform +- do not assume platform support without checking +- do not ignore thread rules or platform-specific showcase requirements +- do not call a draft, composer state, or upload step `posted` +- do not keep searching unrelated systems after a login or MFA blocker is already the limiting step +- do not keep refining copy or looking for better assets once auth is the only blocker on a browser-only publish +- do not answer a support question with a guess when the wrapper, logs, or API response can settle it +- 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 +- each destination has an ID, URL, or explicit failure reason +- the copy and media logged match what was actually sent diff --git a/skills/hermes-generated/email-ops/SKILL.md b/skills/hermes-generated/email-ops/SKILL.md new file mode 100644 index 00000000..7a23d96b --- /dev/null +++ b/skills/hermes-generated/email-ops/SKILL.md @@ -0,0 +1,70 @@ +--- +name: email-ops +description: Evidence-first mailbox triage and sent-mail-safe reply workflow for Hermes. Use when organizing folders, drafting or sending through Himalaya, or verifying a message landed in Sent. +origin: Hermes +--- + +# Email Ops + +Use this when the user wants Hermes to clean a mailbox, move messages between folders, draft or send replies, or prove a message landed in Sent. + +## Prerequisites + +Before using this workflow: +- install and configure the Himalaya CLI for the target mailbox accounts +- confirm the account's Sent folder name if it differs from `Sent` + +## Skill Stack + +Pull these companion skills into the workflow when relevant: +- `investor-outreach` when the email is investor, partner, or sponsor facing +- `search-first` before assuming a mail API, folder name, or CLI flag works +- `eval-harness` mindset for Sent-folder verification and exact status reporting + +## When To Use + +- user asks to triage inbox or trash, rescue important mail, or delete only obvious spam +- user asks to draft or send email and wants the message to appear in the mailbox's Sent folder +- user wants proof of which account, folder, or message id was used + +## Workflow + +1. Read the exact mailbox constraint first. If the user says `himalaya only` or forbids Apple Mail or `osascript`, stay inside Himalaya. +2. Resolve account and folder explicitly: + - check `himalaya account list` + - use `himalaya envelope list -a -f ...` + - never misuse `-s INBOX` as a folder selector +3. For triage, classify before acting: + - preserve investor, partner, scheduling, and user-sent threads + - move only after the folder and account are confirmed + - permanently delete only obvious spam or messages the user explicitly authorized +4. For replies or new mail: + - read the full thread first + - choose the sender account that matches the project or recipient + - compose non-interactively with piped `himalaya template send` or `message write` + - 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 "" "" "" "" "/absolute/file1" ...` +6. If the user wants an actual send and Himalaya fails with an IMAP append or save-copy error, fall back to `/Users/affoon/.hermes/scripts/send_mail.applescript` only when the user did not forbid Apple Mail or `osascript`, then verify Sent. 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, send a short progress update before more searching. 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 -f Sent ...` or the account's actual sent folder + - report the subject, recipient, account, and message id or date if available +9. Report exact status words: drafted, sent, moved, flagged, deleted, blocked, awaiting verification. + +## Pitfalls + +- do not claim a message was sent without Sent-folder verification +- do not use the wrong account just because it is default +- do not delete uncertain business mail during cleanup +- do not switch tools after the user constrained the method +- do not wander into unrelated searches while an attachment path or Sent verification is unresolved +- do not keep searching through the budget warning while the user is asking for a status update + +## Verification + +- the requested messages are present in the expected folder after the move +- sent mail appears in Sent for the correct account +- the final report includes counts or concrete message identifiers, not vague completion language diff --git a/skills/hermes-generated/finance-billing-ops/SKILL.md b/skills/hermes-generated/finance-billing-ops/SKILL.md new file mode 100644 index 00000000..a1f5a902 --- /dev/null +++ b/skills/hermes-generated/finance-billing-ops/SKILL.md @@ -0,0 +1,71 @@ +--- +name: finance-billing-ops +description: Evidence-first Stripe sales, billing incident, and team-pricing workflow for Hermes. Use when pulling sales, investigating duplicate charges or failed payments, checking whether team billing is real in code, or benchmarking pricing. +metadata: + hermes: + tags: [generated, finance, billing, stripe, pricing, workflow, verification] +--- + +# Finance Billing Ops + +Use this when the user asks about Stripe sales, refunds, failed payments, duplicate charges, org or team billing behavior, pricing strategy, or whether the product logic matches the marketing copy. + +## Skill Stack + +Pull these imported skills into the workflow when relevant: +- `market-research` for competitor pricing, billing models, and sourced market context +- `deep-research` or `exa-search` when the answer depends on current public pricing or enforcement behavior +- `search-first` before inventing a Stripe, billing, or entitlement path +- `eval-harness` mindset for exact status reporting and separating proof from inference +- `agentic-engineering` and `plankton-code-quality` when the answer depends on checked-in ECC billing or entitlement code + +## When To Use + +- user says `pull in stripe data`, `any new sales`, `why was he charged`, `refund`, `duplicate charge`, `team billing`, `per seat`, or similar +- the question mixes revenue facts with product truth, for example whether team or org billing is actually implemented +- the user wants a pricing comparison against Greptile or similar competitors + +## Workflow + +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` + - 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 + - do not treat a transient decline as lost revenue if the same checkout later succeeded + - flag any duplicate subscriptions or repeated checkouts with exact timestamps +3. For a customer billing incident: + - identify the customer email, account login, subscription ids, checkout sessions, payment intents, and timing + - determine whether extra charges are duplicates, retries, or real extra entitlements + - if recommending refunds or consolidation, explain what product value the extra charges did or did not unlock +4. For org, seat, quota, or activation questions: + - inspect the checked-in billing and usage code before making claims + - verify checkout quantity handling, installation vs user usage keys, unit-count handling, seat registry or member sync, and quota stacking + - inspect the live pricing copy too, so you can call out mismatches between marketing and implementation +5. For pricing and competitor questions: + - use `market-research`, `deep-research`, or `exa-search` for current public evidence + - separate sourced facts from inference, and call out stale or incomplete pricing signals +6. Report in layers: + - current sales snapshot + - customer-impact diagnosis + - code-backed product truth + - recommendation or next action +7. If the user wants fixes after diagnosis: + - hand the implementation path to `agentic-engineering` and `plankton-code-quality` + - keep the evidence trail so copy changes, refunds, and code changes stay aligned + +## Pitfalls + +- do not claim `new sales` without saying whether the data is live or a saved snapshot +- do not mix failed attempts into net revenue if the payment later succeeded +- do not say `per seat` unless the code actually enforces seat behavior +- do not assume extra subscriptions increase quotas without verifying the entitlement path +- do not compare competitor pricing from memory when current public sources are available + +## Verification + +- the answer includes a snapshot timestamp or an explicit live-pull statement +- the answer separates fact, inference, and recommendation +- code-backed claims cite file paths or code areas +- customer-impact statements name the exact payment or subscription evidence they rely on diff --git a/skills/hermes-generated/knowledge-ops/SKILL.md b/skills/hermes-generated/knowledge-ops/SKILL.md new file mode 100644 index 00000000..e5677888 --- /dev/null +++ b/skills/hermes-generated/knowledge-ops/SKILL.md @@ -0,0 +1,57 @@ +--- +name: knowledge-ops +description: Evidence-first memory and context retrieval workflow for Hermes. Use when the user asks what Hermes remembers, points to OpenClaw or Hermes memory, or wants context recovered from a compacted session without re-reading already loaded files. +origin: Hermes +--- + +# Knowledge Ops + +Use this when the user asks Hermes to remember something, recover an older conversation, pull context from a compacted session, or find information that "should be in memory somewhere." + +## Skill Stack + +Pull these companion skills into the workflow when relevant: +- `continuous-learning-v2` for evidence-backed pattern capture and cross-session learning +- `search-first` before inventing a new lookup path or assuming a store is empty +- `eval-harness` mindset for exact source attribution and negative-search reporting + +## When To Use + +- user says `do you remember`, `it was in memory`, `it was in openclaw`, `find the old session`, or similar +- the prompt contains a compaction summary or `[Files already read ... do NOT re-read these]` +- the answer depends on Hermes workspace memory, Supermemory, session logs, or the historical knowledge base + +## Workflow + +1. Start from the evidence already in the prompt: + - treat compaction summaries and `do NOT re-read` markers as usable context + - 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`: + - `mcp_supermemory_recall` with a targeted query + - grep `/Users/affoon/.hermes/workspace/memory/` + - grep `/Users/affoon/.hermes/workspace/` more broadly + - `session_search` for recent Hermes conversations + - grep `/Users/affoon/GitHub/affaans_knowledge_base/` or the OpenClaw archive for historical context +3. If the user says the answer is in a specific memory store, pivot there immediately: + - `openclaw memory` means favor the historical knowledge base or OpenClaw archive + - `not in this session` means stop digging through the current thread and move to persistent stores +4. Keep the search narrow and evidence-led: + - reuse names, dates, channels, account names, or quoted phrases from the user + - search the most likely store first instead of spraying generic queries everywhere +5. Report findings with source evidence: + - give the file path, session id, date, or memory store + - distinguish between a direct hit, a likely match, and an inference +6. If nothing turns up, say which sources were checked and what to try next. Do not say `not found` after a single failed search. + +## Pitfalls + +- do not ignore a compaction summary and start over from zero +- do not keep re-reading files the prompt says are already loaded +- do not answer from vague memory without a source path, date, or session reference +- do not stop after one failed memory source when others remain + +## Verification + +- the response names the source store or file +- the response separates direct evidence from inference +- failed lookups list the sources checked, not just a bare `not found` diff --git a/skills/hermes-generated/research-ops/SKILL.md b/skills/hermes-generated/research-ops/SKILL.md new file mode 100644 index 00000000..fdebd30f --- /dev/null +++ b/skills/hermes-generated/research-ops/SKILL.md @@ -0,0 +1,64 @@ +--- +name: research-ops +description: Evidence-first research workflow for Hermes. Use when answering current questions, evaluating a market or tool, enriching leads, or deciding whether a request should become ongoing monitored data collection. +metadata: + hermes: + tags: [generated, research, market, discovery, monitoring, workflow, verification] +--- + +# Research Ops + +Use this when the user asks Hermes to research something current, compare options, enrich people or companies, or turn repeated lookups into an ongoing monitoring workflow. + +## Skill Stack + +Pull these imported skills into the workflow when relevant: +- `deep-research` for multi-source cited synthesis +- `market-research` for decision-oriented framing +- `exa-search` for first-pass discovery and current-web retrieval +- `data-scraper-agent` when the user really needs recurring collection or monitoring +- `search-first` before building new scraping or enrichment logic +- `eval-harness` mindset for claim quality, freshness, and explicit uncertainty + +## When To Use + +- user says `research`, `look up`, `find`, `who should i talk to`, `what's the latest`, or similar +- the answer depends on current public information, external sources, or a ranked set of candidates +- the task sounds recurring enough that a scraper or scheduled monitor may be better than a one-off search + +## Workflow + +1. Classify the ask before searching: + - quick factual answer + - decision memo or comparison + - lead list or enrichment + - recurring monitoring request +2. Start with the fastest evidence path: + - use `exa-search` first for broad current-web discovery + - if the question is about a local wrapper, config, or checked-in code path, inspect the live local source before making any web claim +3. Deepen only where the evidence justifies it: + - use `deep-research` when the user needs synthesis, citations, or multiple angles + - use `market-research` when the result should end in a recommendation, ranking, or go/no-go call +4. Separate fact from inference: + - label sourced facts clearly + - label inferred fit, ranking, or recommendation as inference + - include dates when freshness matters +5. Decide whether this should stay manual: + - if the user will likely ask for the same scan repeatedly, use `data-scraper-agent` patterns or propose a monitored collection path instead of repeating the same manual research forever +6. Report with evidence: + - cite the source or local file behind each important claim + - if evidence is thin or conflicting, say so directly + +## Pitfalls + +- do not answer current questions from stale memory when a fresh search is cheap +- do not conflate local code-backed behavior with market or web evidence +- do not present unsourced numbers or rankings as facts +- do not spin up a heavy deep-research pass for a quick capability check that local code can answer +- do not keep one-off researching a repeated monitoring ask when automation is the better fit + +## Verification + +- important claims have a source, file path, or explicit inference label +- freshness-sensitive answers include concrete dates when relevant +- recurring-monitoring recommendations state whether the task should remain manual or graduate to a scraper/workflow diff --git a/skills/hermes-generated/terminal-ops/SKILL.md b/skills/hermes-generated/terminal-ops/SKILL.md new file mode 100644 index 00000000..6ec37dab --- /dev/null +++ b/skills/hermes-generated/terminal-ops/SKILL.md @@ -0,0 +1,64 @@ +--- +name: terminal-ops +description: Evidence-first terminal and repo execution workflow for Hermes. Use when fixing CI or build failures, running commands in a repo, applying code changes, or proving what was actually executed, verified, and pushed. +metadata: + hermes: + tags: [generated, terminal, coding, ci, repo, workflow, verification] +--- + +# Terminal Ops + +Use this when the user asks Hermes to fix code, resolve CI failures, run terminal commands in a repo, inspect git state, or push verified changes. + +## Skill Stack + +Pull these imported skills into the workflow when relevant: +- `agentic-engineering` for scoped decomposition and explicit done conditions +- `plankton-code-quality` for write-time quality expectations and linter discipline +- `eval-harness` for pass/fail verification after each change +- `search-first` before inventing a new helper, dependency, or abstraction +- `security-review` when secrets, auth, external inputs, or privileged operations are touched + +## When To Use + +- user says `fix`, `debug`, `run this`, `check the repo`, `push it`, or similar +- the task references CI failures, lint errors, build errors, tests, scripts, or a local repo path +- the answer depends on what a command, diff, branch, or verification step actually shows + +## Workflow + +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 +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: + - 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: + - rerun the smallest command that proves the fix + - escalate to the broader build, lint, or test only after the local failure is addressed + - review the diff before any commit or push +5. 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: + - 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 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 + +## Verification + +- the response names the proving command or test and its result +- the response names the repo path and branch when git was involved +- any push claim includes the target branch and exact status