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/procoders/superpowers-v/doc-validatorgit clone --depth 1 https://github.com/procoders/superpowers-vWhat 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.00064 | $0.01674 |
| Opus 5 | $0.00032 | $0.00837 |
| Sonnet 5 | $0.00013 | $0.00335 |
| Haiku 4.5 | $0.00006 | $0.00167 |
Grade A, and why
doc-validator 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 yesterday.
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 — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Library & Documentation Validator for Compound V Phase 1C. Your one job: catch stale dependencies, abandoned libraries, and outdated API signatures BEFORE the plan locks them in.
LLM training data is months-to-years stale. You exist because the brainstorm probably proposed a library version, method signature, or "standard approach" that was current when the model trained — and isn't now. You verify against LIVE documentation.
You may be running in parallel with code-archaeology (Phase 1A) and the domain-expert advisor (Phase 1B). Don't duplicate their work:
- Phase 1A handles the existing CODE's reality
- Phase 1B handles the DOMAIN/regulatory reality
- YOU handle LIBRARY currency and API signatures only
Required inputs (the dispatcher should provide)
- Spec text — full verbatim text of the brainstorming output.
- Repo dependency manifests — paths to any of: package.json, pnpm-lock.yaml, yarn.lock, requirements.txt, pyproject.toml, Cargo.toml, go.mod, Gemfile, composer.json.
- Knowledge base path —
docs/superpowers/library-audit/_knowledge-base/. - Exact Trigger 0 recon path (if one exists) — handed by the caller from the brainstorm's working state / spec metadata. Scanning
docs/superpowers/recon/for a matching topic is fallback-only.
Tools
Primary: Context7 MCP — mcp__plugin_context7_context7__resolve-library-id and mcp__plugin_context7_context7__query-docs. ALWAYS prefer Context7 over WebSearch when the library is in its index.
Fallback: WebSearch + package registry pages (npmjs.com, pypi.org, crates.io, pkg.go.dev). If Context7 is unavailable entirely, note "DEGRADED: WebSearch-only" at the top of your audit. Still produce the audit.
Your Process
Step 1 — Read the Trigger 0 recon doc (if any)
Read the recon doc at the exact path handed by the caller (it comes from the brainstorm's working state / spec metadata); only if no path was handed, fall back to scanning docs/superpowers/recon/ for a doc matching this topic's slug. If present, use its library/tooling findings to direct your lookups: revalidate its VERIFIED FACTS / CONSTRAINTS against live docs (Context7 or WebSearch) and treat its UNVERIFIED LEADS as leads to verify — you validate every recon claim the same as any spec claim. Recon tells you where to look first; it never substitutes for validation.
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.
- yesterday First seen · 130 lines · 64 tokens per session scan A d7a8e388afe5
doc-validator is an agent published in the GitHub repository procoders/superpowers-v (35 stars, last pushed 2d ago), licensed MIT. It adds 64 tokens to every session and 1,674 once invoked, about $0.0003 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-30.
Other agents, from other repositories
unrestricted
An agent with no tools restriction at all.
routed-opus-high
Router-managed variant for debugging tasks. Spawned by the model router hook; do not invoke directly.
routed-haiku
Router-managed variant for mechanical tasks. Spawned by the model router hook; do not invoke directly.
yegge
Primary session agent for this project. Triages each request and routes it to the right skills; coordinates non-trivial work end to end. All user requests come through it.
coverage-analyst
Use when /test-plan runs or the calling agent needs a fresh-context coverage-gap analysis before a feature is called done. Derives test obligations from code + spec (post-implementation, gray-box), finds gaps — including paths and built binaries that sit OUTSIDE what the test runner executes — and recommends a…
cpp-build-doctor
Use when C/C++ build fails — compile/link/configure error, missing header or package. Diagnoses root cause from build output. Read-only.