{"title":"Write a README","description":"Create a README that gets a new user productive fast.","tags":["readme","docs","onboarding"],"content":"Write a README for this project: {{project}}\n\nStructure: 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.","variables":[{"name":"project","description":"What the project is and does","required":true}]}
{"title":"Document a Function","description":"Write clear API documentation for a function or method.","tags":["api-docs","docstring"],"content":"Write documentation for this function:\n\n```\n{{code}}\n```\n\nCover: 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}}.","variables":[{"name":"code","description":"The function to document","required":true,"multiline":true},{"name":"language","description":"Language (for doc style)","required":true}]}
{"title":"Write a How-To Guide","description":"Produce a task-focused guide that walks a user to a goal.","tags":["how-to","tutorial","guide"],"content":"Write a how-to guide for: {{task}}\n\nAssume 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.","variables":[{"name":"task","description":"The task the reader wants to accomplish","required":true}]}
{"title":"Explain a Concept Clearly","description":"Teach a technical concept from intuition to detail.","tags":["explainer","teaching","concept"],"content":"Explain this concept clearly: {{concept}}\n\nStart 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.","variables":[{"name":"concept","description":"The concept to explain","required":true},{"name":"audience","description":"Who you're explaining to","required":true}]}
{"title":"Write Inline Comments","description":"Add comments that explain why, not what.","tags":["comments","clarity"],"content":"Add helpful comments to this code:\n\n```\n{{code}}\n```\n\nComment 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.","variables":[{"name":"code","description":"The code to comment","required":true,"multiline":true}]}
{"title":"Generate a Changelog Entry","description":"Summarize a change for users in a changelog.","tags":["changelog","release-notes"],"content":"Write a changelog entry for this change:\n\n{{change}}\n\nWrite 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.","variables":[{"name":"change","description":"The change (diff, PR summary, or description)","required":true}]}
{"title":"Document an Architecture","description":"Write an architecture overview that orients a new engineer.","tags":["architecture","overview","onboarding"],"content":"Write an architecture overview for: {{system}}\n\nCover: 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.","variables":[{"name":"system","description":"The system to document","required":true}]}
{"title":"Write API Reference from Code","description":"Turn a module's public surface into reference docs.","tags":["api-reference","docs"],"content":"Generate API reference documentation from this code:\n\n```\n{{code}}\n```\n\nFor 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.","variables":[{"name":"code","description":"The module's public API","required":true,"multiline":true}]}
{"title":"Write a Troubleshooting Guide","description":"Help users diagnose common failures themselves.","tags":["troubleshooting","docs","support"],"content":"Write a troubleshooting guide for: {{system}}\n\nFor 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.","variables":[{"name":"system","description":"The system users troubleshoot","required":true}]}
{"title":"Document a Configuration Reference","description":"Produce a complete, scannable config reference.","tags":["config","reference","docs"],"content":"Document the configuration for: {{system}}\n\nFor 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.","variables":[{"name":"system","description":"The system being configured","required":true}]}
{"title":"Write Release Notes","description":"Summarize a release for the people who use it.","tags":["release-notes","changelog","communication"],"content":"Write release notes for version {{version}} from these changes:\n\n{{changes}}\n\nLead 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.","variables":[{"name":"version","description":"Version being released","required":true},{"name":"changes","description":"The changes in this release","required":true,"multiline":true}]}
{"title":"Explain a Decision for Newcomers","description":"Write down why something is the way it is.","tags":["onboarding","rationale","docs"],"content":"New engineers keep being surprised by: {{thing}}\n\nWrite 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.","variables":[{"name":"thing","description":"The surprising thing to explain","required":true}]}
{"title":"Write a Quickstart","description":"Get a new user to first success in minutes.","tags":["quickstart","onboarding","docs"],"content":"Write a quickstart for: {{project}}\n\nGet 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.","variables":[{"name":"project","description":"What the quickstart is for","required":true}]}
{"title":"Document an API Endpoint","description":"Write reference docs for one HTTP endpoint.","tags":["api","reference","docs"],"content":"Document this endpoint: {{endpoint}}\n\nCover: 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.","variables":[{"name":"endpoint","description":"The endpoint to document","required":true}]}
{"title":"Write a Migration Guide","description":"Help users upgrade across a breaking change.","tags":["migration","upgrade","docs"],"content":"Write a migration guide from {{from}} to {{to}}.\n\nLead 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.","variables":[{"name":"from","description":"Starting version","required":true},{"name":"to","description":"Target version","required":true}]}
{"title":"Write a Glossary","description":"Define the terms a project keeps using.","tags":["glossary","terminology","docs"],"content":"Write a glossary for: {{domain}}\n\nList 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.","variables":[{"name":"domain","description":"The project or domain","required":true}]}