--- name: write-a-prd description: Use when starting a new build, feature, app, or automation and you want a clear plan before any code gets written. Triggers on "write a PRD", "let's plan this build", "spec this out", or "create a product requirements document". The skill interviews you first, then produces a PRD an AI coding tool can build from. --- # Write a PRD ## What this does Produces a Product Requirements Document: a short, living plan that states what you are building, who it is for, why now, and how you will know it worked, written before any code gets generated. The skill interviews you first, then drafts the PRD from your answers. The finished document is something an AI coding tool can build from without filling the blanks with guesses. A PRD is a living document. The first version is meant to be edited as you learn. Start simple. ## When to use it - Before you ask an AI tool to build an app, a feature, or an automation - When a build keeps drifting and you want to reset everyone on one shared plan - When you want to hand a teammate, or an AI agent, something they can build from - When you are deciding whether a build is worth doing at all Do NOT use it for: a tiny one-off script, or a task you have already fully described and tested. ## How to do it 1. Interview me first. Ask up to seven questions, in one batch, to fill the recipe below. Cover the business reason, the problem, the user, the timing, the win condition, the requirements, and what is out of scope. 2. If I cannot answer something, write it into the Open Questions table rather than inventing an answer. A known unknown is worth more than a confident guess. 3. Draft the PRD using the recipe, in order. Keep it short. One screen per section at most. 4. Write the requirements as Jobs To Be Done: "When [situation], I want to [do something], so I can [outcome]." Describe the job rather than the screen. 5. State every boundary positively. Write down what to build and, just as clearly, what NOT to build in this version. An AI cannot infer from omission: if the plan does not say "do not add user accounts yet," a tool may add them, because most apps have them. 6. Order the requirements so foundations come first. Group them into a few dependency-ordered phases (data and models before the things that depend on them), each one testable on its own. 7. Finish with the Open Questions table. List every decision still open, who owns it, and when it is needed. 8. After I approve the PRD, offer to turn it into a build plan: a short, numbered task list in the same phase order, with a checkpoint to test after each phase. ## The recipe (the sections of the PRD) 1. **Business context.** Why this is worth doing for the business, in a few honest sentences with enough supporting detail to ground the rest. 2. **Problem space / user research.** What you know about the problem, qualitative and quantitative. Real observations rather than assumptions dressed as facts. 3. **Problem statement.** The single problem this build will solve, stated plainly. 4. **Who is this for.** The people who will use it. Use short personas if it helps. 5. **Why now.** What makes this worth doing now instead of later. Justify the priority. 6. **Success outcomes and KPIs.** Your win criteria. The metrics that will prove the build did what you set out to do. 7. **Assumptions.** Everything you are taking on faith in the sections above. Name it so it can be checked. 8. **Requirements.** The high-level Jobs To Be Done, in dependency order. What the thing must do. 9. **Out of scope.** What you are deliberately NOT building in this version. State it positively and specifically. 10. **Open questions.** A living table of decisions still to be made over the life of the PRD. ## Rules and guardrails - Never invent facts, numbers, or requirements to fill a section. Unknowns go in the Open Questions table. - Write every boundary as a positive instruction ("do not build payments in this phase"), because an AI cannot infer a limit from silence. - Keep the first version simple. A PRD that is too long slows the build and stops getting read. Add detail only where the build needs it. - Treat the PRD as a living document. Get feedback early and often from the people who matter, and update it as you learn. - Set a clear "done" for each requirement. If you cannot describe done in a sentence, the requirement is still fuzzy. - For the build itself, write the agent's limits in three tiers: what it should always do, what it should ask before doing, and what it must never touch. ## Open questions table (template) | Question | Owner | Needed by | Status | |---|---|---|---| | Example: which payment provider? | you | before phase 3 | open | | | | | | --- ## Worked example (delete before using) A compact PRD for a small build, so you can see the finished shape. ```markdown # PRD: Weekly Client Recap Generator ## Business context We send every client a Friday recap. Writing them by hand eats two hours a week and the quality drifts when the week is busy. ## Problem statement We need recaps drafted automatically from the week's notes, in our voice, so a person only edits and sends. ## Who is this for The account lead who sends the recap. Secondary: the client who reads it. ## Why now We just added four accounts. The manual approach does not scale to eight. ## Success outcomes and KPIs - A send-ready draft in under 5 minutes of editing - Zero invented facts, dates, or numbers - Account lead rates 8 of 10 drafts "send with light edits" ## Assumptions - Weekly notes already live in one folder - A person approves every recap before it goes out ## Requirements (Jobs To Be Done, in order) 1. When the week ends, pull that account's notes from the folder. 2. Draft a recap with three sections: Done, Decisions, Next. 3. Flag anything missing a date or owner as "[needs confirmation]." ## Out of scope (this version) - Do NOT send anything automatically. Draft only. - Do NOT pull from email or chat yet. Notes folder only. ## Open questions | Question | Owner | Needed by | Status | |---|---|---|---| | One template for all clients, or per-client? | lead | before phase 2 | open | ```