claudeskills.page

19 skills · category

Technical Writing skills for Claude Code

Skills for developer-facing prose that people actually read: technical writing, READMEs, API references, changelogs and release notes, PRDs, design docs and RFCs, blameless postmortems, engineering blog posts, runbooks, UX microcopy, docs sites, and ruthless editing passes.

Download all 19 (.zip) Browse the list
  1. 382API Documentation
  2. 383Case Studies
  3. 384Changelog and Release Notes
  4. 385Conference Talks
  5. 386Design Docs and RFCs
  6. 387Dev Blog Posts
  7. 388Docs Site
  8. 389Help Center Articles
  9. 390Onboarding Docs
  10. 391Postmortems
  11. 392PRD Writing
  12. 393Prose Editing
  13. 394README Writer
  14. 395Resume Writing
  15. 396Runbooks
  16. 397Status Updates
  17. 398Style Guides
  18. 399Technical Writing
  19. 400UX Microcopy

Every technical writing skill

Each card opens the full playbook, example prompts and install commands.

No. 382

API Documentation

First successful call in under five minutes

Claude treats the OpenAPI spec as the single source for reference and writes guides that link into it. Every endpoint gets real request and response examples in curl, JavaScript and Python, every error code gets a cause and a fix, and cross-cutting pages cover auth, pagination, rate limits, idempotency and webhooks. The spec is linted and checked against the running API so it cannot drift.

api-documentation 246 lines
No. 383

Case Studies

Results with baselines, quotes the customer approved

Claude writes case studies that survive a skeptical reader. It runs an interview guide that digs for numbers, builds an evidence table with baselines, periods, sources, and approval status, picks the angle that matters to the target reader, drafts with a snapshot box and problem-approach-results structure, fact-checks every quote and metric, and manages customer sign-off before anything ships.

case-studies 182 lines
No. 384

Changelog and Release Notes

Tell users what changed for them, not what you typed

Claude collects merged PRs and commits since the last tag, drops internal noise like refactors and CI tweaks, and rewrites each remaining change as its effect on the user. Entries land in Keep a Changelog sections, the version bump follows from the highest-impact change, and every breaking change gets a before and after example plus migration steps. Separate benefit-led notes can be written for end users.

changelog-release-notes 198 lines
No. 385

Conference Talks

Proposals that get accepted, talks that land

Claude develops talks from a single takeaway sentence outward. It writes CFP titles, abstracts, reviewer notes, and bios tailored to the conference, builds a timed narrative arc for the slot, drafts speaker notes before slides, keeps code and charts readable from the back row, plans demos with recorded fallbacks, and runs a rehearsal loop that cuts sections instead of rushing.

conference-talks 174 lines
No. 386

Design Docs and RFCs

Proposals that end in a recorded decision

Claude opens each design doc with the decision requested, the deadline and why it matters now, then backs the proposal with back-of-envelope numbers and a diagram. Alternatives, including doing nothing, are compared on the same criteria, every cross-cutting concern gets an explicit answer, and the rollout names its point of no return. The review is time-boxed and ends with a status recorded at the top.

design-docs-rfc 167 lines
No. 387

Dev Blog Posts

Engineering stories with a point, proof and code

Claude pins down the single point a post makes and who it is for, picks a shape such as war story, deep dive or migration report, and builds the draft around evidence: real numbers, error output, diffs and labeled graphs, including the approaches that failed. Titles and hooks get rewritten from vague to specific, and an editing pass cuts roughly a third before technical and sensitive-information review.

dev-blog-posts 151 lines
No. 388

Docs Site

Docs people can navigate, search and trust

Claude designs the information architecture before touching a framework: it audits existing pages and support questions, groups guides by reader job, and caps the sidebar at three levels. It then picks Starlight, Docusaurus, MkDocs or VitePress for your situation, wires search, redirects for every moved URL and versioning only if users need it, and sets up strict builds, link checks and PR previews.

docs-site 174 lines · 2 files
No. 389

Help Center Articles

Customers find the answer and never open a ticket

Claude writes knowledge base articles from real demand. It mines tickets and search logs for the phrases customers use, picks the right article type, does the task in the product to capture exact labels, writes one-action steps with expected results and role prerequisites, adds symptom-cause-fix troubleshooting, and runs a bundled linter for titles, alt text, link text, and step problems.

help-center-articles 177 lines · 2 files
No. 390

Onboarding Docs

New engineers productive on day one, not week three

Claude writes onboarding docs that new engineers can follow without interrupting anyone. It starts from where recent hires got stuck, verifies the setup guide on a clean machine with expected output for every step, traces a real request through the code with file paths, builds a glossary and ownership map, curates a first-task ladder, and makes each new hire fix what failed for them.

onboarding-docs 181 lines
No. 391

Postmortems

Blameless reviews with numbers and owned actions

Claude rebuilds the incident timeline from alerts, deploy logs, chat and dashboards with a source for every entry, quantifies customer impact and error budget burn, and computes detect and mitigate times. Analysis looks for the contributing factors that let the failure happen rather than a person to blame, and action items come out specific, owned, dated and ticketed.

postmortems 173 lines
No. 392

