--- name: technical-documentation description: Comprehensive technical documentation skill for creating clear, accurate, and user-centered documentation across all formats including API docs, user guides, developer documentation, knowledge bases, and system documentation. This skill should be used when creating, organizing, or maintaining technical documentation that explains complex systems, procedures, or concepts to various technical and non-technical audiences. --- # Technical Documentation ## Overview This skill provides frameworks and methodologies for creating technical documentation that is accurate, accessible, and actionable. It covers the full spectrum from API references to end-user guides, emphasizing clarity, completeness, and continuous maintenance. ## Documentation Type Decision Tree To determine the appropriate documentation approach: ``` What are you documenting? ├── API/CODE │ ├── REST/GraphQL API → Use "API Documentation" │ ├── SDK/Library → Use "SDK Documentation" │ ├── Code Functions → Use "Code Documentation" │ └── Architecture → Use "System Design Docs" ├── USER-FACING │ ├── End User Guide → Use "User Documentation" │ ├── Admin Guide → Use "Administrator Docs" │ ├── Tutorials → Use "Tutorial Documentation" │ └── FAQ/KB → Use "Knowledge Base Articles" ├── DEVELOPER-FACING │ ├── Setup/Install → Use "Getting Started Guides" │ ├── Contributing → Use "Contribution Guidelines" │ ├── Architecture → Use "Technical Specifications" │ └── Troubleshooting → Use "Debug Documentation" └── PROCESS/OPERATIONS ├── Runbooks → Use "Operational Runbooks" ├── Deployment → Use "Deployment Guides" ├── Incident Response → Use "Incident Playbooks" └── Release Notes → Use "Release Documentation" ``` ## Core Documentation Principles ### The Four C's of Technical Documentation 1. **Clear** - Unambiguous and easy to understand 2. **Concise** - No unnecessary words or complexity 3. **Correct** - Technically accurate and tested 4. **Complete** - All necessary information included ### Documentation-First Development Write documentation: - **Before coding** - Design docs and specifications - **During coding** - Inline comments and updates - **After coding** - Final polish and examples - **Continuously** - Updates with each change ### Audience-Centered Approach Always consider: - **Who** is reading this documentation? - **What** do they need to accomplish? - **When** will they read it (setup, troubleshooting, learning)? - **Where** are they in their journey (beginner to expert)? - **Why** do they need this information? - **How** will they use it? ## API Documentation ### OpenAPI/Swagger Structure ```yaml # API Endpoint Documentation Template endpoint: path: /api/v1/resource/{id} method: GET|POST|PUT|DELETE summary: Brief description (one line) description: | Detailed explanation of what this endpoint does, when to use it, and any important considerations. parameters: - name: id in: path|query|header|cookie required: true|false schema: type: string|number|boolean format: uuid|email|date description: What this parameter does example: "123e4567-e89b-12d3-a456-426614174000" requestBody: required: true|false content: application/json: schema: type: object properties: field1: type: string description: Purpose of this field example: field1: "value" responses: 200: description: Successful response content: application/json: schema: $ref: '#/components/schemas/Resource' 400: description: Bad request - invalid parameters 401: description: Unauthorized - invalid or missing auth 404: description: Not found - resource doesn't exist 500: description: Server error - something went wrong security: - bearerAuth: [] - apiKey: [] ``` ### API Documentation Best Practices #### Request Examples Provide examples in multiple formats: ```bash # cURL curl -X POST https://api.example.com/v1/users \ -H "Authorization: Bearer YOUR_TOKEN" \ -H "Content-Type: application/json" \ -d '{"name": "John Doe", "email": "john@example.com"}' # JavaScript/Fetch const response = await fetch('https://api.example.com/v1/users', { method: 'POST', headers: { 'Authorization': 'Bearer YOUR_TOKEN', 'Content-Type': 'application/json' }, body: JSON.stringify({ name: 'John Doe', email: 'john@example.com' }) }); # Python/Requests import requests response = requests.post( 'https://api.example.com/v1/users', headers={ 'Authorization': 'Bearer YOUR_TOKEN', 'Content-Type': 'application/json' }, json={ 'name': 'John Doe', 'email': 'john@example.com' } ) ``` #### Response Examples Show both successful and error responses: ```json // Success Response (200 OK) { "id": "123e4567-e89b-12d3-a456-426614174000", "name": "John Doe", "email": "john@example.com", "created_at": "2024-01-15T09:30:00Z", "updated_at": "2024-01-15T09:30:00Z" } // Error Response (400 Bad Request) { "error": { "code": "INVALID_EMAIL", "message": "The email address provided is not valid", "field": "email", "details": "Email must be a valid email address format" } } ``` ### SDK Documentation Pattern ```markdown ## Installation ### npm \`\`\`bash npm install @company/sdk \`\`\` ### yarn \`\`\`bash yarn add @company/sdk \`\`\` ## Quick Start \`\`\`javascript import { Client } from '@company/sdk'; // Initialize the client const client = new Client({ apiKey: 'YOUR_API_KEY', baseUrl: 'https://api.example.com' // Optional }); // Make your first request const users = await client.users.list(); console.log(users); \`\`\` ## Authentication The SDK supports multiple authentication methods: ### API Key Authentication \`\`\`javascript const client = new Client({ apiKey: 'YOUR_API_KEY' }); \`\`\` ### OAuth 2.0 \`\`\`javascript const client = new Client({ clientId: 'YOUR_CLIENT_ID', clientSecret: 'YOUR_CLIENT_SECRET', redirectUri: 'http://localhost:3000/callback' }); // Get authorization URL const authUrl = client.auth.getAuthorizationUrl(); // Exchange code for token const token = await client.auth.exchangeCode(code); \`\`\` ``` ## User Documentation ### Structure for User Guides #### Getting Started Section ```markdown # Getting Started with [Product Name] ## What You'll Learn By the end of this guide, you'll be able to: - [ ] Set up your account - [ ] Complete your first task - [ ] Understand core concepts - [ ] Know where to find help ## Prerequisites Before you begin, make sure you have: - An account (sign up at [link]) - Required permissions (see [permissions guide]) - System requirements met (see [requirements]) ## Step 1: Initial Setup [Clear, numbered steps with screenshots] ## Step 2: Your First Task [Guided walkthrough of common task] ## What's Next? - Explore [advanced features] - Read [best practices] - Join [community] ``` #### Task-Based Documentation Structure documentation around what users want to do: ```markdown # How to [Accomplish Task] ## Before You Begin - Time required: ~X minutes - Prerequisites: [list] - Permissions needed: [list] ## Steps ### 1. [First Action] [Screenshot or diagram] **To [action]:** 1. Navigate to [location] 2. Click [button/link] 3. Enter [information] > **Note:** [Important information] > **Tip:** [Helpful suggestion] > **Warning:** [Potential issue to avoid] ### 2. [Second Action] [Continue pattern] ## Troubleshooting ### Problem: [Common Issue] **Symptoms:** What the user sees **Cause:** Why it happens **Solution:** How to fix it ## Related Topics - [Link to related task] - [Link to concept explanation] - [Link to reference] ``` ### Progressive Disclosure Pattern Organize information from simple to complex: ```markdown ## Overview (Everyone reads) Brief explanation in plain language. ## Basic Usage (Most users read) Common use cases with examples.
Advanced Configuration (Some users read) Detailed configuration options and edge cases.
Technical Details (Few users read) Implementation details, performance considerations, etc.
``` ## Developer Documentation ### README Template ```markdown # Project Name Brief description of what this project does and who it's for. ## Features - ✨ Feature 1 - 🚀 Feature 2 - 💡 Feature 3 ## Installation ### Requirements - Requirement 1 (version X.X+) - Requirement 2 ### Setup \`\`\`bash # Clone the repository git clone https://github.com/username/project.git # Navigate to project directory cd project # Install dependencies npm install # Run the application npm start \`\`\` ## Usage ### Basic Example \`\`\`javascript import { Module } from 'project'; const instance = new Module(); instance.doSomething(); \`\`\` ### Advanced Example \`\`\`javascript // More complex usage \`\`\` ## Configuration | Option | Type | Default | Description | |--------|------|---------|-------------| | option1 | string | 'default' | What this does | | option2 | boolean | false | When to use this | ## API Reference ### `methodName(param1, param2)` Description of what this method does. **Parameters:** - `param1` (Type): Description - `param2` (Type): Description **Returns:** Type - Description **Example:** \`\`\`javascript const result = methodName('value1', 'value2'); \`\`\` ## Contributing See [CONTRIBUTING.md](CONTRIBUTING.md) for details. ## License This project is licensed under the MIT License - see [LICENSE](LICENSE) file. ``` ### Architecture Documentation ```markdown # System Architecture ## Overview [High-level architecture diagram] Brief description of the system and its purpose. ## Components ### Component 1: [Name] **Purpose:** What this component does **Technology:** Languages, frameworks used **Dependencies:** What it depends on **Interface:** How it communicates ### Component 2: [Name] [Continue pattern] ## Data Flow 1. **Step 1:** User initiates action 2. **Step 2:** Request processed by [component] 3. **Step 3:** Data retrieved from [source] 4. **Step 4:** Response returned to user [Sequence diagram showing flow] ## Design Decisions ### Decision: [Technology/Pattern Choice] **Context:** The situation that required a decision **Options Considered:** 1. Option A - Pros/Cons 2. Option B - Pros/Cons **Decision:** What was chosen and why **Consequences:** Impact of this decision ## Security Considerations - Authentication: How users are verified - Authorization: How permissions are managed - Data Protection: How sensitive data is handled - Audit Logging: What is logged and where ## Performance Considerations - Caching Strategy: What, where, TTL - Load Balancing: Method and configuration - Scaling Approach: Horizontal vs Vertical - Bottlenecks: Known issues and mitigation ## Deployment ### Environments - Development: Configuration and purpose - Staging: Configuration and purpose - Production: Configuration and purpose ### Infrastructure - Hosting: Where and how - CI/CD: Pipeline and process - Monitoring: Tools and metrics - Backup: Strategy and frequency ``` ## Knowledge Base Articles ### Problem-Solution Format ```markdown # Error: [Specific Error Message] ## Symptoms What the user experiences when this error occurs. ## Cause Technical explanation of why this happens. ## Solution ### Quick Fix Immediate steps to resolve the issue: 1. Step one 2. Step two 3. Step three ### Permanent Solution Long-term fix to prevent recurrence: 1. Configuration change 2. System update 3. Process improvement ## Prevention How to avoid this issue in the future. ## Related Articles - [Link to similar issue] - [Link to underlying concept] ``` ### FAQ Format ```markdown # Frequently Asked Questions ## General Questions ### Q: What is [Product/Feature]? **A:** Clear, concise answer in 2-3 sentences. ### Q: How much does it cost? **A:** Pricing information with link to full pricing page. ## Technical Questions ### Q: What are the system requirements? **A:** - **Minimum:** List minimum requirements - **Recommended:** List recommended specs - **Optimal:** List best performance specs ### Q: Is my data secure? **A:** Security explanation with specifics about: - Encryption methods - Compliance certifications - Data handling policies ## Troubleshooting ### Q: Why isn't [feature] working? **A:** Common causes and solutions: 1. **Cause 1:** Solution 2. **Cause 2:** Solution 3. **Still having issues?** [Contact support link] ``` ## Documentation Formats and Tools ### Markdown Best Practices ```markdown # Use Semantic Headers Don't skip header levels. Use h1 → h2 → h3 in order. ## Format Code Properly Inline code: `const variable = "value"` Code blocks with language hints: \`\`\`javascript // This enables syntax highlighting const example = true; \`\`\` ## Create Clear Tables | Column 1 | Column 2 | Column 3 | |:---------|:--------:|---------:| | Left | Center | Right | | Aligned | Aligned | Aligned | ## Use Emphasis Wisely - **Bold** for important terms first mention - *Italic* for emphasis or introducing terms - `code` for commands, file names, values - > Blockquotes for important notes ## Link Meaningfully Good: [View the API documentation](link) Bad: [Click here](link) for documentation ## Include Visual Aids ![Alt text for accessibility](image.png) *Figure 1: Caption explaining the image* ``` ### Documentation Site Structure ``` docs/ ├── getting-started/ │ ├── installation.md │ ├── quick-start.md │ └── first-steps.md ├── guides/ │ ├── beginner/ │ ├── intermediate/ │ └── advanced/ ├── reference/ │ ├── api/ │ ├── cli/ │ ├── configuration/ │ └── glossary.md ├── tutorials/ │ ├── tutorial-1.md │ └── tutorial-2.md ├── troubleshooting/ │ ├── common-issues.md │ └── error-codes.md └── contributing/ ├── code-of-conduct.md ├── development-setup.md └── pull-requests.md ``` ## Version Control for Documentation ### Versioning Strategy ```markdown # Documentation Versions ## Version Numbering - v1.0.0 - Major version (breaking changes) - v1.1.0 - Minor version (new features) - v1.1.1 - Patch version (bug fixes) ## Version Banner > **Note:** You are viewing documentation for v2.0. > For v1.x documentation, see [here](link). ## Deprecation Notices > **Deprecated:** This feature will be removed in v3.0. > Use [alternative feature] instead. > Migration guide: [link] ## Changelog Integration ### Version 2.1.0 (2024-01-15) #### Added - New feature documentation - Additional examples #### Changed - Updated API endpoint descriptions - Improved error messages #### Fixed - Corrected typos in examples - Fixed broken links #### Removed - Deprecated v1 endpoints ``` ## Quality Checklist ### Pre-Publication Review #### Content Quality - [ ] Technically accurate and tested - [ ] Complete (no TODO or TBD remaining) - [ ] Clear and concise writing - [ ] Appropriate for target audience - [ ] Examples work as written - [ ] Screenshots current and annotated #### Structure and Organization - [ ] Logical flow and organization - [ ] Consistent formatting - [ ] Proper header hierarchy - [ ] Table of contents for long docs - [ ] Cross-references working - [ ] Navigation clear #### Language and Style - [ ] Active voice predominant - [ ] Present tense for current state - [ ] Consistent terminology - [ ] No jargon without explanation - [ ] Spell-checked - [ ] Grammar-checked #### Technical Elements - [ ] Code examples syntax-highlighted - [ ] Commands copy-pasteable - [ ] API endpoints accurate - [ ] Version numbers correct - [ ] Links validated - [ ] Images optimized #### Accessibility - [ ] Alt text for images - [ ] Descriptive link text - [ ] Color not sole indicator - [ ] Keyboard navigation works - [ ] Screen reader friendly - [ ] Mobile responsive ### Documentation Maintenance #### Regular Updates - **Weekly:** Fix reported issues - **Monthly:** Review analytics, update FAQs - **Quarterly:** Audit for accuracy - **Annually:** Major reorganization #### Feedback Integration 1. Monitor support tickets for doc gaps 2. Track documentation analytics 3. Conduct user surveys 4. Run documentation usability tests 5. Implement feedback systematically ## Style Guide ### Writing Style #### Voice and Tone - **Active:** "Configure the server" not "The server should be configured" - **Direct:** "You must" not "It is required that you" - **Friendly:** Professional but approachable - **Inclusive:** Avoid assumptions about expertise #### Word Choice - Use simple words when possible - Define technical terms on first use - Be consistent with terminology - Avoid colloquialisms and idioms - Spell out acronyms initially #### Sentence Structure - Keep sentences under 25 words - One idea per sentence - Use bullet points for lists - Break up long paragraphs - Start with the most important information ### Formatting Conventions #### Capitalization - Sentence case for headers - Title case for product names - lowercase for commands and code - UPPERCASE for environment variables #### Punctuation - Oxford comma in lists - No period in headers - Colon before code blocks - Semicolon sparingly #### Special Elements - **Note:** Additional helpful information - **Tip:** Best practice or shortcut - **Important:** Critical information - **Warning:** Potential problems - **Danger:** Data loss or security risk ## Resources ### Scripts - `scripts/doc_validator.py` - Validates documentation structure and links - `scripts/api_doc_generator.py` - Generates API docs from code comments - `scripts/changelog_builder.py` - Creates changelog from git commits ### References - `references/style_guide.md` - Complete documentation style guide - `references/template_library.md` - Documentation templates for all types - `references/markdown_cheatsheet.md` - Quick reference for markdown syntax - `references/diagramming_guide.md` - How to create effective technical diagrams ### Assets - `assets/templates/api_reference.md` - API documentation template - `assets/templates/user_guide.md` - User guide template - `assets/templates/readme.md` - README template - `assets/templates/troubleshooting.md` - Troubleshooting guide template