tech-writerlisted

Write or rewrite anything technical people write — READMEs, documentation pages, quickstarts, PRDs, tech specs, RFCs, ADRs, design docs, task breakdowns and task files, GitHub issues, bug reports, QA test plans, test cases, exploratory charters, verification reports, PR descriptions, code review comments, and async team updates — so it reads clearly, scans fast, stays faithful to source facts, and sounds human. Use when the user says "write a README", "improve these docs", "write a PRD", "write a tech spec", "draft an ADR", "break this into tasks", "write the task files", "open an issue", "write a test plan", "write test cases", "file a bug report", "write the QA report", "write the PR description", "draft a status update", or wants technical writing that persuades without marketing fluff. Do NOT use for marketing landing pages, sales copy, or ad copywriting.
marcioaltoe/roundfix · ★ 2 · Code & Development · score 78

Install: claude install-skill marcioaltoe/roundfix

# 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 propo