---
name: prd-writer
description: Write a product requirements document (PRD), product spec or feature brief from rough notes, threads or feedback, using the team template in template.md. Use when the user asks to write, draft, structure or review a PRD, spec, or requirements for a feature. Keeps unknowns as open questions instead of inventing them.
---

# PRD writer

## Files
- `template.md`: the PRD structure. Always read it and follow its sections and order.

## Workflow
1. **Collect inputs.** Read everything the user provided: pasted notes, files or paths they mention, linked documents available in the workspace. Do not search for or assume other sources.
2. **Check critical information.** You need: the problem being solved, who has it, and how success will be judged. If any is missing, ask up to five short questions in one message and wait. If the user says to draft anyway, proceed and record each gap in Open questions.
3. **Draft** by filling every section of `template.md`:
   - Use the user's terms for the product, features and users.
   - **Goals** state outcomes. **Success metrics** name the metric and how it is measured; targets only if the user gave them, otherwise `Target: TBD` plus an open question.
   - **Non-goals** list related things explicitly out of scope; infer candidates from the input and mark them `(proposed)`.
   - **User stories**: "As a <user>, I want <capability>, so that <outcome>."
   - **Functional requirements**: one behavior each, ID `FR-n`, priority `must | should | could`, marked `(proposed)` unless the user set it. Each has at least one acceptance criterion in Given/When/Then form that a tester could verify.
   - **Non-functional requirements** (performance, security, privacy, accessibility, localization): only those relevant; mark assumptions.
   - **Dependencies and risks**: from the input; label anything inferred as `(inferred)`.
   - **Open questions**: every unknown, with a suggested owner role (PM, Design, Engineering, Data, Legal, Support) and when the answer is needed (before design, before build, before launch).
4. **Self-check** before saving:
   - Every requirement is testable and has an ID and priority.
   - No invented numbers, dates, research findings, customer names or technical facts. Search your draft for numbers and confirm each came from the input.
   - Every TBD has a matching open question.
   - No section is left with template markers.
5. **Save** as Markdown. Default path: `docs/prd/<kebab-case-feature-name>.md` when working in a repository; otherwise the current directory or the location the user names. Do not overwrite an existing file without asking.
6. **Reply** with the file path, a three-line summary, and the open questions that block design or build.

## Style
- Plain, specific language. Short sentences. No marketing tone.
- Describe behavior, not UI layout, unless the user's input specifies UI.
- Keep the PRD under about 1,500 words unless the scope clearly requires more; move detail to an appendix section.

## Reviewing an existing PRD
If the user asks to review a PRD, check it against the template and the self-check list, then return: missing sections, untestable requirements with suggested rewrites, unstated assumptions, and missing open questions. Do not rewrite the whole document unless asked.