Project Documentation Generator
Generate complete, professional documentation structures for software projects. Automatically adapts content and structure based on project language (Python/Go), context (OpenSource/internal), and existing files.
Core Documentation Files
Always generate these five core files:
- README.md - Project overview, quick start, badges
- ARCHITECTURE.md - System design, components, data flow
- USER_GUIDE.md - Usage examples, configuration, troubleshooting
- DEVELOPER_GUIDE.md - Development setup, testing, contribution workflow
- CONTRIBUTING.md - Contribution guidelines, code standards, PR process
Workflow
1. Context Detection
Before generating docs, detect:
- Language: Scan for
go.mod, pyproject.toml, requirements.txt, setup.py
- Project type: Check for
Dockerfile, terraform/, k8s/, AI/ML indicators
- Existing docs: Identify what already exists to avoid duplication
- License: Detect from LICENSE file or ask user
- Context: Determine if OpenSource or internal based on repo structure
2. Ask Clarifying Questions
Ask user ONE question at a time to fill gaps:
- "What's the primary purpose of this project in one sentence?"
- "Who's the main audience? (developers, ops, end-users, all)"
- "Is this OpenSource or internal? (affects badges, contact info)"
- "Any company-specific tooling to mention? (Jira, Slack channels, etc.)"
3. Content Adaptation
Read references/templates.md to select appropriate template variants based on detected context.
Language-specific elements:
- Python: Package managers (
uv, pip, poetry), testing (pytest), linting (ruff, mypy)
- Go: Build commands, testing,
golangci-lint, module structure
Context-specific elements:
- OpenSource: Badges, CODE_OF_CONDUCT, security policy, community guidelines
- Internal: Slack channels, internal tools, compliance requirements, team contacts
Project type adjustments:
- AI Agents: MCP architecture, prompt patterns, example interactions
- Infrastructure: Terraform/K8s setup, deployment procedures, DR plans
- Microservices: API schemas, service mesh, health checks
- CLI Tools: Installation methods, command examples, flags
4. File Generation
Generate files in this order:
- README.md first (most visible, sets tone)
- ARCHITECTURE.md (technical foundation)
- DEVELOPER_GUIDE.md (setup and contribution)
- USER_GUIDE.md (end-user focused)
- CONTRIBUTING.md (community guidelines)
Each file must:
- Use clear headers and structure from templates
- Include concrete, runnable examples
- Reference other docs when needed (avoid duplication)
- Match project's actual structure and commands
5. Template Application
For each file:
- Select template variant from
references/templates.md
- Fill in project-specific details
- Add context-appropriate sections
- Ensure consistency across all files
6. Quality Checks
Before finalizing, verify:
- All code examples are runnable and accurate
- Commands match detected language/tooling
- Cross-references between docs are correct
- No placeholder text remains
- Tone is consistent (technical/friendly/formal based on context)
7. Output
Place all files in docs/ and use present_files to share with user.
Resources
references/templates.md
Contains complete documentation templates for all five core files with variants for:
- Python vs Go projects
- OpenSource vs internal contexts
- Different project types (agent, service, CLI, infra)
- Different complexity levels
Claude should read this file to select appropriate templates before generating docs.
Special Considerations
For AI Agent projects:
- Explain MCP server architecture
- Document tool integrations
- Show example prompts and interactions
- Include LLM configuration details
For Infrastructure/DevOps:
- Environment requirements (cloud providers, versions)
- Deployment runbooks
- Monitoring setup
- Disaster recovery procedures
For Microservices:
- API endpoint documentation
- Service dependency diagrams
- Inter-service communication patterns
- Health check and metrics endpoints
Quality Standards
Every documentation file must:
- Have table of contents for files >200 lines
- Use proper code fences with language tags
- Include "Quick Start" section at top
- Show real, tested examples
- Explain "why" decisions were made
- Use consistent terminology throughout
Avoid
- Generic placeholder text like "TODO" or "Coming soon"
- Outdated technology references
- Overly complex explanations without examples
- Duplicating content across multiple files
- Missing concrete code examples
1---2name: document-project3description: Generate comprehensive, professional project documentation structures including README, ARCHITECTURE, USER_GUIDE, DEVELOPER_GUIDE, and CONTRIBUTING files. Use when the user requests project documentation creation, asks to "document a project", needs standard documentation files, or wants to set up docs for a new repository. Adapts to Python/Go projects and OpenSource/internal contexts.4---56# Project Documentation Generator78Generate complete, professional documentation structures for software projects. Automatically adapts content and structure based on project language (Python/Go), context (OpenSource/internal), and existing files.910## Core Documentation Files1112Always generate these five core files:13141. **README.md** - Project overview, quick start, badges152. **ARCHITECTURE.md** - System design, components, data flow163. **USER_GUIDE.md** - Usage examples, configuration, troubleshooting174. **DEVELOPER_GUIDE.md** - Development setup, testing, contribution workflow185. **CONTRIBUTING.md** - Contribution guidelines, code standards, PR process1920## Workflow2122### 1. Context Detection2324Before generating docs, detect:2526- **Language**: Scan for `go.mod`, `pyproject.toml`, `requirements.txt`, `setup.py`27- **Project type**: Check for `Dockerfile`, `terraform/`, `k8s/`, AI/ML indicators28- **Existing docs**: Identify what already exists to avoid duplication29- **License**: Detect from LICENSE file or ask user30- **Context**: Determine if OpenSource or internal based on repo structure3132### 2. Ask Clarifying Questions3334Ask user ONE question at a time to fill gaps:3536- "What's the primary purpose of this project in one sentence?"37- "Who's the main audience? (developers, ops, end-users, all)"38- "Is this OpenSource or internal? (affects badges, contact info)"39- "Any company-specific tooling to mention? (Jira, Slack channels, etc.)"4041### 3. Content Adaptation4243Read `references/templates.md` to select appropriate template variants based on detected context.4445**Language-specific elements:**4647- Python: Package managers (`uv`, `pip`, `poetry`), testing (`pytest`), linting (`ruff`, `mypy`)48- Go: Build commands, testing, `golangci-lint`, module structure4950**Context-specific elements:**5152- OpenSource: Badges, CODE_OF_CONDUCT, security policy, community guidelines53- Internal: Slack channels, internal tools, compliance requirements, team contacts5455**Project type adjustments:**5657- AI Agents: MCP architecture, prompt patterns, example interactions58- Infrastructure: Terraform/K8s setup, deployment procedures, DR plans59- Microservices: API schemas, service mesh, health checks60- CLI Tools: Installation methods, command examples, flags6162### 4. File Generation6364Generate files in this order:65661. **README.md** first (most visible, sets tone)672. **ARCHITECTURE.md** (technical foundation)683. **DEVELOPER_GUIDE.md** (setup and contribution)694. **USER_GUIDE.md** (end-user focused)705. **CONTRIBUTING.md** (community guidelines)7172Each file must:7374- Use clear headers and structure from templates75- Include concrete, runnable examples76- Reference other docs when needed (avoid duplication)77- Match project's actual structure and commands7879### 5. Template Application8081For each file:82831. Select template variant from `references/templates.md`842. Fill in project-specific details853. Add context-appropriate sections864. Ensure consistency across all files8788### 6. Quality Checks8990Before finalizing, verify:9192- All code examples are runnable and accurate93- Commands match detected language/tooling94- Cross-references between docs are correct95- No placeholder text remains96- Tone is consistent (technical/friendly/formal based on context)9798### 7. Output99100Place all files in `docs/` and use `present_files` to share with user.101102## Resources103104### references/templates.md105106Contains complete documentation templates for all five core files with variants for:107108- Python vs Go projects109- OpenSource vs internal contexts110- Different project types (agent, service, CLI, infra)111- Different complexity levels112113Claude should read this file to select appropriate templates before generating docs.114115## Special Considerations116117**For AI Agent projects:**118119- Explain MCP server architecture120- Document tool integrations121- Show example prompts and interactions122- Include LLM configuration details123124**For Infrastructure/DevOps:**125126- Environment requirements (cloud providers, versions)127- Deployment runbooks128- Monitoring setup129- Disaster recovery procedures130131**For Microservices:**132133- API endpoint documentation134- Service dependency diagrams135- Inter-service communication patterns136- Health check and metrics endpoints137138## Quality Standards139140Every documentation file must:141142- Have table of contents for files >200 lines143- Use proper code fences with language tags144- Include "Quick Start" section at top145- Show real, tested examples146- Explain "why" decisions were made147- Use consistent terminology throughout148149## Avoid150151- Generic placeholder text like "TODO" or "Coming soon"152- Outdated technology references153- Overly complex explanations without examples154- Duplicating content across multiple files155- Missing concrete code examples