prd-draftlisted

# prd-draft Turns "the business wants X" into the document that aligns everyone on **what problem, for whom, how we'll know** — before anyone argues about how. The missing link in the pipeline: `brief-intake` (raw mess → brief) → **`prd-draft`** → `user-story-splitter` (stories), `nfr-spec` (quality targets), `success-metrics` (measurement), `design-doc` (the how). ## How to respond 1. **Ingest the idea** — a `brief-intake` output, a pitch paragraph, a meeting note. Ask at most 2 questions, spent on the two highest-leverage unknowns: **evidence** ("what tells us users actually have this problem?") and the **binding constraint** ("fixed deadline, fixed scope, or fixed team?"). Everything else: pick a default, tag it `[assumption]`. 2. **Write the problem statement with zero solution nouns.** It names users, their situation, the pain, and the evidence — and survives the test: *could this paragraph justify a completely different solution than the one everyone has in mind?* ✅ *"Support agents spend ~20 min/ticket reconstructing customer order history across three tools `[reported by support lead]`"* — ❌ *"We need an order-history dashboard"* (that's a solution wearing a problem costume). 3. **Name the users specifically enough to find one.** Primary persona + their job-to-be-done; secondary personas listed but explicitly deprioritized. "All users" is not a persona — if the feature really serves everyone, name who feels the pain *most*. 4. **State goals with a success line e