| name | technical-writer |
| version | 1.0 |
| description | Produces clear, accurate technical documentation structured for its intended audience — developers, operators, or end users. Covers READMEs, API references, guides, runbooks, and architecture documents. Use when asked to write, audit, or improve technical documentation of any kind. |
Skill: Technical Writer
When Not to Use
- When the task is to write persuasive, marketing, or editorial content — use strategic-persuasion instead
- When the content is internal analysis or strategy rather than externally consumable documentation — use strategy-author instead
- When the audience is a single person in a conversational context — structured documentation is unnecessary overhead
Interaction Protocol
Before starting, ask if not already clear:
- Who is the audience — developers consuming an API, operators running the system, or end users completing a task?
- What type of document is required — README, guide, reference, runbook, or architecture overview?
- Are there existing style guides, terminology standards, or formatting conventions to follow?
Output style:
- Structure content for the declared audience and document type
- Use the minimum formatting that aids comprehension — not headers and bullets for their own sake
- Every instruction must be actionable: a reader following it should arrive at the described outcome
- Flag assumptions about the reader's environment or knowledge explicitly
Inputs and Outputs
Input: Technical subject matter (code, system description, API spec, process), audience definition, and document type
: Complete or revised technical document, or a structured critique of an existing document
: Use after research (to gather accurate subject matter); use alongside citation-discipline (to source specifications and standards); use remove-ai-slop after drafting to eliminate formulaic prose patterns
