| name | document-writer |
| description | Use when writing or improving technical documentation, API references, runbooks, onboarding guides, READMEs, changelogs, ADRs, release notes, or any content that ships to engineers or end users. Also use for structuring documentation sites (MkDocs, Docusaurus) and diagrams-as-code. |
| version | 2.1.0 |
Document Writer
Iron Law
Documentation is a product. Write for the reader, not the writer.
Every API endpoint, CLI flag, and configuration option needs a real, runnable example.
Examples are not optional, they are the most important part of the documentation.
Before Taking Any Action
- Announce what you intend to write or change, and for which audience
- Clarify the documentation type (tutorial vs. how-to vs. reference vs. explanation) before drafting
- Ask for confirmation before creating or overwriting any files
- Report what was created, the intended audience, and what still needs review
Task Approach
Use this table to determine what to produce for each task type:
| User asks for | What to produce |
|---|
| API reference | Endpoint-by-endpoint reference using the API Reference template below: method + path, description, headers table, request body with JSON example and field table, all response codes with example bodies |
| README | README using the structure below: one-sentence purpose, Quick Start (≤5 commands), Installation, Configuration (all options with types/defaults/examples), Usage, Development, Architecture, Contributing, Licence |
| Runbook | Step-by-step response procedure using the Runbook template: purpose, triggering conditions, prerequisites, numbered steps with exact commands and expected output, escalation path, related runbooks |
| ADR | Completed ADR using the template: status, context (constraints and forces), decision, consequences (positive / negative / neutral) |
| Changelog entry | Keep a Changelog format entries grouped by Added / Changed / Deprecated / Removed / Fixed / Security; each entry is one line with the user-visible change |
| Tutorial | Step-by-step learning document classified to Diátaxis Tutorial quadrant: outcome guaranteed by following steps; no explanation mixed in; every command is runnable as written |
| How-to guide | Task-oriented guide classified to Diátaxis How-to quadrant: starts from a working state; addresses a specific real-world goal; no teaching detours |
| Explanation / concept doc | Conceptual document classified to Diátaxis Explanation quadrant: explores context, trade-offs, history; contains no instructions |
| Documentation audit | Gap analysis against the Documentation Quality Checklist; each failing item flagged with the specific problem and a suggested fix |
| Doc site structure | Proposed IA with page types labelled by Diátaxis quadrant; navigation hierarchy; cross-link strategy |
Diátaxis Framework (Procida)
Every document falls into exactly one of four quadrants. Mixing types in the same document creates confusion, separate them deliberately.
| Type | Question it answers | Reader state | Key characteristic |
|---|
| Tutorial | How do I learn this? | New to the topic; learning | Step-by-step; outcome is guaranteed by following the steps; teaching, not explaining |
| How-to guide | How do I do X? | Knows the domain; has a specific goal | Task-oriented; starts from a working state; addresses a real-world problem |
| Reference | What is X? | Looking something up; not reading top-to-bottom | Complete, accurate, consistent; describes the system as it is |
| Explanation | Why does X work this way? | Wants to understand, not do | Conceptual; explores context, trade-offs, history; does not include instructions |
Common mistake: mixing how-to steps inside a reference page, or explaining concepts inside a tutorial. Separate them.
Style Rules
| Rule | Wrong | Correct |
|---|
| Active voice | "The file can be run with..." | "Run the file with..." |
| Imperative mood for instructions | "You should install..." | "Install..." |
| Second person for user-facing docs | "Users must configure..." | "Configure your..." |
| Third person for reference | "The user can set..." | "The API accepts..." |
| Short sentences | "The configuration file, which is located in the root directory of the project, must contain the database connection string, the API key, and the environment name." | "The configuration file lives in the project root. It must contain three values: the database connection string, the API key, and the environment name." |
| No jargon without definition | "Use the idempotency key" | "Use the idempotency key, a unique identifier you generate that prevents duplicate operations if the request is retried." |
| Consistent terminology | Mixing "endpoint", "route", "URL", "path" | Pick one term per concept and use it throughout |
Documentation Templates
ADR (Architecture Decision Record)
# ADR-NNN: [Title]
## Status
[Proposed / Accepted / Superseded by ADR-NNN]
## Context
[What is the situation that forces a decision? What are the constraints?]
## Decision
[What was decided?]
## Consequences
### Positive
- [Benefits this decision enables]
### Negative / Trade-offs
- [Costs and risks this decision introduces]
### Neutral
- [Things that change but are neither positive nor negative]
Runbook
# Runbook: [Alert Name or Operational Procedure]
## Purpose
[What situation does this runbook address?]
## When to use this runbook
[Triggering conditions, alert name, error pattern, user-reported symptom]
## Prerequisites
- [Access / permissions required]
- [Tools required]
## Steps
1. **[Step title]**: [Action with exact command]
Expected output: `[exact output]`
If you see X instead: [what to do]
2. **[Step title]**: ...
## Escalation
If the issue is not resolved after [N] minutes, escalate to [team/person] via [channel].
## Related runbooks
- [Links to related runbooks]
API Reference Endpoint
## POST /payments
Creates a new payment. Idempotent with the same `idempotency_key`.
### Request
**Headers**
| Header | Required | Description |
|---|---|---|
| `Authorization` | Yes | Bearer token |
| `Idempotency-Key` | Yes | UUID; retries with the same key return the original response |
**Body**
```json
{
"amount": 10000,
"currency": "GBP",
"recipient_account_id": "acc_abc123"
}
| Field | Type | Required | Description |
|---|
amount | integer | Yes | Amount in minor units (pence for GBP) |
currency | string | Yes | ISO 4217 currency code |
recipient_account_id | string | Yes | ID of the destination account |
Response
201 Created
{ "payment_id": "pay_xyz789", "status": "pending" }
400 Bad Request, invalid input
409 Conflict, idempotency key already used with different parameters
422 Unprocessable Entity, business logic failure (insufficient funds, blocked account)
---
## README Structure
A README is a how-to guide for contributors and consumers of the repository:
```markdown
# Project Name
[One sentence: what does this do and who is it for?]
## Quick Start
[Minimal steps to get something running. Under 5 commands.]
## Installation
[Full setup instructions]
## Configuration
[All config options with types, defaults, and examples]
## Usage
[Common use cases with working examples]
## Development
[How to run tests, lint, build locally]
## Architecture
[Link to detailed architecture docs or a 1-paragraph summary]
## Contributing
[PR process, coding standards link, review process]
## Licence
Changelog Format (Keep a Changelog)
# Changelog
## [Unreleased]
## [1.2.0] - 2025-05-01
### Added
- Payment retry with exponential backoff
### Changed
- `/payments` now requires `Idempotency-Key` header
### Deprecated
- `POST /v1/send`, use `POST /v2/payments` instead; removed in v3.0
### Removed
- `GET /status` endpoint (deprecated since v1.0)
### Fixed
- CLS regression on the transaction history page
### Security
- Upgraded `jackson-databind` to 2.16.1 (CVE-2024-XXXXX)
Documentation Quality Checklist
Output Protocol
End every response with a confidence signal on its own line:
CONFIDENCE: [High|Medium|Low], [one-line reason]
- High, output is complete, correct, and based on sufficient context
- Medium, output is reasonable but contains an assumption or a gap; state the assumption inline
- Low, insufficient context to produce a reliable result; state what is missing
If the task is outside this skill's scope or you lack the information needed to proceed, return this instead of a confidence signal:
BLOCKED: [reason], [what information would unblock this]
Do not guess or produce low-quality output to avoid returning BLOCKED. A precise BLOCKED is more useful than a low-confidence guess.
