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: project-docs3description: 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.4license: MIT5---6
7# Project Documentation Generator
8
9Generate complete, professional documentation structures for software projects. Automatically adapts content and structure based on project language (Python/Go), context (OpenSource/internal), and existing files.
10
11## Core Documentation Files
12
13Always generate these five core files:
14
151. **README.md** - Project overview, quick start, badges
162. **ARCHITECTURE.md** - System design, components, data flow
173. **USER_GUIDE.md** - Usage examples, configuration, troubleshooting
184. **DEVELOPER_GUIDE.md** - Development setup, testing, contribution workflow
195. **CONTRIBUTING.md** - Contribution guidelines, code standards, PR process
20
21## Workflow
22
23### 1. Context Detection
24
25Before generating docs, detect:
26
27- **Language**: Scan for `go.mod`, `pyproject.toml`, `requirements.txt`, `setup.py`
28- **Project type**: Check for `Dockerfile`, `terraform/`, `k8s/`, AI/ML indicators
29- **Existing docs**: Identify what already exists to avoid duplication
30- **License**: Detect from LICENSE file or ask user
31- **Context**: Determine if OpenSource or internal based on repo structure
32
33### 2. Ask Clarifying Questions
34
35Ask user ONE question at a time to fill gaps:
36
37- "What's the primary purpose of this project in one sentence?"
38- "Who's the main audience? (developers, ops, end-users, all)"
39- "Is this OpenSource or internal? (affects badges, contact info)"
40- "Any company-specific tooling to mention? (Jira, Slack channels, etc.)"
41
42### 3. Content Adaptation
43
44Read `references/templates.md` to select appropriate template variants based on detected context.
45
46**Language-specific elements:**
47
48- Python: Package managers (`uv`, `pip`, `poetry`), testing (`pytest`), linting (`ruff`, `mypy`)
49- Go: Build commands, testing, `golangci-lint`, module structure
50
51**Context-specific elements:**
52
53- OpenSource: Badges, CODE_OF_CONDUCT, security policy, community guidelines
54- Internal: Slack channels, internal tools, compliance requirements, team contacts
55
56**Project type adjustments:**
57
58- AI Agents: MCP architecture, prompt patterns, example interactions
59- Infrastructure: Terraform/K8s setup, deployment procedures, DR plans
60- Microservices: API schemas, service mesh, health checks
61- CLI Tools: Installation methods, command examples, flags
62
63### 4. File Generation
64
65Generate files in this order:
66
671. **README.md** first (most visible, sets tone)
682. **ARCHITECTURE.md** (technical foundation)
693. **DEVELOPER_GUIDE.md** (setup and contribution)
704. **USER_GUIDE.md** (end-user focused)
715. **CONTRIBUTING.md** (community guidelines)
72
73Each file must:
74
75- Use clear headers and structure from templates
76- Include concrete, runnable examples
77- Reference other docs when needed (avoid duplication)
78- Match project's actual structure and commands
79
80### 5. Template Application
81
82For each file:
83
841. Select template variant from `references/templates.md`
852. Fill in project-specific details
863. Add context-appropriate sections
874. Ensure consistency across all files
88
89### 6. Quality Checks
90
91Before finalizing, verify:
92
93- All code examples are runnable and accurate
94- Commands match detected language/tooling
95- Cross-references between docs are correct
96- No placeholder text remains
97- Tone is consistent (technical/friendly/formal based on context)
98
99### 7. Output
100
101Place all files in `docs/` and use `present_files` to share with user.
102
103## Resources
104
105### references/templates.md
106
107Contains complete documentation templates for all five core files with variants for:
108
109- Python vs Go projects
110- OpenSource vs internal contexts
111- Different project types (agent, service, CLI, infra)
112- Different complexity levels
113
114Claude should read this file to select appropriate templates before generating docs.
115
116## Special Considerations
117
118**For AI Agent projects:**
119
120- Explain MCP server architecture
121- Document tool integrations
122- Show example prompts and interactions
123- Include LLM configuration details
124
125**For Infrastructure/DevOps:**
126
127- Environment requirements (cloud providers, versions)
128- Deployment runbooks
129- Monitoring setup
130- Disaster recovery procedures
131
132**For Microservices:**
133
134- API endpoint documentation
135- Service dependency diagrams
136- Inter-service communication patterns
137- Health check and metrics endpoints
138
139## Quality Standards
140
141Every documentation file must:
142
143- Have table of contents for files >200 lines
144- Use proper code fences with language tags
145- Include "Quick Start" section at top
146- Show real, tested examples
147- Explain "why" decisions were made
148- Use consistent terminology throughout
149
150## Avoid
151
152- Generic placeholder text like "TODO" or "Coming soon"
153- Outdated technology references
154- Overly complex explanations without examples
155- Duplicating content across multiple files
156- Missing concrete code examples