audit-docs
Skill4 starsChanged 8 months agoMITView on GitHub
Audit documentation coverage across CLI commands, web features, and configuration. Builds the CLI, discovers all commands/flags, checks web pages, and cross-references against docs/ and apps/docs/.
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
- 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
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
- bmaltais/skills★ 2same name
- faparicior/sdlc-skills★ 2same name
- krixon/skills★ 1same 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 repository5 other files it gives its agents.
- claude-code-plugin/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- tasks/CLAUDE.mdCLAUDE.md
- add-message-typeSkill
- auditSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. 0 are common, 11 are distinctive, and 12 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
12
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
If no arguments are provided, run a full audit and produce a report (no fixes).
- Distinctive: line 30
Verify the binary works:
- Very specific: line 37
Get the top-level help: Run vibeview-dev --help and parse the list of available commands.
- Distinctive: line 41
All flags (name, type, default, description)
- Distinctive: line 49
Read the web app source to identify all pages/views:
- Very specific: line 52
Read apps/web/src/App.tsx to extract route definitions (URL paths).
- Very specific: line 53
Read apps/cli/internal/server/*.go to identify API endpoints served by the backend.
- Very specific: line 60
Read apps/cli/cmd/vibeview/main.go and apps/cli/internal/settings/ to extract global flags and config loading.
- Very specific: line 61
Read any config-related files (grep for config file references or viper usage) to find all supported config keys.
- Distinctive: line 62
Check for any example config files.
- Very specific: line 89
Check apps/docs/getting-started/installation.md and apps/docs/getting-started/quick-start.md:
- Distinctive: line 91
Do quick-start steps match current CLI behavior?
- Very specific: line 139
If $ARGUMENTS contains --fix:
- Very specific: line 142
Add missing command sections to apps/docs/guide/cli.md
- Distinctive: line 143
Add missing flag tables
- Very specific: line 144
Add missing web feature descriptions to apps/docs/guide/web-interface.md
- Distinctive: line 145
Add missing config options
- Distinctive: line 146
Follow the existing documentation style and formatting conventions in each file.
- Distinctive: line 147
After making changes, list all modified files.
- Very specific: line 149
If --fix was NOT passed, end with: "Run /audit-docs --fix to automatically update documentation."
- Very specific: line 153
If make install-dev fails, report the build error and stop.
- Very specific: line 154
If a command's --help output can't be parsed, note it in the report and continue.
- Distinctive: line 155
If a documentation file doesn't exist, note it as a gap.
“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 Documentation
Discover all CLI commands, web features, and configuration options, then cross-reference against the documentation in apps/docs/ to identify gaps, outdated content, and missing sections.
Instructions
Arguments in $ARGUMENTS are optional flags:
--fix— after reporting gaps, update the documentation files to fill them--cli-only— only audit CLI command documentation--web-only— only audit web feature documentation--verbose— include per-flag detail in the report--since-last-release— only check for items added since the last release. Look at the last git tag and determine whether changes since that tag have been documented.
If no arguments are provided, run a full audit and produce a report (no fixes).
Phase 1: Build the CLI
- Build the development binary so we have the latest commands:
make install-dev - Verify the binary works:
vibeview-dev --version
Phase 2: Discover CLI commands and flags
- Get the top-level help: Run
vibeview-dev --helpand parse the list of available commands. - For each command, run
vibeview-dev <command> --helpto capture:- Usage string
- Description (Short + Long)
- All flags (name, type, default, description)
- Subcommands (if any)
- For commands with subcommands, recurse: run
vibeview-dev <command> <subcommand> --help. - Also capture global flags from
vibeview-dev --help. - Store all of this as a structured inventory for comparison.
Phase 3: Discover web features
- Read the web app source to identify all pages/views:
- Glob
apps/web/src/pages/*.tsxfor page components - Glob
apps/web/src/components/*/for feature areas
- Glob
- Read
apps/web/src/App.tsxto extract route definitions (URL paths). - Read
apps/cli/internal/server/*.goto identify API endpoints served by the backend. - Compile a list of:
- Pages: name, URL path, key features
- API endpoints: method, path, description
Phase 4: Discover configuration options
- Read
apps/cli/cmd/vibeview/main.goandapps/cli/internal/settings/to extract global flags and config loading. - Read any config-related files (grep for config file references or
viperusage) to find all supported config keys. - Check for any example config files.
Phase 5: Cross-reference against documentation
For each discovered item, check whether it is documented:
CLI Commands → Documentation
For each command discovered in Phase 2:
apps/docs/guide/cli.md(docs site):- Is the command listed?
- Does it have its own section with usage examples?
- Are all flags documented?
- Are examples accurate (flag names, defaults match reality)?
Web Features → Documentation
For each page/API endpoint discovered in Phase 3:
apps/docs/guide/web-interface.md(docs site):- Is the page/view listed?
- Are key features described?
- Are API endpoints documented?
Getting Started → Documentation
- Check
apps/docs/getting-started/installation.mdandapps/docs/getting-started/quick-start.md:- Are install instructions accurate?
- Do quick-start steps match current CLI behavior?
Phase 6: Generate report
Produce a structured markdown report with these sections:
## Documentation Audit Report
### Summary
- Total CLI commands: X (documented: Y, missing: Z)
- Total CLI flags: X (documented: Y, missing: Z)
- Total web pages: X (documented: Y, missing: Z)
- Total API endpoints: X (documented: Y, missing: Z)
- Total config options: X (documented: Y, missing: Z)
### CLI Command Gaps
For each undocumented or partially documented command:
- Command name
- What's missing (entire section, specific flags, examples)
- Which doc file(s) need updating
### Web Feature Gaps
For each undocumented page or endpoint:
- Feature name
- What's missing
- Which doc file(s) need updating
### Configuration Gaps
For each undocumented config option:
- Option name
- Which doc file(s) need updating
### Stale/Inaccurate Documentation
Items where docs don't match the actual CLI behavior:
- Flag name mismatches
- Wrong defaults
- Missing or renamed commands
### Navigation Issues
- Broken sidebar links
- Orphan pagesPrint the report to stdout.
Phase 7: Fix gaps (only if --fix was passed)
If $ARGUMENTS contains --fix:
- For each gap identified in Phase 6, update the relevant documentation file:
- Add missing command sections to
apps/docs/guide/cli.md - Add missing flag tables
- Add missing web feature descriptions to
apps/docs/guide/web-interface.md - Add missing config options
- Add missing command sections to
- Follow the existing documentation style and formatting conventions in each file.
- After making changes, list all modified files.
If --fix was NOT passed, end with: "Run /audit-docs --fix to automatically update documentation."
Error Handling
- If
make install-devfails, report the build error and stop. - If a command's
--helpoutput can't be parsed, note it in the report and continue. - If a documentation file doesn't exist, note it as a gap.
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.

