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 skills/aj604/toolshed/fixing-docsnpx skills add aj604/toolshed --skill fixing-docsgit clone --depth 1 https://github.com/aj604/toolshedWhat 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.00097 | $0.04537 |
| Opus 5 | $0.00048 | $0.02269 |
| Sonnet 5 | $0.00019 | $0.00907 |
| Haiku 4.5 | $0.00010 | $0.00454 |
Grade A, and why
fixing-docs 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 — 259 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Fixing Docs
Overview
A validated, current approval set is the only authority, and the applier is the only writer. One door lands every record type — drift and bloat alike — because after minting the flow is identical; the record's finding code is internal routing, not a different skill.
You never edit a document under audit. Not with Edit, not with Write, not with
sed, not "just this one line". Every byte that lands is written by
python3 -m doclifecycle apply-plan, from an edit plan bound to an approval set the
engine validated against both the report and the repository.
Violating the letter of the flow is violating the spirit of the flow. The point is not ceremony: a diff produced any other way carries no proof of what authorized it, so a reviewer cannot tell an approved remedy from your opinion.
Contract (read it, do not restate it): ${CLAUDE_PLUGIN_ROOT}/engine/README.md,
sections Approval sets and The applier. Run engine commands with the plugin's
engine directory on PYTHONPATH.
REQUIRED SUB-SKILL: use writing-docs for any replacement text you must author yourself (a paragraph, a merged remainder) rather than place — the report's proposal already meets that bar and is placed byte-verbatim.
The flow — four steps, in order, every time
1. Mint the approval set
The input is one engine report — drift-audit or bloat-audit output — plus the
record digests a person selected from it. That selection is the semantic approval,
and minting is what turns it into the artifact; the names alone are not it.
python3 -m doclifecycle mint-approval --report "${TMPDIR:-/tmp}/report.json" --repo . \
--record <record digest> --minter <who approved> --out /tmp/approval.json
--record takes the record's digest, not its display id — the id is a label the
report can renumber. Repeat it once per approved record. Write the artifact
outside the work tree or to a git-ignored path; the engine refuses a tracked or
would-be-tracked path, because a git add -A in the change it authorizes would
commit the authority next to the diff.
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 · 259 lines · 97 tokens per session scan A 3a4b6bec9a8a
fixing-docs is a skill published in the GitHub repository aj604/toolshed (2 stars, last pushed 26d ago), licensed MIT. It adds 97 tokens to every session and 4,537 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 skills, from other repositories
tech-design-generation
Generates professional Technical Design Documents following industry-standard engineering practices. This skill activates when the user asks to write a technical design, create an architecture design, draft a design doc, write a technical proposal, do system design, create a technical design document, write an RFC…
test-cases-generation
Generates structured test case sets with multi-dimensional coverage from project code analysis or specification documents. This skill activates when the user asks to write test cases, generate tests, supplement tests, create test coverage, or improve test completeness. It auto-scans the project to extract testable…
idea
Use when exploring a new idea before writing formal specifications. Guides users through iterative discovery, research, and critical analysis to crystallize vague ideas into validated requirement drafts. Includes anti-pseudo-requirement checks, competitive research, demand evidence gathering, and "What if we don't…
test-plan-generation
Generates professional Test Plan and Test Cases documents following IEEE 829 test documentation standards, ISTQB testing methodologies, and Google Testing Blog best practices. This skill activates when the user asks to write a test plan, create test cases, draft a test plan document, create a test cases document…
prd-generation
Generates professional Product Requirements Documents (PRDs) following industry-standard methodologies. This skill activates when the user asks to write PRD, create a product requirements document, draft product requirements, do product planning, do feature planning, write a product spec, or create a product document.…
propagate
Walk an upstream documentation change downstream — when a PRD, SRS, tech-design, or feature spec is edited, find every dependent document, identify which sections are now stale, and interactively update them to keep the entire doc chain consistent. Use after editing any spec-forge document, or run periodically with…