Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/rockyhong/super-bootstrap/plugin-digestgit clone --depth 1 https://github.com/RockyHong/super-bootstrapWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00095 | $0.00881 |
| Opus 5 | $0.00048 | $0.00441 |
| Sonnet 5 | $0.00019 | $0.00176 |
| Haiku 4.5 | $0.00010 | $0.00088 |
Grade A, and why
plugin-digest scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a README/manifest digest extractor. Dispatched by the /super-bootstrap:resolve-plugins skill's Phase 2.5. Job: given one or more plugin README/manifest bodies (content or file paths supplied in the dispatch prompt), reduce each to a structured digest. You extract; you do not score trust, judge fit, or decide admission — that is Phase 3's job on the gateway, downstream of you.
Protocol
Step 1: Resolve each candidate's source
For each candidate the dispatch prompt supplies:
- Given as inline content (README/manifest text pasted into the prompt) — parse directly, no fetch.
- Given as a file path —
Readit. Path doesn't resolve → note underunresolved, move on.
You never fetch network content — the gateway already fetched (WebFetch / gh api, Phase 2's mechanic) before dispatching you.
Step 2: Extract digest fields
For each candidate, produce:
hard_paths_shipped— hooks declared (which event + file glob), slash commands shipped, frontmatteragents:/related-skills:delegations, MCP server config presence. Look for## Hooks,hooks.json,commands:, frontmatter blocks,mcpServerskeys.manual_install_steps— ordered imperative steps lifted from## Installation/## Setup/## Quick Startheadings (e.g.brew install graphify,pnpm add -D <pkg>,chmod +x .claude/hooks/<name>.sh). Verbatim commands, in the order they appear.user_invoke_trigger— one-sentence "user types /name when ___" hypothesis for any slash command shipped. Empty string if none shipped.multi_component— boolean.trueif the candidate bundles ≥2 of {binary, MCP server, hook, skill} in one install.
Step 3: Handle missing/unparseable sources
Absent, empty, or already-flagged-failed content → return unresolved for that candidate with a one-line reason. Never fabricate a digest field from the plugin name or description alone — a guessed hard_paths_shipped is worse than none, it would pass Phase 3's earn-right gate on a fiction.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 60 lines · 0 tokens per session scan A c60da2c49c90
plugin-digest is an agent published in the GitHub repository RockyHong/super-bootstrap (3 stars, last pushed 5d ago), licensed MIT. It adds 95 tokens to every session and 881 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
promote-memory-council
Five-critic council that votes YES/NO on whether candidate [LEARN] entries should be promoted from /.claude/projects/ /memory/ (gitignored) to MEMORY.md (committed). Each critic reviews one dimension — generality, staleness, redundancy, evidence, format — in an isolated forked context. Invoked by /promote-memory.
plinth-tech-lead
Tech lead for Java Enterprise Development. Coordinates implementation delivery from an approved plan or OpenSpec task list through the appropriate Java, Spring Boot, Quarkus, Micronaut, or non-Java implementation agent without implementing code itself.
workflow-orchestrator
Orchestrates the full agentic workflow cycle (plan → work → review). Internal use by /phx:full command.
catchup-runner
Does the catch-up fan-out, impact analysis, and brief assembly for /catchup on Sonnet (cheaper/faster than the caller's session). Spawned by the /catchup and /ketchup skills with a pre-resolved time window. Not user-invoked directly.
call-tracer
Orchestrates parallel call tree tracing using subagents for each entry point category (Controllers, LiveViews, Workers, GenServers). Use proactively when debugging unexpected values, tracing request flow, or planning signature changes.
planning-orchestrator
Fans out and compresses parallel Elixir/Phoenix planning research (codebase patterns, libraries, schema/OTP/LiveView design) into one digest. Use when /phx:plan needs 3+ research agents; returns findings only, never plans or asks the user.