Technical writing is the discipline where every shortcut shows up in a support ticket. A README that skips the prerequisites turns into ten Slack pings on Monday morning. An API reference that drifts a single field name out of sync with the running code produces customer integrations that pass staging and crash in production. A changelog that buries a breaking change in a vague bullet becomes a series of churned accounts the following quarter. The skills below cover the actual surface area a working tech writer ships against — structured co-authoring with subject-matter experts, a document format that stays readable for both humans and the LLMs readers now paste docs into, changelog discipline, OpenAPI spec generation, Architecture Decision Records, style-guide review on every PR, and blameless postmortem writing. All from verified plugins with real commit history and real star counts on GitHub.
From the flagship skills plugin (138,382 stars). Guides users through a structured workflow for co-authoring documentation — proposals, technical specs, decision docs, and similar long-form content. The skill encodes the part of the writing process that fights every tech writer: extracting context from a subject-matter expert who is busy, who explains things out of order, and who assumes shared knowledge the reader does not have. The workflow keeps the SME on rails (interview, outline, draft, review) so the writer leaves the session with a complete first pass rather than a folder of half-written notes.
When to use: at the start of any new long-form doc — a product spec, a migration guide, an architecture explainer — especially when you are writing about a system you did not build and the expert can only give you 45 minutes. Pair it with the content-creator stack when the same doc has to be reshaped into a launch post and a release-day email.
From the documentation-standards plugin (35,732 stars). Use when writing technical documentation that needs to be readable by both humans and AI models, when converting existing docs to HADS format, or when optimizing for token-efficient AI consumption. HADS (Human and AI Documentation Standard) recognizes the 2026 reality: a meaningful share of every page you write is now consumed by an LLM via copy-paste, a browser tool, or a retrieval pipeline. Docs that look clean to a human can be ambiguous to a model. HADS gives you a shared format that works for both.
When to use: when refactoring a docs site for AI discoverability, when your docs keep surfacing in citations with wrong answers attached, and when standing up a new docs repo where the source format needs to outlast a model generation. It pairs well with the /llms.txt and /llms-full.txt conventions you already publish.
From the documentation-generation plugin (35,732 stars). Automates changelog generation from commits, PRs, and releases following the Keep a Changelog format. The skill encodes the structural decisions — Added / Changed / Deprecated / Removed / Fixed / Security — and the prose conventions (user-facing impact first, internal refactors omitted, breaking changes called out explicitly) that turn a commit log into something a customer can use to plan an upgrade.
When to use: on every release, especially when the engineering team writes commit messages in their own private dialect and the customer-facing changelog has to translate. Combine it with the DevOps category tooling when the release pipeline emits the draft changelog as part of CI and your job becomes editing rather than authoring.
Also from documentation-generation. Generates and maintains OpenAPI 3.1 specifications from code, design-first specs, and validation patterns. The most expensive class of bug in API docs is drift: the running service returns a field the spec does not mention, or the spec promises an enum value the service no longer accepts. The skill closes drift in both directions — lifting a spec out of code so docs follow the service, or holding code to a design-first spec so the service follows the docs.
When to use: any time you own reference docs for a REST or webhook API, when a customer files a "docs say X but API returns Y" ticket, and when shipping an SDK that needs a spec as input to a code generator. Pair it with the backend-engineer skill stack so the team that owns the service and the writer who owns the docs work from the same artifact.
Also from documentation-generation. Writes and maintains Architecture Decision Records (ADRs) following best practices for technical decision documentation. The hardest doc to write is the one that explains why a system is the way it is — why the team picked Postgres over DynamoDB three years ago, or why the auth service is a separate deployment. ADRs give you the format (context, decision, status, consequences) and the cadence (one ADR per significant decision, numbered, immutable once accepted) that turn tribal knowledge into a searchable archive new hires can read in their first week.
When to use: the next time an engineer says "we tried that and it did not work" and cannot remember why, when onboarding docs are full of "for historical reasons," and at the moment a significant decision is being made — not three months later when nobody remembers the alternatives. ADRs pair naturally with the postmortem skill below.
From the metabase plugin (47,386 stars). Reviews documentation changes for compliance with the Metabase writing style guide. The interesting move here is not the Metabase style guide specifically — it is the pattern: a style-guide-aware reviewer running on every doc PR, catching voice drift, terminology inconsistency, and structural problems before they merge. Even if you do not work at Metabase, the skill is a blueprint for the in-house equivalent you should build for your own style guide and banned-word list.
When to use: on every documentation PR in a multi-contributor repo, especially when engineers and PMs are landing docs alongside code and the writing team is reviewing rather than authoring. Worth running over an existing docs site as a one-time audit to find accumulated drift. For the authoring side, see the sibling metabase/docs-write skill in the same plugin.
From the incident-response plugin (35,732 stars). Writes effective blameless postmortems with root cause analysis, timelines, and action items. Postmortems are the most undervalued document a tech writer can own — they convert a bad night into permanent organizational memory, but only if they are written well. Done poorly, they read as defensive and get filed in a folder nobody opens. Done well, they describe what happened minute by minute, separate contributing factors from root cause, and produce action items that are concrete, owned, and dated.
When to use: after every significant incident, when the review meeting is scheduled for the day after and the on-call engineer has not had time to draft anything, and when the same class of incident keeps recurring because previous postmortems pointed at people instead of systems. Pair it with the DevOps-engineer skill stack when the same team owns both the response and the writeup, and with ADRs above for the architectural decisions the incident has now invalidated.
How to install
Each skill lives inside a plugin. Add the plugin marketplace once, then install with a single command. The skill detail page on Skill Index has the exact install string and a copy button.
If you are starting a docs site from scratch in 2026, the highest-ROI first install is the skills plugin (you get doc-coauthoring for long-form workflows plus the rest of the Anthropic-maintained set), then documentation-generation for openapi-spec-generation, changelog-automation, and architecture-decision-records as your release-and-reference backbone, then documentation-standards/hads as the format layer so the docs you write today still parse cleanly for the next model generation, and finally incident-response/postmortem-writing when the on-call rotation needs a writer in the loop. Pair the output with the rest of the thicket toolkit — reference screenshots via capture.thicket.sh, QR codes for docs URLs via qr.thicket.sh, and timeboxed deep-work blocks via focus.thicket.sh — and the gap between "the feature shipped" and "the docs are live" stops being the bottleneck on your release train.