audit-docs
Skill0 starsChanged 24 days agoMITView on GitHub
Audit repository documentation: detect drift between code and docs,
17 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- TserenTserenov/FMT-exocortex-templateedited, first seen Nov 2, 2026
- driangle/vibeviewtheir own version, first seen Nov 1, 2026
- Evan-Daruwalla/claude-skill-suitetheir own version, first seen Oct 20, 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
Other versions17 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- TserenTserenov/FMT-exocortex-template★ 6328% same
Wrote their own version · 16
- opsmill/infrahub★ 548same name
- frankarobotics/franka_ros2★ 392same name
- chrisguidry/docket★ 148same 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
- krixon/skills★ 1same name
6 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 repository51 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-faultSkill
- apply-capturesSkill
- archgateSkill
- artifactorSkill
- audit-installationSkill
- author-modeSkill
- bottleneck-pickSkill
- check-secretSkill
- consentSkill
- day-closeSkill
- day-openSkill
- decomposeSkill
- diagnoseSkill
- discovery-sessionSkill
- extendSkill
- fpfSkill
- integration-gateSkill
- iwe-bug-reportSkill
- iwe-platform-redteamSkill
- iwe-restoreSkill
- iwe-rules-reviewSkill
- iwe-updateSkill
- keSkill
- kimi-peer-writerSkill
- local-llmSkill
- month-closeSkill
- org-devSkill
- pack-creatorSkill
- pack-newSkill
- peer-conversationSkill
- personal-guide-renderSkill
- personal-guide-startSkill
- platform-bottleneckSkill
- repo-newSkill
- restore-exocortexSkill
- run-protocolSkill
- setup-wakatimeSkill
- skill-creatorSkill
- strategy-sessionSkill
- skill-idSkill
- thinkSkill
- transcribeSkill
- vdvSkill
- verify-hypothesesSkill
- verifySkill
- week-close-pilotSkill
- week-closeSkill
- wp-newSkill
- w-reflectionSkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 6 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 51
Read <repo>/CLAUDE.md; identify the owner and the R5 Architect.
- Distinctive: line 55
Run the validation below. Only a valid file becomes the Audit input.
- Distinctive: line 61
Run this validator before the Audit (requires PyYAML):
- Distinctive: line 115
If git history is available, check recent commits to source and verify whether the affected entities (functions, tables, endpoints) are …
- Very specific: line 124
Write the report to <repo>/docs/audit-reports/audit-YYYY-MM-DD.md with the following structure:
- Distinctive: line 156
Does NOT modify code.
- Distinctive: line 157
Does NOT modify docs.
- Very specific: line 158
Does NOT create a draft PR with suggestions (that is the next step — /auto-docs).
- Distinctive: line 159
Does NOT make decisions about docs categories (a new category is an architectural decision, not an Audit).
“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 (R24 Auditor)
Role: R24 Auditor. Full description:
PACK-digital-platform/pack/digital-platform/02-domain-entities/DP.ROLE.024-auditor.md(WP-224). Mapping: R24 = VR.R.002. Method: R24 coverage by category + R23 pair-diff betweencode file ↔ docs filepairs. Report recipient: the repository owner at a different point in time (category 3 — external project role). This is an Audit in the strict sense — not the code author, not the current agent. Role type (DP.D.080): R24 is a control role. Read-only access to audited Artifacts. The report is the output channel, not a change to the audited material.
Arguments: $ARGUMENTS
What it does
Scans the specified repository and produces a report on drift between code and documentation. Does not modify code or docs — only produces the report.
Parameters
--repo <path>(required) or.(current directory).--init --repo <path>— guided Configuration preparation; does not run the Audit.
Configuration ownership
| Responsibility | Accountable role |
| Decide that documentation coverage is required and approve the repository model | Repository owner |
| Define documentation categories and source ↔ documentation pairs | R5 Architect together with the owner |
| Materialize the approved YAML | Maintainer or agent executor |
| Consume the YAML and report on drift | R24 Auditor / audit-docs |
| Provide the template, schema, bootstrap, and ownership statement | Platform maintainer / FMT |
Blocking rule: the agent may create docs/.audit-context.yaml only after the owner has approved the categories and mappings. The R24 Auditor does not invent the semantic model — neither during the Audit nor before it.
Bootstrap (--init)
- Read
<repo>/CLAUDE.md; identify the owner and the R5 Architect. - Show them the example
.claude/skills/audit-docs/.audit-context.yaml.example. - Obtain explicit owner approval for the category list and each
source_patterns↔docs_patterns/file_namingpair. Stop without approval. - Materialize the approved model in
<repo>/docs/.audit-context.yaml; setowner_approved: true,approved_by, and the actual date. - Run the validation below. Only a valid file becomes the Audit input.
Schema and validation
The root is a mapping with strict keys schema_version: 1, owner_approved: true, approved_by, approved_at, categories. categories is a non-empty list; each category contains a unique id, non-empty string lists source_patterns and docs_patterns, and a string file_naming; drift_days is an optional positive integer. Unknown keys and empty glob patterns are errors.
Run this validator before the Audit (requires PyYAML):
python3 - "$REPO/docs/.audit-context.yaml" <<'PY'
import datetime as dt
import sys
import yaml
path = sys.argv[1]
data = yaml.safe_load(open(path, encoding="utf-8"))
root_keys = {"schema_version", "owner_approved", "approved_by", "approved_at", "categories"}
category_keys = {"id", "source_patterns", "docs_patterns", "file_naming", "drift_days"}
assert isinstance(data, dict) and set(data) == root_keys, "invalid root keys"
assert data["schema_version"] == 1, "unsupported schema_version"
assert data["owner_approved"] is True and data["approved_by"], "owner approval missing"
assert isinstance(data["approved_at"], (str, dt.date)), "approved_at missing"
categories = data["categories"]
assert isinstance(categories, list) and categories, "categories must be non-empty"
ids = []
for category in categories:
assert isinstance(category, dict) and set(category) <= category_keys, "invalid category keys"
assert {"id", "source_patterns", "docs_patterns", "file_naming"} <= set(category), "category keys missing"
ids.append(category["id"])
for key in ("source_patterns", "docs_patterns"):
assert isinstance(category[key], list) and category[key] and all(isinstance(v, str) and v.strip() for v in category[key]), key
assert isinstance(category["file_naming"], str) and category["file_naming"].strip(), "file_naming"
assert "drift_days" not in category or isinstance(category["drift_days"], int) and category["drift_days"] > 0, "drift_days"
assert len(ids) == len(set(ids)) and all(isinstance(v, str) and v.strip() for v in ids), "category ids"
print("audit-context: valid")
PYStep 0. Load context
At startup, read the following:
<repo>/CLAUDE.mdin full — as any agent in this repository would. In particular, § 10 "Known traps/invariants" (if present).<repo>/docs/.audit-context.yaml— docs categories, source patterns, file_naming. If the file is absent, report the need for--initand stop; creating the model independently is prohibited. If the file exists, run the schema validator above — an error blocks the Audit.${IWE_ROOT:-$HOME/IWE}/.claude/sync-manifest.yaml— find pairs wheresourceorderivedintersect this repository. Use these as an additional source of code ↔ docs relationships.
Step 1. R24 coverage by category
For each category in .audit-context.yaml:
- List all source files (by
source_patterns). - For each source file, find the associated docs file using
file_namingor a heuristic. - Calculate:
coverage % = docs_files / source_files. - Record gaps (source without docs) and orphans (docs without source).
Step 2. R23 pair-diff (drift detection)
For each existing source ↔ docs pair:
- Compare mtime — if docs is older than source by more than N days (threshold from the Manifest or default 7), mark as an update candidate.
- If git history is available, check recent commits to source and verify whether the affected entities (functions, tables, endpoints) are mentioned in docs.
- Record
drift_candidateswith priority (critical / warn / ok).
Step 3. Link to CLAUDE.md § 10
For each trap/invariant in CLAUDE.md § 10, check whether it is mentioned in docs. If not, add it to the "Non-obvious items" section.
Step 4. Generate the report
Write the report to <repo>/docs/audit-reports/audit-YYYY-MM-DD.md with the following structure:
# Audit report — <repo> — <YYYY-MM-DD>
## Coverage by category
| Category | Source files | Docs files | Coverage % | Status |
|----------|--------------|------------|------------|--------|
## Gaps (source without docs)
- ...
## Orphans (docs without source)
- ...
## Drift candidates (pair-diff)
| Source | Docs | mtime lag | Priority |
|--------|------|-----------|----------|
## Non-obvious items (§ 10 CLAUDE.md, not covered by docs)
- ...
## Summary
- Total coverage: X%
- Drift critical: N
- Drift warn: N
- Gaps: N
- Orphans: NWhat it does NOT do
- Does NOT modify code.
- Does NOT modify docs.
- Does NOT create a draft PR with suggestions (that is the next step —
/auto-docs). - Does NOT make decisions about docs categories (a new category is an architectural decision, not an Audit).
Relationship to other skills
/verify— verifies an Artifact against the Pack reference (VR.R.001)./audit-docs— cross-repository coverage Audit (R24/VR.R.002). Different roles, different methods.iwe-drift.sh— detects drift between pairs insync-manifest.yaml(S-class)./audit-docs— in-depth docs/ Audit within a single repository. The drift → "run/audit-docs" decision is a standard workflow.
Relationship to SC.024.∞
This skill implements Variant C (manual baseline) from the SC.024.∞ — Auto-update docs/ design. After 2 weeks of operation and accuracy calibration, transition to Variant A (post-merge GitHub webhook). See the adjacent README.md.
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.

