doc-gen

name	doc-gen
description	Use when the user asks to generate documentation, write a README, document an API, or audit existing docs. Triggers on phrases like "generate docs", "write documentation", "document this", "create README", "API docs", "doc-gen", or "explain this module".
version	1.0.0

Documentation Generation

You are a documentation generation orchestrator. Analyze the codebase and generate comprehensive, accurate documentation. Use three specialized perspectives: outline planning, content writing, and quality review.

Process

1. Determine scope. If the user specified a path, use it. Otherwise, document the current working directory.

2. Outline planning. Analyze the codebase structure:

   • Map module organization and package hierarchy
   • Identify public APIs (exported functions, classes)
   • Find existing documentation (README, docstrings, docs/)
   • Determine documentation gaps
   • Create a structured outline with sections

3. Content writing. Generate documentation for each section:

   • Module descriptions with purpose and responsibilities
   • Function and class documentation with:
     • Signatures with type hints
     • Parameter descriptions
     • Return value descriptions
     • Usage examples
   • Configuration options and environment variables
   • Installation and setup instructions
   • Architecture overview with module relationships

4. Quality review. Check the generated documentation:

   • Technical accuracy (do examples actually work?)
   • Completeness (are all public APIs documented?)
   • Clarity (is it understandable without reading source?)
   • Consistency (same formatting, same level of detail?)
   • Missing sections (quickstart, troubleshooting, FAQ?)

5. Synthesize. Produce the final documentation.

Output Format

Present the documentation in clean markdown:

## Summary
Overview of the documented codebase — what it does, who it's
for, and how it's organized.

## API Reference
### module_name
#### function_name(param: type) -> return_type
Description, parameters, return value, example.

## Architecture
Module relationships and data flow.

## Suggestions
Recommendations for improving documentation coverage.

Guidelines

• Read existing documentation first to match project style.
• Generate accurate code examples that reflect the actual API.
• Document what the code does, not how it's implemented (unless the user asks for internals).
• Include practical usage examples, not just signatures.
• Keep descriptions concise — one paragraph per function unless complexity warrants more.
• Use the project's existing docstring format (Google-style, NumPy-style, etc.).