Writing and Documentation Skills

Best for: Stress-testing a design while the glossary and ADRs write themselves

The most installed skill on this page, and one of the ten most installed in the entire registry. Its SKILL.md is two lines long: run a grilling session, using the domain-modeling skill. The grilling half interviews you about a plan one question at a time, looks up facts in the codebase itself instead of asking you, reserves the decisions for you, and refuses to start building until you both confirm a shared understanding.

The domain-modeling half is what earns the with-docs suffix. As terms get resolved in conversation, the agent writes them into a CONTEXT.md glossary on the spot, and it offers an ADR only when a decision passes three tests: hard to reverse, surprising without context, and the result of a real trade-off. It ships with model invocation disabled, so it runs only when you call it by name.

• 436K installs, a top-ten skill in the whole registry
• One question at a time, facts from code, decisions from you
• Maintains a CONTEXT.md glossary as terms get settled
• Three-part gate keeps ADRs rare and worth reading

Best for: Turning a spec into tasks a fresh subagent can execute cold

The planning skill from the superpowers suite writes for a deliberately unflattering audience: a skilled engineer with zero context for your codebase and questionable taste. Every task lists exact file paths, complete code, and 2 to 5 minute steps that follow the TDD loop of failing test, run, implement, pass, commit. Plans land in docs/superpowers/plans/ with a date-stamped filename.

Its sharpest section is the placeholder ban. Writing TBD, add appropriate error handling, or similar to Task N counts as a plan failure, because the engineer may read tasks out of order and cannot fill gaps they cannot see. A self-review pass then checks spec coverage, scans for banned placeholders, and verifies that function signatures stay consistent between tasks before the plan hands off to execution.

• Assumes the reader knows nothing about your codebase
• Every step is one 2 to 5 minute action with real code
• Placeholders like TBD are defined as plan failures
• Self-review checks types match across all tasks

Best for: Capturing why the codebase looks the way it does

Addy Osmani's take on documentation starts from a rule: document decisions, since the code already shows what was built. Its ADR template stores records in docs/decisions/ with sequential numbers and demands an alternatives-considered section, so a future reader learns that MongoDB was rejected and why. Old ADRs never get deleted; a new one supersedes them, preserving the history of how the team's thinking changed.

The skill also covers where comments belong (on intent and gotchas, never restating code) and closes with a rationalizations table that answers every excuse for skipping docs. Its reply to nobody reads docs has aged well: agents do. ADRs are how a coding agent avoids relitigating a decision your team already settled six months ago.

• ADR template with a required alternatives section
• Superseded ADRs stay in the repo as history
• Comment rules: intent and gotchas, never what
• Frames docs as context for agents, not just humans

Best for: Getting everything you know about a topic out of your head

The explore phase of Pocock's writing system. The agent interviews you about whatever you want to write and appends every promising piece to a single markdown file: sharp sentences with no home yet, half-thoughts, vignettes, complaints, punchlines. Imposing an outline is explicitly out of scope here, and the skill names the model it imitates, the novelist's diary of unstructured noticings that get mined later.

The fragment it values most is what the skill calls a leading word, a compact coinage the whole piece can hang on, the way tracer bullets names an entire pattern. When the conversation keeps circling one idea, the agent pushes you to coin a term for it, because landing the right name in explore pays off through every later phase. Before each write it re-reads the file from disk, so your manual edits between turns survive.

• Pure explore: outlines and structure are out of scope
• Hunts for a leading word the piece can hang on
• Fragments separated by rules in one growing file
• Re-reads from disk so your edits are never clobbered

Best for: Turning a fragment pile into an argument that holds

The exploit phase for essays and articles. It takes the raw file that writing-fragments produced (or any pile of notes, the format does not matter), drafts two or three candidate openings that each imply a different thesis, and makes you pick. From there the article grows one block at a time, with the agent asking what the reader needs to hear next and arguing out loud about form: prose versus list, table versus repeated structure, quote versus paraphrase.

Its central discipline is grounding. A block may only lean on concepts the reader brought in or met in an earlier block, and the agent keeps a running list of what is grounded so far. Reach for an ungrounded concept and the fix is either a grounding block first or a renegotiated prerequisite. It is the rare writing tool that treats losing the reader as a structural bug with a named cause.

