Technical Writing
Creates professional technical documentation with clear structure, appropriate detail level, and user-focused content.
Workflow
1. Identify Documentation Type
Determine which type of documentation is needed:
- API Documentation - REST, GraphQL, webhooks, authentication
- User Guides - Features, how-tos, troubleshooting
- Tutorials - Learning-focused with hands-on examples
- Architecture Documents - System design, technical decisions
- README Files - Project overview, quick start
- Release Notes - Changes, migrations, breaking changes
- Technical Specifications - Requirements, constraints
For detailed templates and patterns: Load documentation-types-and-workflows.md
2. Gather Context
Collect essential information before writing:
- Audience - Developers, end-users, managers, administrators
- Technical depth - Beginner, intermediate, advanced
- Scope - Codebase/APIs/systems to document
- Standards - Style guides or organizational requirements
- Related docs - Existing documentation to reference or integrate with
3. Structure Content
Apply clear organization principles:
- Lead with overview/introduction
- Use descriptive heading hierarchy (H1 → H2 → H3)
- Include table of contents for documents with >3 sections
- Group related information logically
- Place examples immediately after concepts
- Add diagrams/visuals for complex workflows
4. Write Clear Content
Follow core writing principles:
- Active voice - "The API returns..." not "The response is returned..."
- Specificity - "Response time < 200ms" not "Fast response"
- Define acronyms - "API (Application Programming Interface)" on first use
- Consistent terminology - Same terms throughout document
- Imperative instructions - "Run the command" not "You should run..."
- Show examples - Provide code/output for every concept
For comprehensive style guidance: Load writing-guidelines.md
5. Add Code Examples
Code example requirements:
- Specify language in code blocks:
python,javascript
- Show complete, runnable examples (not fragments)
- Include input/output pairs
- Add explanatory comments for complex logic
- Test all code before publishing
6. Review and Validate
Quality assurance checklist:
- ✓ Verify technical accuracy
- ✓ Test all code examples
- ✓ Check clarity and completeness
- ✓ Ensure consistent terminology
- ✓ Validate all links and references
Documentation Templates
README Files
Essential components for project documentation:
# Project Name
Brief description of what the project does
## Features
- Key feature 1
- Key feature 2
- Key feature 3
## Installation
[step-by-step installation commands]
## Quick Start
[minimal working example]
## Configuration
[environment variables or config options]
## License
[license type]
Release Notes
Structure for version releases:
# Version X.X.X - YYYY-MM-DD
## Summary
[High-level overview of this release]
## New Features
- Feature description (#issue-number)
- Feature description (#issue-number)
## Bug Fixes
- Fix description (#issue-number)
- Fix description (#issue-number)
## Breaking Changes
⚠️ **Change that breaks compatibility**
Migration guide: [step-by-step migration instructions]
## Deprecations
- Deprecated feature (will be removed in vX.X)
Quality Standards
Documentation quality checklist before publishing:
Common Pitfalls to Avoid
- Assuming knowledge - Define all acronyms and technical terms
- Vague instructions - Be specific with concrete examples
- Missing error scenarios - Document errors and solutions
- Outdated examples - Test and update code regularly
- Inconsistent terminology - Use identical terms throughout
- Missing prerequisites - List all requirements upfront
- Poor formatting - Use headings, lists, code blocks properly
- No examples - Always include working code samples
- Wrong audience level - Match technical depth to readers
- Dense text - Break into scannable sections with clear headings
Reference Files
- documentation-types-and-workflows.md - Complete templates and patterns for API docs, user guides, tutorials, architecture docs, and technical specifications
- writing-guidelines.md - Detailed style rules for clarity, active voice, specificity, consistency, heading hierarchy, code formatting, and lists
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: technical-writing-93description: Creates high-quality technical documentation including API documentation, user guides, tutorials, architecture documents, README files, release notes, and technical specifications. Produces clear, structured, and comprehensive documentation following industry best practices. Use when writing technical documentation, creating API docs, developing user guides, documenting architecture, writing tutorials, preparing release notes, or when users mention "technical writing", "documentation", "API docs", "user guide", "tutorial", "README", "technical specification", "architecture document", or "developer documentation".4---56# Technical Writing78Creates professional technical documentation with clear structure, appropriate detail level, and user-focused content.910## Workflow1112## 1. Identify Documentation Type1314Determine which type of documentation is needed:1516- **API Documentation** - REST, GraphQL, webhooks, authentication17- **User Guides** - Features, how-tos, troubleshooting18- **Tutorials** - Learning-focused with hands-on examples19- **Architecture Documents** - System design, technical decisions20- **README Files** - Project overview, quick start21- **Release Notes** - Changes, migrations, breaking changes22- **Technical Specifications** - Requirements, constraints2324**For detailed templates and patterns:** Load [documentation-types-and-workflows.md](references/documentation-types-and-workflows.md)2526### 2. Gather Context2728Collect essential information before writing:2930- **Audience** - Developers, end-users, managers, administrators31- **Technical depth** - Beginner, intermediate, advanced32- **Scope** - Codebase/APIs/systems to document33- **Standards** - Style guides or organizational requirements34- **Related docs** - Existing documentation to reference or integrate with3536### 3. Structure Content3738Apply clear organization principles:3940- Lead with overview/introduction41- Use descriptive heading hierarchy (H1 → H2 → H3)42- Include table of contents for documents with >3 sections43- Group related information logically44- Place examples immediately after concepts45- Add diagrams/visuals for complex workflows4647### 4. Write Clear Content4849Follow core writing principles:5051- **Active voice** - "The API returns..." not "The response is returned..."52- **Specificity** - "Response time < 200ms" not "Fast response"53- **Define acronyms** - "API (Application Programming Interface)" on first use54- **Consistent terminology** - Same terms throughout document55- **Imperative instructions** - "Run the command" not "You should run..."56- **Show examples** - Provide code/output for every concept5758**For comprehensive style guidance:** Load [writing-guidelines.md](references/writing-guidelines.md)5960### 5. Add Code Examples6162Code example requirements:6364- Specify language in code blocks: ```python,```javascript65- Show complete, runnable examples (not fragments)66- Include input/output pairs67- Add explanatory comments for complex logic68- Test all code before publishing6970### 6. Review and Validate7172Quality assurance checklist:7374- ✓ Verify technical accuracy75- ✓ Test all code examples76- ✓ Check clarity and completeness77- ✓ Ensure consistent terminology78- ✓ Validate all links and references7980## Documentation Templates8182### README Files8384Essential components for project documentation:8586```markdown87# Project Name88Brief description of what the project does8990## Features91- Key feature 192- Key feature 293- Key feature 39495## Installation96[step-by-step installation commands]9798## Quick Start99[minimal working example]100101## Configuration102[environment variables or config options]103104## License105[license type]106```107108### Release Notes109110Structure for version releases:111112```markdown113# Version X.X.X - YYYY-MM-DD114115## Summary116[High-level overview of this release]117118## New Features119- Feature description (#issue-number)120- Feature description (#issue-number)121122## Bug Fixes123- Fix description (#issue-number)124- Fix description (#issue-number)125126## Breaking Changes127⚠️ **Change that breaks compatibility**128Migration guide: [step-by-step migration instructions]129130## Deprecations131- Deprecated feature (will be removed in vX.X)132```133134## Quality Standards135136Documentation quality checklist before publishing:137138- [ ] **Accuracy** - All technical details are correct139- [ ] **Completeness** - All necessary topics covered140- [ ] **Clarity** - Target audience can understand content141- [ ] **Examples** - Working code included and tested142- [ ] **Structure** - Logical organization with clear headings143- [ ] **Consistency** - Terminology and formatting consistent144- [ ] **Links** - All hyperlinks are valid145- [ ] **Grammar** - No spelling or grammatical errors146- [ ] **Current** - Version numbers and dates up-to-date147148## Common Pitfalls to Avoid1491501. **Assuming knowledge** - Define all acronyms and technical terms1512. **Vague instructions** - Be specific with concrete examples1523. **Missing error scenarios** - Document errors and solutions1534. **Outdated examples** - Test and update code regularly1545. **Inconsistent terminology** - Use identical terms throughout1556. **Missing prerequisites** - List all requirements upfront1567. **Poor formatting** - Use headings, lists, code blocks properly1578. **No examples** - Always include working code samples1589. **Wrong audience level** - Match technical depth to readers15910. **Dense text** - Break into scannable sections with clear headings160161## Reference Files162163- **[documentation-types-and-workflows.md](references/documentation-types-and-workflows.md)** - Complete templates and patterns for API docs, user guides, tutorials, architecture docs, and technical specifications164- **[writing-guidelines.md](references/writing-guidelines.md)** - Detailed style rules for clarity, active voice, specificity, consistency, heading hierarchy, code formatting, and lists165166---167> Converted and distributed by [TomeVault](https://tomevault.io/claim/dauquangthanh) — claim your Tome and manage your conversions.168<!-- tomevault:4.0:skill_md:2026-04-11 -->