|
| 1 | +--- |
| 2 | +title: 'Audit and Update docs/ Directory' |
| 3 | +scope: 'repo' |
| 4 | +targets: |
| 5 | + - 'docs/' |
| 6 | + - 'codebase' |
| 7 | +labels: |
| 8 | + - 'documentation' |
| 9 | + - 'audit' |
| 10 | + - 'mermaid' |
| 11 | +--- |
| 12 | + |
| 13 | +Purpose: |
| 14 | +While reviewing the #activePullRequest, analyze the entire #codebase and ensure |
| 15 | +that the #file:docs directory is fully up to date, consistent, and accurate based |
| 16 | +on the current implementation. |
| 17 | + |
| 18 | +What to do: |
| 19 | + |
| 20 | +1. Audit the `docs/` directory against the real codebase |
| 21 | + - Identify documentation gaps, inaccuracies, outdated explanations, or missing sections. |
| 22 | + - Cross-check code comments, architecture, directory structure, core modules, exposed APIs, utilities, and workflows. |
| 23 | + |
| 24 | +2. Update documentation as necessary |
| 25 | + - Revise outdated sections. |
| 26 | + - Add missing content. |
| 27 | + - Rewrite unclear explanations. |
| 28 | + - Add short code snippets where they meaningfully clarify how something works. |
| 29 | + |
| 30 | +3. Use visual diagrams as frequently as appropriate |
| 31 | + - Prefer Mermaid diagrams to explain architecture, flows, relationships, state transitions, data movement, or component interactions. |
| 32 | + - Choose diagram types that best communicate the system (e.g., `flowchart`, `sequenceDiagram`, `classDiagram`, `stateDiagram`, `gitGraph`). |
| 33 | + - When explaining logic, system or architecture, include Mermaid diagrams when applicable. |
| 34 | + |
| 35 | +4. Ensure architectural accuracy |
| 36 | + - Validate that the documented behavior matches real code. |
| 37 | + - If implementation diverges from existing docs, update docs to match real behavior. |
| 38 | + |
| 39 | +5. Maintain a concise, structured writing style |
| 40 | + - Keep explanations clear and self–contained. |
| 41 | + - Avoid unnecessary verbosity. |
| 42 | + - Highlight important behaviors or assumptions explicitly. |
| 43 | + |
| 44 | +6. Make changes directly |
| 45 | + - Modify documentation files. |
| 46 | + - Add new files if needed. |
| 47 | + - Update diagrams. |
| 48 | + - Include only meaningful and defensible changes; do not generate placeholder text. |
| 49 | + |
| 50 | +Goal: |
| 51 | +Produce a clean, accurate, comprehensively updated `docs/` directory that fully |
| 52 | +reflects the current implementation, backed by diagrams and practical examples. |
| 53 | + |
| 54 | +Acceptance checklist (use as review checklist): |
| 55 | + |
| 56 | +- [ ] Audit `docs/` for correctness against actual code |
| 57 | +- [ ] Fix or update inaccurate/outdated pages |
| 58 | +- [ ] Add missing sections or examples |
| 59 | +- [ ] Add Mermaid diagrams where helpful |
| 60 | +- [ ] Ensure examples are runnable/accurate |
| 61 | +- [ ] Run repository `validate` (format, lint and testing) are passing and fix markdown lint issues. For example #file:package.json `npm run validate` |
| 62 | + |
| 63 | +Notes: |
| 64 | + |
| 65 | +- Prefer concrete changes only; avoid adding placeholders or speculative content. |
0 commit comments