audit-docs
Skill0 starsChanged 45 days agoMITView on GitHub
Cold DOCS-only audit tested against disk: are the docs TRUE (wrong before missing before ugly); "recent" also finds docs that code changes should have updated. Use when: "audit the docs", "are the docs true", "did I update the docs". Findings only.
17 other projects use a version of this.
Adopted by
Most recently taken up by
- TserenTserenov/FMT-exocortex-templatetheir own version, first seen Nov 2, 2026
- iwesys/IWEtheir own version, first seen Nov 1, 2026
- driangle/vibeviewtheir own version, first seen Nov 1, 2026
- LandonTomaine/LT-Agentstheir own version, first seen Oct 20, 2026
- faparicior/sdlc-skillstheir own version, first seen Oct 20, 2026
- fritzprix/libr-agenttheir own version, first seen Oct 13, 2026
Used with
Projects with it also use diagnose and skill-creator.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
MicrosoftSkilldiagnose
Use to systematically diagnose why scenarios fail — identifies root causes by analyzing agent traces, codebase, and behavioral patterns
Also in 3 projects that use this
SentrySkillskill-creator
Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.
Also in 4 projects that use this
Other versions17 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 17
- opsmill/infrahub★ 548same name
- frankarobotics/franka_ros2★ 392same name
- chrisguidry/docket★ 148same name
- TserenTserenov/FMT-exocortex-template★ 63same name
- DGouron/review-flow★ 42same name
- gtrabanco/agentic-workflow★ 23same name
- fritzprix/libr-agent★ 11same name
- driangle/vibeview★ 4same name
- bmaltais/skills★ 2same name
- faparicior/sdlc-skills★ 2same name
7 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 repository34 other files it gives its agents.
- audit-codeSkill
- auditSkill
- bisect-driverSkill
- coding-conventionsSkill
- commit-gateSkill
- compact-ioSkill
- cron-task-manageSkill
- cve-auditSkill
- data-integrity-auditSkill
- decision-logSkill
- deck-builderSkill
- determinism-guardSkill
- etl-validateSkill
- experiment-logSkill
- fetch-firstSkill
- flaky-test-detectorSkill
- github-repo-polishSkill
- golden-lockSkill
- history-leak-scanSkill
- landing-checkSkill
- llm-eval-harnessSkill
- local-secrets-manageSkill
- long-taskSkill
- milestone-trackSkill
- opus-workersSkill
- path-quirk-auditSkill
- reorg-proposalSkill
- research-briefSkill
- seed-controlSkill
- shell-portabilitySkill
- skill-vetSkill
- small-taskSkill
- token-squeezeSkill
- venue-fitSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 3 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
Scope is an argument, not a separate skill: Default is the whole project.
- Very specific: line 46
Enter cold: If this session already worked on the project, spawn a fresh auditor per fanout.md and hand it only what that file permits — …
- Distinctive: line 93
Verify: Every crit and high is reproduced by the session model itself, with the command and its real output.
- Distinctive: line 113
The findings pass changes NOTHING: No drive-by fixes.
- Very specific: line 116
Never invent a number, measurement, or timestamp: Run date before writing any timestamp.
- Very specific: line 123
Every .md file this skill creates or writes to gets ASCII characters only (bytes 0x00-0x7F) in the text you add.
- Very specific: line 131
Check before saving. In a git repo, git diff -U0 -- <file> | grep -v '^+++' | grep '^+' | grep -nP '[^\x00-\x7F]' must print nothing.
- Distinctive: line 135
Leave non-ASCII in text you did not write.
“Common” is measured: kept by at least 6 in 10 of the 16 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
Audit — docs, whole project
Documentation audited for defects, against evidence — not a content inventory, not a style pass. Every finding carries a file:line and the command that proves the contradiction.
In this tree's 2026-08-15 cold audit, roughly six of about thirty-five findings were doc-vs-reality drift even though docs were only a secondary lens. This skill makes them the primary one.
Which audit is this?
| Skill | Domain |
audit | code + docs + the cross-domain pass |
audit-code | code only |
audit-docs | docs only |
Scope is an argument, not a separate skill. Default is the whole project.
Pass recent — /audit-docs recent, or "audit the recent docs" — to scope to
work since a base ref. The methods are identical either way; only what they are
pointed at changes.
Not this skill
- Did the change land where it actually executes? ->
landing-check. This skill hunts defects; it does not verify a deployment reached the live file. The two are complementary and neither replaces the other. - Is this diff correct? ->
/code-review. - Did the code I just wrote run? ->
coding-conventions(fires on its own). - One narrow mechanical check -> the specialist owns it and this audit
CALLS it rather than re-deriving:
cve-audit,history-leak-scan,local-secrets-manage,data-integrity-audit,path-quirk-audit,shell-portability,seed-control,determinism-guard,milestone-track.
Protocol
The depth lives in shared reference files, in the audit skill's references/ directory. Read each as you reach
its step; this file holds only the order and what is different about this mode.
Enter cold. If this session already worked on the project, spawn a fresh
auditor per fanout.md and hand it only what that file permits — never session
belief, never "this part is known-good". If the session is genuinely fresh, you
ARE the cold auditor. Cold means unbiased, not amnesiac: read the project's own
docs, as claims under test.
1. Resolve scope. Per scoping.md.
FULL scope (default). Build the manifest before spawning anyone. Enumerate
with git -c core.quotepath=false ls-files — not a $-anchored extension
grep, which silently drops every non-ASCII filename (this cost a real audit its
most important document on 2026-08-21). Reconcile the count against a second
enumeration. This working directory may contain several git repos rather than
being one: do not silently pick one, and do not sweep them all under a single
manifest without asking.
RECENT scope (when recent is passed). Resolve the base ref deliberately
and say which you chose. Use three-dot git diff base...HEAD — two-dot
picks up base-branch drift and is the classic wrong answer. Include uncommitted
and untracked work (git status --porcelain, git diff, git diff --staged;
untracked files need git add -N to appear in a diff at all — there is no
--include-untracked flag). Rank by relative churn, not absolute:
Nagappan & Ball (ICSE 2005) measured absolute churn at R^2 = 0.052 and
size-normalized churn at R^2 = 0.811.
Then walk the blast radius — mandatory. Take the changed set, walk reverse
dependencies (import graph, call graph, git log -G over changed symbols), and
pull unchanged callers into scope. A changed function's untouched callers are
exactly where a broken contract surfaces. Without this, "recent audit clean"
means only "the diff reads fine".
Recent-scoped reports state their own blind spots — what was not swept, and that they cannot see pre-existing defects in untouched code or a latent bug the change newly made reachable.
2. Every file in scope is assigned to a worker, and every exclusion is listed with its reason. The coverage map is computed from the manifest and the workers' reconciled search trails, not narrated from memory. "38 of 41 files swept, 3 vendored" is checkable; "comprehensive sweep" is not.
Fan out. Per fanout.md. Sonnet workers, eight maximum across all
levels including any delegates. Pre-register the acceptance rubric before any
worker output exists. Workers do NOT vote or cross-review — they report
independently and the session model adjudicates on evidence.
Sweep. docs-methods.md — D1 through D8, after the automated pass, in the cost order that file specifies.
Verify. Every crit and high is reproduced by the session model itself, with the command and its real output. A zero-result search is a claim, not a fact — cross-check load-bearing negatives through a second implementation before believing them.
Report. Exactly the contract in reporting.md.
Wait for approval, then fix in the stated order, verifying each fix by running the thing. Re-run the automated pass afterwards and report before/after.
Notes for this mode
Two rules from that file are worth surfacing here, because both cut against instinct:
File age is not staleness. Tang et al. (ACM TOSEM 2024) tested the "untouched for N days" heuristic: it flagged 70.3% of screenshots, of which a 154-item sample contained 8 genuinely outdated. An old date is a reason to check, never a finding.
Hunt wrong before missing. Practitioners rate a wrong code comment (49% important) at roughly twice a missing one (28%). Do not spend the sweep counting undocumented functions.
Rules
- The findings pass changes NOTHING. No drive-by fixes.
- Never delete anything you did not create this session without asking.
- Never install new scanners without asking; never certify compliance.
- Never invent a number, measurement, or timestamp. Run
datebefore writing any timestamp. Missing data is reported as missing. - Coverage is proven by the manifest, not by how thorough it felt. A method not run is "not swept", never "no findings".
ASCII-only markdown (rule added 2026-09-23)
Every .md file this skill creates or writes to gets ASCII characters only
(bytes 0x00-0x7F) in the text you add. No exceptions for headings, tables,
quotes, names or pasted tool output.
- Dashes:
-(never an en or em dash). Arrows:->and<-. Quotes: straight"and'. Ellipsis:.... Math:x,+/-,<=,>=,~. Separators:-,;or|. No emoji, no check-mark glyphs (use[x]and[ ]), no accented letters: transliterate names and quoted text. - Check before saving. In a git repo,
git diff -U0 -- <file> | grep -v '^+++' | grep '^+' | grep -nP '[^\x00-\x7F]'must print nothing. For a new or untracked file,grep -nP '[^\x00-\x7F]' <file>must print nothing. - Leave non-ASCII in text you did not write. Earlier entries of an append-only record stay byte for byte; converting an existing file is a separate, explicit job.
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.

