mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-12 04:33:29 +08:00
feat: consolidate all Anthropic plugins into ECC v2.0.0
Ports functionality from 10+ separate plugins into ECC so users only need one plugin installed. Consolidates: pr-review-toolkit, feature-dev, commit-commands, hookify, code-simplifier, security-guidance, frontend-design, explanatory-output-style, and personal skills. New agents (8): code-architect, code-explorer, code-simplifier, comment-analyzer, conversation-analyzer, pr-test-analyzer, silent-failure-hunter, type-design-analyzer New commands (9): commit, commit-push-pr, clean-gone, review-pr, feature-dev, hookify, hookify-list, hookify-configure, hookify-help New skills (8): frontend-design, hookify-rules, github-ops, knowledge-ops, lead-intelligence, oura-health, pmx-guidelines, remotion Enhanced skills (8): article-writing, content-engine, market-research, investor-materials, investor-outreach, x-api, security-scan, autonomous-loops — merged with personal skill content New hook: security-reminder.py (pattern-based OWASP vulnerability warnings on file edits) Totals: 36 agents, 69 commands, 128 skills, 29 hook scripts
This commit is contained in:
Affaan Mustafa
@@ -1,6 +1,6 @@
|
||||
---
|
||||
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.
|
||||
description: Evidence-first crossposting workflow for Hermes. Use when adapting posts, threads, demos, videos, or articles across requested social destinations while keeping per-platform copy distinct and verified.
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [generated, content, crosspost, workflow, verification]
|
||||
@@ -17,6 +17,7 @@ Pull these imported skills into the workflow when relevant:
|
||||
- `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
|
||||
- `continuous-agent-loop` when the task spans capability checks, multi-platform execution, and verification
|
||||
- `search-first` before claiming a platform or API supports a format
|
||||
- `eval-harness` mindset for publish verification and status reporting
|
||||
|
||||
@@ -24,22 +25,45 @@ Pull these imported skills into the workflow when relevant:
|
||||
|
||||
- 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 destination is a community thread or showcase channel like Discord's `built-with-claude`, or another destination whose live support must be checked first
|
||||
- the user asks whether a new destination or post type is supported
|
||||
|
||||
## 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`
|
||||
|
||||
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.
|
||||
|
||||
## Capability Matrix
|
||||
|
||||
Resolve these as separate questions before you answer or execute:
|
||||
- is the destination itself currently publishable or only `unverified capability`
|
||||
- does the asked transport support it right now, for example PostBridge
|
||||
- does another live path exist, such as browser publish or a different verified API
|
||||
- what is the active blocker: unsupported transport, unsupported destination, auth, MFA, missing asset, or approval
|
||||
|
||||
Do not flatten these into one label. `PostBridge unsupported` can still mean `browser path available`, and `browser blocked on auth` does not mean the destination is fully unsupported.
|
||||
|
||||
## 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
|
||||
- treat `/Users/affoon/.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
|
||||
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
|
||||
- Threads, Bluesky, or other short-form social destinations: shorter, conversational, clearly distinct wording
|
||||
- YouTube Community or other media-led destinations: 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
|
||||
@@ -56,9 +80,14 @@ Pull these imported skills into the workflow when relevant:
|
||||
- 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
|
||||
- if the asked transport is unavailable but another approved live path exists, say that explicitly and take that path next instead of doing unrelated side work
|
||||
- if the explicitly asked destination is unsupported or still unverified, report that exact state before moving to any secondary destination, and only continue with other requested platforms when the user asked for a multi-destination publish or approved the fallback order
|
||||
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
|
||||
- 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
|
||||
- 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`
|
||||
- if the state is only drafted, uploaded-only, queued, blocked, or pending manual action, report that exact status
|
||||
|
||||
@@ -71,6 +100,11 @@ Pull these imported skills into the workflow when relevant:
|
||||
- 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 treat destination examples in this skill as a live support matrix
|
||||
- do not collapse `transport unsupported` into `destination unsupported` when another live path still exists
|
||||
- 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 ignore the user's preference for screenshots or native media over raw links
|
||||
|
||||
## Verification
|
||||
|
||||
@@ -18,6 +18,7 @@ Before using this workflow:
|
||||
|
||||
Pull these companion skills into the workflow when relevant:
|
||||
- `investor-outreach` when the email is investor, partner, or sponsor facing
|
||||
- `continuous-agent-loop` when the task spans draft, approval, send, and Sent proof across multiple steps
|
||||
- `search-first` before assuming a mail API, folder name, or CLI flag works
|
||||
- `eval-harness` mindset for Sent-folder verification and exact status reporting
|
||||
|
||||
@@ -41,18 +42,23 @@ Pull these companion skills into the workflow when relevant:
|
||||
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`
|
||||
- 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
|
||||
- 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, 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.
|
||||
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.
|
||||
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
|
||||
- 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.
|
||||
9. Report exact status words: drafted, approval-pending, approved, sent, moved, flagged, deleted, blocked, awaiting verification.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
@@ -60,6 +66,8 @@ Pull these companion skills into the workflow when relevant:
|
||||
- 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 invent `himalaya smtp` or other unverified send paths
|
||||
- do not build last-minute raw-send wrappers when the checked commands and guard scripts already cover the path
|
||||
- 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
|
||||
|
||||
|
||||
@@ -12,6 +12,7 @@ Use this when the user asks Hermes to remember something, recover an older conve
|
||||
|
||||
Pull these companion skills into the workflow when relevant:
|
||||
- `continuous-learning-v2` for evidence-backed pattern capture and cross-session learning
|
||||
- `continuous-agent-loop` when the lookup spans multiple stores, compaction summaries, and follow-up recovery steps
|
||||
- `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
|
||||
|
||||
@@ -19,22 +20,24 @@ Pull these companion skills into the workflow when relevant:
|
||||
|
||||
- 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 prompt says `use the context summary above`, `proceed`, or otherwise hands off loaded context plus a concrete writing, editing, or response task
|
||||
- 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
|
||||
- if the prompt already says `use the context summary above` or asks you to proceed with writing, editing, or responding, continue from that loaded context first and search only the missing variables
|
||||
- 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`:
|
||||
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
|
||||
- `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
|
||||
- grep `/Users/affoon/GitHub/affaans_knowledge_base/` and `/Users/affoon/.hermes/openclaw-home/hub/workspace/memory/` 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/`
|
||||
- `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
|
||||
- search the most likely store first instead of spraying generic queries everywhere
|
||||
@@ -47,6 +50,8 @@ Pull these companion skills into the workflow when relevant:
|
||||
|
||||
- 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 turn a loaded-context handoff into a pure retrieval loop when the user already asked for an actual draft, edit, or response
|
||||
- do not keep searching the current session after the user already named OpenClaw or another persistent store as the likely source
|
||||
- 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
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
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.
|
||||
description: Evidence-first research workflow for Hermes. Use when answering current questions, evaluating a market or tool, enriching leads, comparing strategic options, or deciding whether a request should become ongoing monitored data collection.
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [generated, research, market, discovery, monitoring, workflow, verification]
|
||||
@@ -16,6 +16,7 @@ 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
|
||||
- `continuous-agent-loop` when the task spans user-provided evidence, fresh verification, and a final recommendation across multiple turns
|
||||
- `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
|
||||
@@ -24,28 +25,41 @@ Pull these imported skills into the workflow when relevant:
|
||||
|
||||
- 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 user pastes a compaction summary, copied research, manual calculations, or says `factor this in`
|
||||
- the user asks `should i do X or Y`, `compare these options`, or wants an explicit recommendation under uncertainty
|
||||
- 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:
|
||||
1. Start from the evidence already in the prompt:
|
||||
- treat compaction summaries, pasted research, copied calculations, and quoted assumptions as loaded inputs
|
||||
- normalize them into `user-provided evidence`, `needs verification`, and `open questions`
|
||||
- do not restart the analysis from zero if the user already gave you a partial model
|
||||
2. 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:
|
||||
3. Build the decision surface before broad searching when the ask is comparative:
|
||||
- list the options, decision criteria, constraints, and assumptions explicitly
|
||||
- keep concrete numbers and dates attached to the option they belong to
|
||||
- mark which variables are already evidenced and which still need outside verification
|
||||
4. 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:
|
||||
5. 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:
|
||||
- keep `continuous-agent-loop` discipline when the task spans user evidence, fresh searches, and recommendation updates across interruptions
|
||||
6. Separate fact from inference:
|
||||
- label sourced facts clearly
|
||||
- label user-provided evidence clearly
|
||||
- label inferred fit, ranking, or recommendation as inference
|
||||
- include dates when freshness matters
|
||||
5. Decide whether this should stay manual:
|
||||
7. 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:
|
||||
8. Report with evidence:
|
||||
- group the answer into sourced facts, user-provided evidence, inference, and recommendation when the ask is a comparison or decision
|
||||
- cite the source or local file behind each important claim
|
||||
- if evidence is thin or conflicting, say so directly
|
||||
|
||||
@@ -53,12 +67,16 @@ Pull these imported skills into the workflow when relevant:
|
||||
|
||||
- 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 ignore pasted research or compaction context and redo the whole investigation from scratch
|
||||
- do not mix user-provided assumptions into sourced facts without labeling them
|
||||
- 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 leave the comparison criteria implicit when the user asked for a recommendation
|
||||
- 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
|
||||
- user-provided evidence is surfaced as a distinct layer when it materially affects the answer
|
||||
- freshness-sensitive answers include concrete dates when relevant
|
||||
- recurring-monitoring recommendations state whether the task should remain manual or graduate to a scraper/workflow
|
||||
|
||||
@@ -13,6 +13,7 @@ Use this when the user asks Hermes to fix code, resolve CI failures, run termina
|
||||
## Skill Stack
|
||||
|
||||
Pull these imported skills into the workflow when relevant:
|
||||
- `continuous-agent-loop` for multi-step execution with scope freezes, recovery gates, and progress checkpoints
|
||||
- `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
|
||||
@@ -42,6 +43,7 @@ Pull these imported skills into the workflow when relevant:
|
||||
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
|
||||
- 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:
|
||||
- distinguish `changed locally`, `verified locally`, `committed`, and `pushed`
|
||||
@@ -56,6 +58,7 @@ Pull these imported skills into the workflow when relevant:
|
||||
- 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
|
||||
|
||||
## Verification
|
||||
|
||||
|
||||
Reference in New Issue
Block a user