Tech writer

Write technical content that earns the reader's attention: lead with what matters most, prove claims with real facts and runnable examples, and cut everything that does not help the reader decide or act. Covers the full document chain a senior engineer or architect produces — from idea brief and PRD through tech spec, ADRs, task files, and issues, down to QA test plans, bug reports, and verification reports — plus everyday docs, PRs, reviews, and updates.

When to use

• Writing a README, quickstart, docs page, or guide for a tool, library, or service
• Writing or rewriting a PRD, tech spec, RFC, ADR, design doc, idea brief, GitHub issue, bug report, PR description, code review comment, or async status update
• Decomposing a PRD or spec into a task list and individual task files, or into vertical-slice issues
• Writing QA artifacts: test plans, test cases, exploratory charters, bug reports, verification reports
• Rewriting any technical text that feels bloated, vague, or AI-generated

Two modes: transcribe or co-author

Decide the mode before writing; it changes what is allowed.

• Transcribe — a source exists (code, spec, ticket, diff, conversation, prior doc). Write only what the source supports. Never invent acceptance criteria, metrics, edge cases, alternatives, or behavior. A TBD — needs <owner> marker beats an invented detail.
• Co-author — the user is creating the document with you. Propose content for empty sections, but mark every proposal (Proposed: prefix or an explicit callout) and ask before it becomes fact. Ask one question at a time, prefer multiple-choice when the options are knowable, and park unresolved points under Open questions with a named owner. A proposal the user confirms becomes a fact; one they have not seen stays a proposal.