prd-writerlisted

# Product Spec Write the spec that gets a team building the right thing. A good PRD isn't a feature list — it's a shared understanding of the problem, who has it, what "done" means, and how you'll know it worked. It closes the gaps where projects usually go sideways. ## When to use this skill Use Product Spec to turn a feature idea, request, or rough notes into a product requirements document (PRD) or one-pager. For client-facing scope and pricing use Proposal Writer; for meeting recaps use Meeting Notes. ## What a PRD needs to answer - **Problem** — what user pain or business need this addresses, and why now. If you can't state the problem, the feature isn't ready. - **Users & context** — who it's for and the situation they're in when they hit this. - **Goals & non-goals** — what this explicitly will and won't do. Non-goals prevent scope creep as much as goals drive it. - **Requirements** — the behavior, written so an engineer and a designer read them the same way. Separate must-haves from nice-to-haves. - **Success metrics** — how you'll measure whether it worked. - **Open questions & risks** — the unknowns, surfaced rather than buried. ## Principles - **Problem before solution.** Anchor on the user's pain; a solution with no stated problem is a guess. - **Unambiguous requirements.** If a requirement can be read two ways, pick one and make it explicit. - **Right altitude.** Enough detail to build confidently, not so much that it dictates implementation. State intent