Generate Docs

Generate Documentation

Detect Documentation Style

!find . -name "README*" -o -name "CONTRIBUTING*" -o -name "CHANGELOG*" -o -name "docs" -type d 2>/dev/null | grep -v node_modules | grep -v .git | head -10 !ls docs/ doc/ documentation/ wiki/ 2>/dev/null

Detect Code Documentation Format

!grep -r "\/\*\*" --include="*.ts" --include="*.js" --include="*.java" -l 2>/dev/null | head -3 !grep -r '"""' --include="*.py" -l 2>/dev/null | head -3 !grep -r "\/\/\/" --include="*.rs" --include="*.cs" --include="*.go" -l 2>/dev/null | head -3

Documentation Types

Type 1: README Generation

If "readme" is specified, generate a complete README.md with:

• Project name and one-line description
• Badges (build status, coverage, version — if CI is configured)
• Table of contents
• Features list
• Prerequisites and installation
• Quick start / usage examples
• Configuration options
• API reference (if applicable)
• Contributing guidelines
• License

Type 2: API Documentation

If "api" is specified:

• Find all public endpoints/routes/handlers
• Document each with: method, path, description, parameters, request body, response body, error codes
• Generate in the format matching existing docs (OpenAPI, Markdown, or inline)

Type 3: Module/File Documentation

If a file or module is specified:

• Read the code completely
• Add inline documentation following the project's convention:
  • JavaScript/TypeScript: JSDoc (/** ... */)
  • Python: Docstrings ("""...""")
  • Go: GoDoc comments (// FunctionName ...)
  • Rust: Doc comments (/// ...)
  • Java: Javadoc (/** ... */)
  • C#: XML comments (/// <summary>)
  • Ruby: YARD (# @param, # @return)

For each public function/method/class, document:

• Brief description of what it does
• Parameters with types and descriptions
• Return value with type and description
• Exceptions/errors that can be thrown
• Usage example (for complex APIs)

Type 4: Architecture Documentation

If "architecture" is specified:

• Map the high-level system components
• Create ASCII or Mermaid diagrams
• Document data flow between components
• List external dependencies and integrations
• Note key design decisions and trade-offs

Rules

• Match existing style — if the project uses JSDoc, don't add Python docstrings
• Don't over-document — skip obvious getters/setters/constructors
• Document the why — explain intent and gotchas, not just parameters
• Keep it current — documentation that lies is worse than no documentation
• Show don't tell — include usage examples for complex APIs