Write clear, comprehensive technical documentation. Use when creating specs, architecture docs, runbooks, or API documentation. Handles technical specifications, system design docs, operational guides, and developer documentation with industry best practices.
68
54%
Does it follow best practices?
Impact
93%
1.22xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agent-skills/technical-writing/SKILL.mdDeveloper audience:
DevOps/Operations audience:
Manager/Stakeholder audience:
End user audience:
Technical Specification:
# [Feature Name] Technical Specification
## Overview
Brief description of what this spec covers
## Problem Statement
What problem are we solving?
## Goals and Non-Goals
### Goals
- Goal 1
- Goal 2
### Non-Goals
- What we're explicitly not doing
## Solution Design
### High-Level Architecture
### Data Models
### API Contracts
### User Interface
## Implementation Plan
### Phase 1
### Phase 2
## Testing Strategy
## Security Considerations
## Performance Considerations
## Monitoring and Alerting
## Rollout Plan
## Rollback Plan
## Open Questions
## ReferencesArchitecture Document:
# System Architecture
## Overview
High-level system description
## Architecture Diagram
[Insert diagram]
## Components
### Component 1
- Responsibility
- Technology stack
- Interfaces
### Component 2
...
## Data Flow
How data moves through the system
## Key Design Decisions
### Decision 1
- Context
- Options considered
- Decision made
- Rationale
## Technology Stack
- Frontend: React, TypeScript
- Backend: Python, FastAPI
- Database: PostgreSQL
- Infrastructure: AWS, Docker, Kubernetes
## Scalability
How the system scales
## Security
Authentication, authorization, data protection
## Monitoring and Observability
Metrics, logs, tracing
## Disaster Recovery
Backup and recovery procedures
## Future ConsiderationsRunbook:
# [Service Name] Runbook
## Service Overview
What this service does
## Dependencies
- Service A
- Service B
- Database X
## Deployment
### How to deploy
```bash
./deploy.sh production./rollback.shSymptoms: Response time > 1s Diagnosis: Check database connection pool Resolution: Restart service or scale up
Symptoms: Memory usage growing over time Diagnosis: Check heap dump Resolution: Restart service, investigate in staging
kubectl logs -f deployment/service-namecurl https://api/metrics**API Documentation**:
```markdown
# API Documentation
## Authentication
All requests require authentication:
```bash
curl -H "Authorization: Bearer YOUR_TOKEN" \
https://api.example.com/endpointGET /api/v1/usersParameters:
| Name | Type | Required | Description |
|---|---|---|---|
| page | integer | No | Page number (default: 1) |
| limit | integer | No | Items per page (default: 20) |
Example Request:
curl -X GET "https://api.example.com/api/v1/users?page=1&limit=20" \
-H "Authorization: Bearer YOUR_TOKEN"Example Response:
{
"data": [
{
"id": 1,
"name": "John Doe",
"email": "john@example.com"
}
],
"pagination": {
"page": 1,
"limit": 20,
"total": 100
}
}Error Responses:
| Status | Description |
|---|---|
| 400 | Bad Request |
| 401 | Unauthorized |
| 500 | Server Error |
### Step 3: Writing guidelines
**Clarity**:
- Use simple, direct language
- One idea per sentence
- Short paragraphs (3-5 sentences)
- Define technical terms
- Avoid jargon when possible
**Structure**:
- Use hierarchical headings (H1, H2, H3)
- Break content into sections
- Use lists for multiple items
- Use tables for structured data
- Add table of contents for long docs
**Examples**:
- Include code examples
- Provide diagrams
- Show before/after comparisons
- Real-world scenarios
**Completeness**:
- Cover prerequisites
- Include error handling
- Document edge cases
- Explain why, not just how
- Link to related docs
**Consistency**:
- Consistent terminology
- Consistent formatting
- Consistent code style
- Consistent structure
### Step 4: Visual aids
**Architecture diagrams** (Mermaid):
```mermaid
graph TB
A[Client] -->|HTTP| B[Load Balancer]
B --> C[Web Server 1]
B --> D[Web Server 2]
C --> E[Database]
D --> ESequence diagrams:
sequenceDiagram
Client->>+Server: Request
Server->>+Database: Query
Database-->>-Server: Data
Server-->>-Client: ResponseFlowcharts:
flowchart TD
A[Start] --> B{Is valid?}
B -->|Yes| C[Process]
B -->|No| D[Error]
C --> E[End]
D --> ECode blocks with syntax highlighting:
def calculate_total(items: List[Item]) -> Decimal:
"""Calculate total price of items."""
return sum(item.price for item in items)Screenshots:
Tables:
| Parameter | Type | Default | Description |
|---|---|---|---|
| timeout | int | 30 | Request timeout in seconds |
| retries | int | 3 | Number of retry attempts |
Self-review checklist:
Get feedback:
Maintain documentation:
# [Feature Name] Technical Spec
**Author**: [Your Name]
**Date**: [Date]
**Status**: [Draft/Review/Approved]
## Overview
[1-2 paragraphs describing what this document covers]
## Background
[Context and motivation]
## Goals
- Goal 1
- Goal 2
## Non-Goals
- What we're not doing
## Detailed Design
[Technical details]
## Alternatives Considered
[Other approaches and why we didn't choose them]
## Timeline
- Week 1: ...
- Week 2: ...
## Open Questions
- Question 1
- Question 2
## Features
- Feature 1
- Feature 2
## Installation
### Prerequisites
- Node.js >= 14
- npm >= 6
### Setup
```bash
git clone https://github.com/user/project.git
cd project
npm installnpm startEnvironment variables:
API_KEY: Your API keyPORT: Server port (default: 3000)npm run dev
npm test[Deployment instructions]
[Contributing guidelines]
MIT
### Changelog Template
```markdown
# Changelog
## [1.2.0] - 2024-01-15
### Added
- New feature X
- Support for Y
### Changed
- Improved performance of Z
- Updated dependency A to v2.0
### Fixed
- Bug where user couldn't login
- Memory leak in background task
### Deprecated
- Old API endpoint /v1/users (use /v2/users)
### Removed
- Legacy authentication method
### Security
- Fixed XSS vulnerability in comments
## [1.1.0] - 2024-01-01
...✅ Good: "The system sends a notification"
❌ Bad: "A notification is sent by the system"✅ Good: "Click Save to save changes"
❌ Bad: "In order to save your changes, you should click on the Save button"✅ Good:
"Set the timeout in seconds:
```yaml
timeout: 30❌ Bad: "Configure the timeout parameter appropriately"
### Break down complexity✅ Good: "To deploy:
❌ Bad: "Deploy by building and pushing the image to the registry, then update the deployment and verify the rollout succeeded"
## Common mistakes to avoid
1. **Assuming knowledge**: Define terms, explain context
2. **Outdated docs**: Keep in sync with code
3. **Missing examples**: Always include examples
4. **No visuals**: Use diagrams for complex concepts
5. **Poor structure**: Use headings and sections
6. **Passive voice**: Use active voice
7. **Too much jargon**: Write for your audience
8. **No version info**: Date docs, note versions
9. **Missing error cases**: Document what can go wrong
10. **No maintenance**: Update regularly
## Best practices
1. **Write for your audience**: Match their knowledge level
2. **Start with why**: Explain the purpose
3. **Show, don't just tell**: Use examples
4. **Be consistent**: Terminology, style, structure
5. **Test your docs**: Can someone follow them?
6. **Version your docs**: Track with code versions
7. **Use templates**: Consistency across docs
8. **Link related docs**: Help readers find more info
9. **Update with code**: Docs are part of the code
10. **Review regularly**: Quarterly doc review
## Tools
**Diagram tools**:
- Mermaid (markdown-based)
- Draw.io
- Lucidchart
- PlantUML
**Documentation platforms**:
- GitBook
- Docusaurus
- MkDocs
- Sphinx
**Style checkers**:
- Grammarly
- Hemingway Editor
- Vale
**Screenshot tools**:
- Snagit
- CloudApp
- Loom (for videos)
## Examples
### Example 1: Basic usage
<!-- Add example content here -->
### Example 2: Advanced usage
<!-- Add advanced example content here -->c033769
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.