doc-audit
Skill1 starsChanged 8 days agoMITView on GitHub
Use after a slice/phase completes, at a phase transition, or before handing off unfinished work.
12 other projects use a version of this.
Adopted by
Most recently taken up by
- florian101010/awesome-agentic-AI-coding-templatetheir own version, first seen Nov 1, 2026
- sunitghub/canon-skillstheir own version, first seen Oct 22, 2026
- Sprintlaw/legal-skillstheir own version, first seen Oct 17, 2026
- jrittelmeyer/ai-dev-kittheir own version, first seen Oct 15, 2026
- bekalpaslan/promptlinetheir own version, first seen Oct 13, 2026
- tachyon-zcash/ragutheir own version, first seen Oct 8, 2026
Other versions12 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 12
- PackmindHub/packmind★ 321same name
- tachyon-zcash/ragu★ 61same name
- bekalpaslan/promptline★ 11same name
- sunitghub/canon-skills★ 9same name
- florian101010/awesome-agentic-AI-coding-template★ 4same name
- Wubabalala/claude-skills★ 4same name
- ApurvBazari/claude-plugins★ 3same name
- jarosser06/drift★ 1same name
- jrittelmeyer/ai-dev-kit★ 1same name
- s-frantz/agent-memory-trellis★ 1same name
2 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- brainstormingSkill
- commitSkill
- design-doc-templateSkill
- dev-kickoffSkill
- dev-resumeSkill
- reverse-engineeringSkill
- review-reportSkill
- roadmap-planningSkill
- setupSkill
- teardownSkill
- verify-checklistSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.
0
Common
Most of the 12 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Before handing off an unfinished session
- Very specific: line 36
If docs/00.INDEX.md / docs/CLAUDE.md exist, they are the SSOT for that set's structure and per-topic ownership — audit against them.
- Very specific: line 58
Only at session handoff. Single question: can the next session identify one concrete task to start from the documents alone (yes/no + …
“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Document Audit Guide
Audits document-to-document consistency and whether the code paths/symbols the documents cite still exist. Other mak stages only diff code against one design doc — nothing checks whether the rest of the documents are still valid.
Report only, in the user's language — never edit documents. Fixes go through mak:doc-editor or the main thread.
Delegation — if the mak:auditor agent is in the available agent list, the audit itself may be delegated to it. It loads this skill as a companion, so the assignment does not need to re-transmit §Checklist, §Report, §Scope Rule, or §Non-goals below — it still must carry which §When to Use trigger this audit is running under, the entry points, the derived audit surface, the output language, and the project path. It reports only too; fixes stay with the main thread either way.
When to Use
- Right after a slice/phase completes
- At a phase transition
- Before handing off an unfinished session
Do not run on every commit — this targets accumulated drift across documents, not a single change.
Route elsewhere: implementation vs. one design doc → mak:review-report; build/lint/tests → mak:verify-checklist; whether documented behavior matches code → mak:analyzer; choosing the next task → mak:dev-resume.
Audit Surface
Audit only what exists; silently skip what doesn't.
| Surface | Where |
| Design docs (master + sub-docs) | per the mak:design-doc-template save-path rule |
| Roadmap | per the mak:roadmap-planning save-path priority |
| Permanent doc set | docs/ |
If docs/00.INDEX.md / docs/CLAUDE.md exist, they are the SSOT for that set's structure and per-topic ownership — audit against them. If absent, treat docs/*.md as plain documents and never invent structure.
Scope Rule
Fixed entry points — never scan everything, unless the user explicitly requests a full scan.
Resolve cited paths against the project they belong to — a document may legitimately cite a target project's file (docs/CLAUDE.md, .claude/CLAUDE.md) that does not exist in this repository. Treat those as out of scope, not as dangling.
- Collect entry points — slice IDs / documents / source files or symbols changed or completed this cycle
- Trace backward — grep each entry point across the audit surface
- Audit only entry-point documents + grep hits — read nothing else
Checklist
- Back-reference tracking — grep changed slice IDs/symbols; do referencing documents match the post-change content?
- Dangling references — references to nonexistent symbols, sections, documents, or code paths/identifiers
- Mismarked completion — marked done while residual tasks remain. Includes the design doc's own progress record: a meta
Status: doneover §5.0 rows still sitting at⬜ todo/▶ in progress, or a roadmap item marked complete while its design doc's §5.0 disagrees. Compare the documents against each other only — whether a✅ donerow matches the actual code is §Non-goals - Cross-document contradiction — phase placement/status differs between documents
- SSOT inversion — a derived document contradicts its SSOT (sub-doc vs. master,
docs/per-topic SSOT)
Handoff Check
Only at session handoff. Single question: can the next session identify one concrete task to start from the documents alone (yes/no + evidence)? The receiving side of that handoff is mak:dev-resume.
Non-goals
Whether documented behavior/flow matches the code is out of scope — that needs code reading, not comparison (mak:analyzer's job). If a drift signal appears (symbol exists but signature/arity differs from the doc, or cited code changed substantially after the doc's last update), do not judge it here — record it as a 📝 Note recommending mak:analyzer re-analysis.
Report
Reuse mak:review-report's grades: 🔴 Critical / 🟡 Warning / 🟢 Pass / 📝 Note — no new grades. Every finding needs evidence (a grep hit, or two contradicting locations). State the entry points used and the derived audit surface at the top. Distinguish "no issues found" from "could not verify".
| Grade | Item | Location | Evidence | Suggested fix |
If clean: ✅ No cross-document inconsistencies found
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

