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 commands/edwardangert/docs-agent-plugin/auditgit clone --depth 1 https://github.com/EdwardAngert/docs-agent-pluginWhat 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.00011 | $0.03688 |
| Opus 5 | $0.00005 | $0.01844 |
| Sonnet 5 | $0.00002 | $0.00738 |
| Haiku 4.5 | $0.00001 | $0.00369 |
Grade A, and why
audit scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
1. **No tooling at all, or a one-off scoped audit**: run `npx --yes markdown-link-check --quiet <files>` directly (add `--config .markdown-link-check.json` if present) rather than hand-rolling requests with `curl`/`WebFe How it starts
The opening of the file, as written. The whole thing — 221 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Audit Documentation
Perform a systematic documentation audit on the specified path: $ARGUMENTS
Your Role
Focus on content and strategy, the things that require judgment:
- Is this the right content type for the user's goal?
- Does the information architecture match how users think?
- Are there gaps in documentation coverage?
- Does content make assumptions about prerequisite knowledge?
- Is related information consolidated or scattered?
- Are docs serving users or just describing features?
- Does each doc's reader journey actually work? Outline the user stories each doc serves and walk them through it: arrival, entry, path, exit. See
${CLAUDE_PLUGIN_ROOT}/skills/docs-assist/reference/user-stories.md.
Leave mechanical checks to linters (Vale, markdownlint, cspell). This is an operation, not just a principle: see step 0 below. Do not reimplement MD022, MD032, MD040, or Vale's prose rules by reading files by hand; a linter finds every instance in seconds where a manual pass misses several per file.
Running the linters clean is the floor, not the audit. It confirms the docs are well-formed; it says nothing about whether they're still true. Your primary value is the two things a linter cannot do: understanding the documentation holistically to serve users better, and tracing what the docs claim out to the code that should back it (see "Trace claims to the code" under Content Issues below). A pass that stops at a clean lint run has not audited the content yet.
Resolve .docs-assist/config.yml and style.md first if they exist, and audit against them.
When they do not exist, do not stop to ask about conventions: the docs set's own internal consistency is the standard.
Hold the set to the rigor of a full documentation team reviewing a solo writer's work: example values that drift between docs, the same concept under different terms, stale cross-references, and structural inconsistencies between sibling docs.
Audit Process
Match the depth of the audit to the target. A full documentation set, a single directory, a handful of changed files, and a diff are different jobs. Do not run whole-set steps against a few files.
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 · 221 lines · 11 tokens per session scan A 22ac8918eea4
audit is a command published in the GitHub repository EdwardAngert/docs-agent-plugin (5 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 11 tokens to every session and 3,688 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.