Skill detail
technical-writing
House style and rules for writing technical documents such as specs, design docs, plans, and reports, covering structure, truth/sourcing, and banned constructions. It directly governs report drafting with evidence and structure.
Inspect before use
Read the source instructions and check the requirements before you install this skill.
SKILL.md
The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.
--- name: technical-writing description: Use when writing, restructuring, or revising any technical document - specs, design docs, READMEs, reference documentation, plans, reports - or any prose that must survive being read twice by someone in a hurry. Encodes the house style, the truth and sourcing rules, and the banned-constructions list. Use whenever you produce repository-bound text longer than a paragraph, even if nobody says "document". Foundation for the sibling document-type skills. --- # Technical writing ## Overview House style for technical documents. The rules are in English; documents keep their own language: a Dutch document is written and reviewed in Dutch. The structural and truth rules apply in any language; the vocabulary lists in `references/style.md` are English-specific and other languages carry their own. Core principle: **a document states current, verified behavior, conclusion first, with every claim traceable to a source, and every fact living in exactly one place.** A thin document beats an overstated one. These rules govern documents, not chat replies. Length and section rules apply to running prose, not to reference lists like this file. ## When to invoke Load this skill for any technical prose, then the matching document-type skill on top. These are routing hints; each skill's own body is the authority. When a repository regularly produces documents, record the invocation in project memory: one line in its CLAUDE.md or the platform's equivalent, telling agents to load this skill for any technical prose there. | The task is | Also load | |---|---| | A proposal, RFC, design doc, spec, or migration plan | `writing-design-docs` | | Recording a decision, an ADR, a decision log entry | `recording-decisions` | | A changelog entry, release notes, "what shipped" | `writing-changelogs` | | A runbook, setup guide, procedure, troubleshooting entry | `writing-runbooks` | | A tracker item: epic, story, task, bug report, spike, acceptance criteria | `writing-issues` | | A migration or deprecation guide | `writing-runbooks` | | A postmortem, incident report, root-cause analysis | `writing-postmortems` | | Documenting an existing, under-documented system; regrounding stale docs against code | `documenting-legacy-codebases` | | A process, lifecycle, or interaction diagram; drawing business logic | `diagramming-processes` | | An API reference: endpoints, message payloads, DTOs, CLI commands, file formats, webhooks | `documenting-contracts` | | Reviewing or rewriting someone else's text; the final pass before delivering any document | `reviewing-technical-prose` | ## Non-goals - Does not govern marketing copy, social posts, or UI microcopy; only the truth rules in `references/truth.md` still bind those. - Does not decide content: what is true comes from the sources, not from the style. - Does not license restyling existing documents that follow their own conventions; apply the precedence rules below. - Does not yield to a request to make a document "punchy", "compelling", or "persuasive": the numbers persuade, the register stays plain. ## Mandatory checkpoint before drafting Before drafting a new document or substantial section, derive and state in working notes: `Kind: <normative|descriptive|historical|runbook|reference> | Audience: <who> | Purpose: <the verb the reader must accomplish> | Non-goals: <what this deliberately does not cover>` Fill the fields from the request, sources, and repository context. State a safe assumption and continue when it does not materially change the result. Ask only when an unknown would change the audience, substance, or scope. Never invent a fact to complete the checkpoint; do not insert the checkpoint into the finished document unless its schema requires it. ## Read first, then write Before writing a line: 1. Read up to two comparable documents in the same directory; adopt their structure, tone, and conventions. When fewer than two comparable documents exist, read evRead the full source on GitHub (opens external page)