PRD Writing

Requirements engineers can estimate and test

Claude writes the problem before the solution, backed by tickets, data and quotes, then sets goals, explicit non-goals and success metrics that each carry a baseline, target, timeframe and guardrail. Requirements are prioritized P0 to P2 with Given-When-Then acceptance criteria, and vague asks like 'make it fast' are turned into numbers someone can test against.

prd-writing 163 lines
No. 393

Prose Editing

Cut a third, keep the meaning and the voice

Claude edits in separate passes from structure down to proofreading instead of rewriting everything at once. A bundled Python linter gives a baseline of filler, wordy phrases, hype words, likely passives and long sentences, and the edit ends with a before and after word count, a summary of changes and a list of queries wherever meaning was ambiguous, so the author's voice and facts stay intact.

prose-editing 174 lines · 2 files
★ No. 394

README Writer

From landing on the repo to a working result

Claude reads your manifest, CLI help and config schema before writing so every flag and version in the README is real. It leads with a plain one-sentence pitch, keeps badges to the few users act on, writes a quickstart that reaches visible output in three commands or fewer, and runs a bundled checker that catches broken relative links, untagged code blocks and leftover TODOs.

readme-writer 180 lines · 2 files
No. 395

Resume Writing

Impact bullets with real numbers, never invented ones

Claude rewrites engineering resumes into specific, defensible bullets built from action, scope and result, and asks you for missing numbers instead of making them up. It maps a job description to real evidence, flags genuine gaps rather than stuffing keywords, picks length and section order by seniority, and checks the text an ATS will parse with a bundled linter.

resume-writing 196 lines · 2 files
No. 396

Runbooks

From page to mitigation without asking anyone

Claude writes one runbook per alert, starting from the alert rule itself: what it means, who is affected, then read-only triage commands with the normal output spelled out. A decision tree routes to mitigations ordered by risk, each with exact commands, expected effect, verification and undo, and high-risk steps require incident commander approval inline.

runbooks 184 lines
No. 397

Status Updates

Readers know where it stands in 30 seconds

Claude writes status updates from facts, not memory. It pulls merged PRs, tracker milestones, and metrics, sets red, amber, or green against written criteria, leads with a bottom line and the ask, reports progress against planned dates, lists risks with owners and mitigations, and cuts activity that does not change the reader's picture. Bad news surfaces the week it is known.

status-updates 182 lines
No. 398

Style Guides

One voice and one term list, enforced in CI

Claude builds style guides people use. It audits existing docs for conflicting terms, inherits a published base guide and records only your overrides, defines voice traits with do and don't examples from your product, writes the terminology table that fixes most inconsistency, and encodes the enforceable rules as Vale styles and vocabularies rolled out gradually in CI.

style-guides 188 lines · 2 files
No. 399

Technical Writing

Docs that get one reader to one goal

Claude starts every document by naming the reader, their goal and the Diátaxis type, then outlines by the reader's task rather than the system's architecture. Drafts use active voice, short sentences and complete runnable examples with real output, and the result is tested by following it step by step in a clean environment where every deviation counts as a bug.

technical-writing 172 lines · 2 files
No. 400

UX Microcopy

Labels that say exactly what will happen

Claude rewrites interface strings by component pattern: buttons become verb plus object, errors state what happened and how to fix it without blame, and destructive dialogs name the action and its consequences. It builds a glossary so one concept has one name across the app, uses ICU plurals instead of concatenation and reviews copy in context for truncation and screen reader sense.

ux-microcopy 197 lines

Choosing Technical Writing skills

Install the skills that match requests you make every week; each costs about 100 tokens of standing context until it loads. If you are not sure where to begin, start with README Writer. For background, read Using Skills on claude.ai, the Claude API, and the Agent SDK, The Best Claude Code Skills in 2026, by Use Case and How to Write Your First Claude Code Skill, Step by Step.

Install several

Install several at once

The installer accepts any number of skill names. Add --project to install into the current repository.

curl -fsSL https://claudeskills.page/install.sh | sh -s -- api-documentation case-studies changelog-release-notes conference-talks design-docs-rfc dev-blog-posts docs-site help-center-articles onboarding-docs postmortems prd-writing prose-editing readme-writer resume-writing runbooks status-updates style-guides technical-writing ux-microcopy

Technical Writing skills FAQ

How do I install every Technical Writing skill at once?

Download the bundle at https://claudeskills.page/downloads/category/writing.zip and unzip it into ~/.claude/skills/ (or .claude/skills/ inside a repository). To pick a few, pass several names to the installer: curl -fsSL https://claudeskills.page/install.sh | sh -s -- api-documentation case-studies changelog-release-notes.

Will installing 19 skills slow Claude Code down?

No. Claude Code keeps only each skill's short description in context — roughly 100 tokens per skill — and loads the full instructions only when a request matches. Install the whole category if it fits your work; unused skills cost almost nothing.

Which Technical Writing skill should I start with?

Start with README Writer. They cover the most common requests in this category; add the rest as your work calls for them.

Featured in Ship to Production, Docs That Get Read, Product Manager Toolkit.

Explore other categories

esc