Generate Docs

---
name: generate-docs
description: "Generates documentation matching the project's style — README files, API docs, inline documentation, or architecture docs. Auto-detects the documentation format in use."
argument-hint: "[file, module, 'readme', or 'api']"
allowed-tools: Read, Grep, Glob, Bash, Write
---

# 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