1---2name: codebase-documenter3description: Scaffold project documentation (README, ARCHITECTURE, API, CODE_COMMENTS) from templates with documented standards. Use when bootstrapping docs for a new or under-documented codebase.4license: MIT5---67# Codebase Documenter89Generate documentation scaffolding for a project that has none, or has the wrong shape. This skill produces structured starters with bracketed placeholders the team fills in. It does not write prose for you.1011## Triggers1213| Trigger Phrase | Operation |14|----------------|-----------|15| `scaffold project documentation` | Generate README, ARCHITECTURE, API, code comment scaffolds |16| `bootstrap docs for new codebase` | Produce starter docs with placeholders |17| `add starter README` | Create README scaffold only |18| `set up documentation standards` | Drop standards references into the repo |19| `document this codebase from scratch` | Full scaffold pass |2021## When to Use2223Use this skill when:2425- A repository has no `README.md`, `ARCHITECTURE.md`, or API reference, and you need a populated skeleton.26- A team is onboarding without a tech writer and wants documented standards alongside the templates.27- You need a starting point for code-comment conventions in a polyglot project.2829Use a different skill when:3031- Documentation already exists and you want to verify accuracy, detect missing XML docs / docstrings / JSDoc, or audit README / CLAUDE.md drift. Use `doc-accuracy` for verification, missing-doc detection, and structural sync.32- You want narrative prose generated for an existing component. Use the `explainer` agent.3334## Boundaries3536- Writes scaffolding and standards references only. Does not write narrative prose for the project.37- Placeholders use bracket convention `[Like this]` so a writer can search and replace.38- Templates must be filled in by a human or downstream skill. The skill does not infer project specifics.3940## Process41421. Confirm the target directory and confirm no overwrite of existing docs without explicit user consent.432. Copy `assets/templates/README.template.md` to `README.md` (or path the user requests).443. Copy `assets/templates/ARCHITECTURE.template.md` to `ARCHITECTURE.md` if a separate architecture doc is wanted.454. Create parent directories (`docs/`, `docs/standards/`, or any user-requested path) before any copy step that targets them.465. Copy `assets/templates/API.template.md` to `docs/API.md` (or equivalent) if the project exposes an API.476. Copy `assets/templates/CODE_COMMENTS.template.md` to `docs/standards/CODE_COMMENTS.md` (or link from the README).487. Point the team at `references/documentation_guidelines.md` and `references/visual_aids_guide.md` for voice and visual standards.4950## Templates5152| Template | Purpose |53|----------|---------|54| `assets/templates/README.template.md` | Project front door. Why, quick start, structure, common tasks, troubleshooting. |55| `assets/templates/ARCHITECTURE.template.md` | System overview, components, data flow, decisions, failure modes. |56| `assets/templates/API.template.md` | API reference per endpoint with conventions and examples. |57| `assets/templates/CODE_COMMENTS.template.md` | Docstring and inline comment standards across languages. |5859## References6061| Reference | Purpose |62|-----------|---------|63| `references/documentation_guidelines.md` | Voice, structure, audience framing, placeholder convention. |64| `references/visual_aids_guide.md` | When and how to use diagrams, tables, callouts. |6566## Verification Checklist6768- [ ] No environment-specific paths in any template69- [ ] All user-provided paths are validated against path traversal70- [ ] Bracketed placeholders match the `[Word or short phrase]` convention71- [ ] Code fences are balanced and use language identifiers on the opener only72- [ ] Voice is active, audience is the project's reader (not the documenter)73- [ ] No marketing language, weasel words, or filler74- [ ] Diagrams added only when they reduce ambiguity (see `references/visual_aids_guide.md`)7576## Anti-Patterns7778| Avoid | Why | Instead |79|-------|-----|---------|80| Filling in placeholders speculatively | Produces fiction the team will rediscover and rewrite | Leave brackets; team fills in |81| Copying README content into ARCHITECTURE | Both files drift; readers cannot tell which is current | One concept per document |82| Adding diagrams for every section | Visual noise distracts from text | Diagram only where ambiguity is real |83| Long preamble before quick start | Readers leave before they reach the value | Quick start in the first screen |
rjmurillo