title: Write a README

description: Create a README that gets a new user productive fast.

content:
Write a README for this project: {{project}}

Structure: one-line description, what problem it solves, quick start (install + minimal working example), common usage, configuration, and where to get help. Lead with the example a user can copy-paste to see it work. Keep prose tight; show, don't tell. Omit sections that don't apply rather than padding them.

project

description: What the project is and does


title: Document a Function

description: Write clear API documentation for a function or method.

content:
Write documentation for this function:

```
{{code}}
```

Cover: what it does (one sentence), each parameter and its constraints, the return value, errors/exceptions it can raise, and a short usage example. Document the non-obvious: side effects, performance characteristics, and any gotcha a caller would hit. Match the docstring style of {{language}}.

code

description: The function to document

language

description: Language (for doc style)


title: Write a How-To Guide

description: Produce a task-focused guide that walks a user to a goal.

content:
Write a how-to guide for: {{task}}

Assume the reader wants to accomplish this specific task, not learn the whole system. Give numbered steps with the exact commands/code, show expected output at key checkpoints, and include a 'if this fails' note for the steps most likely to trip people up. End with how to verify success.

task

description: The task the reader wants to accomplish


title: Explain a Concept Clearly

description: Teach a technical concept from intuition to detail.

content:
Explain this concept clearly: {{concept}}

Start with an intuition or analogy, then the precise definition, then a concrete example, then the common misconceptions. Tailor the depth to: {{audience}}. Don't oversimplify to the point of being wrong; flag where the simple model breaks down. End with one question that tests whether the reader really got it.

concept

description: The concept to explain

audience

description: Who you're explaining to


title: Write Inline Comments

description: Add comments that explain why, not what.

content:
Add helpful comments to this code:

```
{{code}}
```

Comment the WHY, not the what — explain intent, non-obvious decisions, tricky edge cases, and references to relevant context (tickets, specs, gotchas). Do NOT narrate code that already reads clearly. If a comment would only exist because the code is unclear, suggest renaming/restructuring instead. Keep them concise.

code

description: The code to comment


title: Generate a Changelog Entry

description: Summarize a change for users in a changelog.

content:
Write a changelog entry for this change:

{{change}}

Write it for users, not maintainers: what changed from their perspective, why it matters, and any action they must take. Categorize it (Added/Changed/Fixed/Deprecated/Removed/Security). For breaking changes, lead with the migration step. Keep it to a couple of crisp lines.

change

description: The change (diff, PR summary, or description)


title: Document an Architecture

description: Write an architecture overview that orients a new engineer.

content:
Write an architecture overview for: {{system}}

Cover: the big-picture purpose, the main components and their responsibilities, how data and control flow through them, the key design decisions and why, and where the bodies are buried (known limitations, tech debt, surprising constraints). Aim to get a new engineer to a useful mental model in 10 minutes of reading. Use a simple text diagram.

system

description: The system to document


title: Write API Reference from Code

description: Turn a module's public surface into reference docs.

content:
Generate API reference documentation from this code:

```
{{code}}
```

For each public export: signature, description, parameters, return value, errors, and a minimal example. Group related items and order them by how commonly they're used, not alphabetically. Note any deprecated or experimental items clearly. Skip private/internal symbols.

code

description: The module's public API


title: Write a Troubleshooting Guide

description: Help users diagnose common failures themselves.

content:
Write a troubleshooting guide for: {{system}}

For each common symptom, give: what the user sees, the likely cause, how to confirm it, and the fix. Order by frequency so the common cases come first. Use a symptom-first structure (users search by what they see, not by cause). Include the one diagnostic command or check that resolves the most ambiguity. End with where to go if nothing here helps.

system

description: The system users troubleshoot


title: Document a Configuration Reference

description: Produce a complete, scannable config reference.

content:
Document the configuration for: {{system}}

For each option: name, type, default, whether it's required, what it controls, and a realistic example. Note interactions between options and any that are dangerous to change. Group related options and mark deprecated ones. Make it scannable: a table or consistent block per option, not prose. Lead with the handful of options most people actually need to set.

description: The system being configured


title: Write Release Notes

description: Summarize a release for the people who use it.

content:
Write release notes for version {{version}} from these changes:

{{changes}}

Lead with what users gain and what they must do. Group by Highlights, Changes, Fixes, and Breaking. For breaking changes, give the exact migration step up front. Write for users, not maintainers: skip internal refactors with no user-visible effect. Keep it skimmable and honest about known issues.

version

description: Version being released

changes

description: The changes in this release


title: Explain a Decision for Newcomers

description: Write down why something is the way it is.

content:
New engineers keep being surprised by: {{thing}}

Write a short doc that explains WHY it's this way. Cover the context and constraints that led to it, the alternatives that were rejected and why, and what would have to change for the decision to be revisited. The goal is to stop the recurring why-is-this-weird question and prevent someone from naively undoing a deliberate choice. Be honest about the trade-offs.

thing

description: The surprising thing to explain


title: Write a Quickstart

description: Get a new user to first success in minutes.

content:
Write a quickstart for: {{project}}

Get the reader from nothing to one working result as fast as possible. Cover the minimum: prerequisites, install, the single smallest example that does something real, and how to confirm it worked. Cut everything that isn't on the critical path to that first success — link to it instead. Assume the reader is impatient and will leave if it doesn't work. End with the obvious next step.

project

description: What the quickstart is for


title: Document an API Endpoint

description: Write reference docs for one HTTP endpoint.

content:
Document this endpoint: {{endpoint}}

Cover: method and path, what it does in one line, parameters (path/query/body) with types and which are required, the request and a realistic response example, the status codes and what each means, auth, and rate limits. Show one full working example a reader can copy. Note the non-obvious behavior — pagination, idempotency, side effects — that callers get wrong. Be precise about error responses.

endpoint

description: The endpoint to document


title: Write a Migration Guide

description: Help users upgrade across a breaking change.

content:
Write a migration guide from {{from}} to {{to}}.

Lead with why upgrading is worth it and roughly how much work it is. List the breaking changes, each with a concrete before/after and the exact edit to make. Order them so the reader can work top to bottom. Call out what can be automated, what must be done by hand, and how to verify the migration worked. Be honest about the painful parts rather than hiding them.

from

description: Starting version

to

description: Target version


title: Write a Glossary

description: Define the terms a project keeps using.

content:
Write a glossary for: {{domain}}

List the terms that newcomers stumble on — domain jargon, project-specific words, and overloaded common words used in a special way here. Define each in one or two plain sentences, from the reader's point of view, with an example where it helps. Disambiguate terms that get confused with each other. Skip terms a competent reader already knows. Keep it alphabetical and scannable.

domain

description: The project or domain