agentleFS
driangledriangle/vibeview/.claude/skills/audit-docs/SKILL.md

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

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.
  • MicrosoftSkill

    diagnose

    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

  • SentrySkill

    skill-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

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
  1. Distinctive:

    If no arguments are provided, run a full audit and produce a report (no fixes).

    line 22
  2. Distinctive:

    Verify the binary works:

    line 30
  3. Very specific:

    Get the top-level help: Run vibeview-dev --help and parse the list of available commands.

    line 37
  4. Distinctive:

    All flags (name, type, default, description)

    line 41
  5. Distinctive:

    Read the web app source to identify all pages/views:

    line 49
  6. Very specific:

    Read apps/web/src/App.tsx to extract route definitions (URL paths).

    line 52
  7. Very specific:

    Read apps/cli/internal/server/*.go to identify API endpoints served by the backend.

    line 53
  8. Very specific:

    Read apps/cli/cmd/vibeview/main.go and apps/cli/internal/settings/ to extract global flags and config loading.

    line 60
  9. Very specific:

    Read any config-related files (grep for config file references or viper usage) to find all supported config keys.

    line 61
  10. Distinctive:

    Check for any example config files.

    line 62
  11. Very specific:

    Check apps/docs/getting-started/installation.md and apps/docs/getting-started/quick-start.md:

    line 89
  12. Distinctive:

    Do quick-start steps match current CLI behavior?

    line 91
  13. Very specific:

    If $ARGUMENTS contains --fix:

    line 139
  14. Very specific:

    Add missing command sections to apps/docs/guide/cli.md

    line 142
  15. Distinctive:

    Add missing flag tables

    line 143
  16. Very specific:

    Add missing web feature descriptions to apps/docs/guide/web-interface.md

    line 144
  17. Distinctive:

    Add missing config options

    line 145
  18. Distinctive:

    Follow the existing documentation style and formatting conventions in each file.

    line 146
  19. Distinctive:

    After making changes, list all modified files.

    line 147
  20. Very specific:

    If --fix was NOT passed, end with: "Run /audit-docs --fix to automatically update documentation."

    line 149
  21. Very specific:

    If make install-dev fails, report the build error and stop.

    line 153
  22. Very specific:

    If a command's --help output can't be parsed, note it in the report and continue.

    line 154
  23. Distinctive:

    If a documentation file doesn't exist, note it as a gap.

    line 155

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Build the development binary so we have the latest commands:
    make install-dev
  2. Verify the binary works:
    vibeview-dev --version

Phase 2: Discover CLI commands and flags

  1. Get the top-level help: Run vibeview-dev --help and parse the list of available commands.
  2. For each command, run vibeview-dev <command> --help to capture:
    • Usage string
    • Description (Short + Long)
    • All flags (name, type, default, description)
    • Subcommands (if any)
  3. For commands with subcommands, recurse: run vibeview-dev <command> <subcommand> --help.
  4. Also capture global flags from vibeview-dev --help.
  5. Store all of this as a structured inventory for comparison.

Phase 3: Discover web features

  1. Read the web app source to identify all pages/views:
    • Glob apps/web/src/pages/*.tsx for page components
    • Glob apps/web/src/components/*/ for feature areas
  2. Read apps/web/src/App.tsx to extract route definitions (URL paths).
  3. Read apps/cli/internal/server/*.go to identify API endpoints served by the backend.
  4. Compile a list of:
    • Pages: name, URL path, key features
    • API endpoints: method, path, description

Phase 4: Discover configuration options

  1. Read apps/cli/cmd/vibeview/main.go and apps/cli/internal/settings/ to extract global flags and config loading.
  2. Read any config-related files (grep for config file references or viper usage) to find all supported config keys.
  3. 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:

  1. 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:

  1. apps/docs/guide/web-interface.md (docs site):
    • Is the page/view listed?
    • Are key features described?
    • Are API endpoints documented?

Getting Started → Documentation

  1. Check apps/docs/getting-started/installation.md and apps/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 pages

Print the report to stdout.

Phase 7: Fix gaps (only if --fix was passed)

If $ARGUMENTS contains --fix:

  1. 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
  2. Follow the existing documentation style and formatting conventions in each file.
  3. 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-dev fails, report the build error and stop.
  • If a command's --help output can't be parsed, note it in the report and continue.
  • If a documentation file doesn't exist, note it as a gap.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.