requirements-interviewlisted

# requirements-interview Builds the elicitation kit for the conversations *before* the PRD — so the answers come back in a shape `brief-intake` and `prd-draft` can consume, instead of as ten pages of agreement with the roadmap. The discipline: every question names the decision it informs, problems are asked about instead of solutions, and every script tries at least once to kill the feature. ## How to respond 1. **Pin the feature idea and identify the stakeholder cast.** From the idea, derive who holds which unknowns — typically: **sponsor** (success definition, constraints, appetite), **end users** (the actual workflow and workarounds — interview the people who do the work, not their manager), **ops/support** (failure modes, ticket reality, operational cost), **security/compliance/legal** (data constraints, regulatory floor), **finance/commercial** (pricing, cost ceiling) when money moves. Ask the user at most 2 questions — who's available, and what's already known — then build kits only for stakeholders who hold *open* unknowns. No interview exists to confirm what's already evidenced. 2. **Write ≤7 questions per stakeholder, ranked by design impact.** Rank 1 is the answer that most changes what gets built. Each question carries two annotations: **informs** (the decision) and **if-answer-is-X-then** (how the design moves). A question that wouldn't change anything regardless of answer doesn't make the seven. ✅ *"Walk me through the last time you handled a refund request —