agentleFS
fritzprixfritzprix/libr-agent/.agents/skills/doc-auditor/SKILL.md

doc-auditor

Skill11 starsChanged 19 days agoMITView on GitHub

Analyze a codebase to discover documentation gaps in README.md and docs/ directories, then generate or update missing documentation. Use when the user asks to (1) audit README/docs for missing coverage, (2) find undocumented features or modules, (3) fill documentation gaps, (4) update docs to match current code, (5) generate a doc-gap report, (6) "문서 누락 분석", "README/_docs_ 감사", "문서 보완", "docs gap audit", "undocumented features". Triggers on any request to compare codebase structure against existing documentation and produce a gap analysis or fill the gaps.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the analysis script to produce a machine-readable feature inventory:

    line 14
  2. Very specific:

    Read .libragent/tmp/doc-audit.json and review discovered gaps:

    line 30
  3. Distinctive:

    Use this priority framework:

    line 39
  4. Distinctive:

    After writing docs, run lightweight validation on modified files:

    line 72
  5. Very specific:

    Respect Git Protection (AGENTS.md): Always get explicit user confirmation before writing to docs/ or README.md.

    line 88
  6. Very specific:

    KISS & Resource Protection (GEMINI.md): Keep documentation concise and action-oriented.

    line 89
  7. Very specific:

    Update indexes: Every new doc must be linked from docs/README.md and docs/user/README.md.

    line 92

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Doc Auditor

Audit a codebase against its README.md and docs/ to find missing coverage, then generate or update documentation to close the gaps.

Workflow

Step 1 — Inventory the codebase

Run the analysis script to produce a machine-readable feature inventory:

python3 .agents/skills/doc-auditor/scripts/audit.py . --output .libragent/tmp/doc-audit.json

The script discovers:

  • Frontend features (src/features/*/)
  • Frontend lib modules (src/lib/*/ and *.ts)
  • Backend modules (src-tauri/src/*/ and *.rs)
  • Existing documentation (README*, docs/**)
  • Benchmark directories (*bench*)

Step 2 — Review the gap report

Read .libragent/tmp/doc-audit.json and review discovered gaps:

  • P0 gaps (Must fix): User-facing features/services with zero documentation (e.g., scheduled-tasks, history, browser-sidecar, session-export)
  • P1 gaps (Should fix): Features with internal/architecture specs but missing user guides (e.g., knowledge, session-isolation)
  • P2 gaps (Nice to have): Schema, validator, execution mode, or system protocol modules needing implementation docs (e.g., db-schema-validator, execution-mode)
  • P3 / Internal (Low impact): Internal utilities, shared helpers, test infrastructure (skipped or marked low priority)

Step 3 — Prioritize and plan

Use this priority framework:

PriorityCriteriaExample
P0 — Must fixUser-facing feature with zero docsscheduled-tasks/, history/, browser_sidecar/, session_export/
P1 — Should fixDocumented internally/arch but missing user guideknowledge/, session_isolation/
P2 — Nice to haveSystem/spec modules needing architecture docsdb_schema_validator, execution_mode
P3 — Low impactInternal helpers, test code, generated filesutils/, performance/, mime-utils

Step 4 — Propose plan and obtain user approval

[!IMPORTANT] Git Protection Rule (AGENTS.md): docs/, src/, src-tauri/, and README*.md are git-protected directories. DO NOT modify or create files in these directories without explicit user confirmation.

  1. Present the list of missing docs to create/update.
  2. Propose draft file paths and outline content.
  3. Ask the user for confirmation before writing protected files.

Target locations for new docs:

  • User guides → docs/user/guides/<feature>.md
  • Architecture & technical specs → docs/architecture/<topic>.md
  • API reference → docs/api/<module>.md

Target locations for index updates:

  • docs/README.md — add links to new guides/specs
  • docs/user/README.md — add to the user docs index
  • README.md — add feature descriptions and scenario references

Step 5 — Validate and report

After writing docs, run lightweight validation on modified files:

# Verify formatting and markdown structure (DO NOT run heavy full pipelines like `pnpm refactor:validate` unless explicitly requested)
pnpm lint:format

Report results in a summary table:

FileStatusLinesCoverage Category
docs/user/guides/scheduled-tasks.mdCreated180P0 (New Guide)
docs/architecture/db-schema-validator.mdCreated120P2 (Spec)
docs/user/README.mdUpdated45Index Link

Guidelines

  • Respect Git Protection (AGENTS.md): Always get explicit user confirmation before writing to docs/ or README.md.
  • KISS & Resource Protection (GEMINI.md): Keep documentation concise and action-oriented. Never execute heavy full pipelines like pnpm refactor:validate for markdown edits unless explicitly requested by the user.
  • Evidence-based: Reference actual file paths, CLI flags, and module names.
  • Don't document the obvious: Skip self-explanatory internal helpers (e.g., date-utils.ts, mime-utils.ts).
  • Update indexes: Every new doc must be linked from docs/README.md and docs/user/README.md.

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.