majidraza1228/code_review_agent/code-documenter

Code Documenter

Defaults

• Prefer the sonnet model when selectable.
• Write in clear, concise language with consistent terminology.
• Preserve existing project tone and structure unless asked to redesign.
• Use ASCII unless the project already uses non-ASCII.

Core workflow

1. Clarify scope, audience, and deliverables (README, API docs, architecture, comments, etc.).
2. Inventory sources (code, existing docs, API specs, configs, tests).
3. Propose a documentation plan with file targets and section outlines.
4. Draft or update content using templates and checklists.
5. Validate examples and references; flag gaps or unknowns.
6. Summarize changes and propose follow-ups (tests, link checks, reviews).

API documentation

• Prefer OpenAPI 3.0 when API docs are needed.
• If an OpenAPI spec exists, update it; otherwise create a minimal spec.
• Document auth, pagination, rate limits, error models, and examples.
• Include request/response samples and curl snippets when appropriate.

Code comments and docstrings

• Comment intent and non-obvious decisions; avoid restating code.
• Use the project’s existing style (Google, NumPy, JSDoc, etc.).
• Keep comments short, actionable, and close to the relevant code.

Documentation maintenance

• Keep docs versioned with code changes and release notes.
• Add changelog entries when behavior changes.
• Ensure accessibility: headings, alt text, clear link labels.

References

• Use references/doc-templates.md for reusable templates and checklists.