• Forces a choice between openings with different theses
• Grounding rule: no block leans on an unmet concept
• Format choices argued out loud, not applied silently
• Treats your raw material file as strictly read-only

Best for: Narrative pieces where the path matters as much as the point

The second exploit skill takes a different route through the same raw material. Instead of committing to one opening and one thesis, it offers two or three candidate beats at every step, tells you which concepts each would ground, and previews what picking one unlocks, so writing the piece feels like walking a branching path with a map. A beat is one move: set a scene, land a point, drop an aside, then stop.

Beats are sized by what they need, from a single sentence to a multi-paragraph vignette, and anything demanding five paragraphs and three subheadings gets split. The journey ends when it feels complete rather than when the pile runs out, and the skill treats leftover fragments as the point of gathering more material than you use. Like the other two, it only runs when you invoke it by name.

• Offers candidate next beats with what each unlocks
• Beats range from one sentence to a full vignette
• Ends at a natural close, not an empty pile
• Writes one beat, then re-reads the file before the next

Best for: Improving copy that exists without rewriting it

The editing counterpart to the copywriting skill featured on our SEO and marketing page. Its core is the Seven Sweeps framework: clarity, voice, so-what, prove-it, specificity, emotion, and risk, each a separate pass with its own checks, and each looping back through the earlier sweeps to confirm nothing broke. The so-what sweep alone earns the install: every claim must answer why a reader should care, or it gets a which-means bridge added.

The word-level tables are pleasingly self-aware, ordering cuts for utilize, leverage, seamless, and cutting-edge, the exact vocabulary AI drafts reach for. For high-stakes pages it adds an expert panel pass, scoring the copy 1 to 10 from several personas and iterating until every persona scores it 7 or higher. Marketing copy is the target audience, but the sweeps work on any prose that has a job to do.

• Seven named sweeps, each rechecking the ones before
• Every claim must survive the so-what test
• Cut lists target utilize, leverage, and seamless
• Panel scoring iterates until every persona says 7+

Best for: Doc sets that separate tutorials from reference on purpose

From GitHub's official awesome-copilot collection, this skill writes documentation under the Diátaxis framework, which splits all docs into four types with different jobs: tutorials teach, how-to guides solve, reference describes, and explanation clarifies. Most bad documentation is one of these pretending to be another, which is exactly the failure the framework exists to prevent.

Before writing a word, the skill requires four things settled: document type, target audience, the reader's goal, and scope including what to exclude. Then it proposes an outline and waits for approval before generating content. It also refuses to consult external websites unless you hand it a link, which keeps generated docs anchored to your project instead of to whatever the model half-remembers about your dependencies.

• Four Diátaxis types, each with a distinct job
• Requires type, audience, goal, and scope up front
• Outline proposed and approved before any drafting
• No external sources unless you provide the link

Best for: Auditing docs pages the way a linter audits code

Vercel's prose reviewer has an unusual architecture: the SKILL.md contains almost no rules. Instead, it fetches the current ruleset from the vercel-labs/writing-guidelines repository at review time, checks your files against it, and reports findings in terse file:line format, the same shape a linter or compiler produces. Style decisions stay in one upstream place and every installed copy picks them up on the next run.

That design means the skill you install today enforces the rules Vercel's docs team publishes tomorrow, with no reinstall. It reviews rather than writes, which makes it the natural closing step after any of the writing skills on this page: draft with one of them, then run this against the output and fix what it flags.

• Fetches the latest rules from GitHub on every review
• Findings in file:line format, built for fixing
• Rule updates arrive without reinstalling the skill
• Pairs as the review pass after any writing skill

Best for: Release notes that assemble themselves from good commits

From the wshobson/agents collection, this skill wires together the three standards that make changelog generation mechanical: Keep a Changelog 1.1.0 for the file format, Conventional Commits for the input, and semantic versioning for the numbers. Its commit examples cover the details teams get wrong, like marking breaking changes with both the bang and a BREAKING CHANGE footer that carries a migration note.

The release notes template goes past the bare changelog, with sections for highlights, an upgrade guide, known issues, and a dependency table with the reason for each bump. One rule in its don't list summarizes the philosophy: never hand-edit a generated changelog. Fix the commits instead, and the changelog fixes itself on the next release.

• Keep a Changelog, Conventional Commits, and semver together
• Breaking-change examples with migration footers
• Release template includes upgrade guide and known issues
• Generated files stay generated; you fix the commits