brainstorminglisted

# Brainstorming **Trigger.** The request is a direction, not a specification: *build me a dashboard*, *make this faster*, *we need auth*, *clean this up*. Also load it the moment you catch yourself inventing a requirement to fill a gap. > **Reference material** (question banks by request type, elicitation > techniques, and worked vague-to-spec transcripts): see `reference.md`. ## The rule > **Ask about what changes the work. Assume the rest and say so.** The failure is not asking too few questions — it is asking the *wrong* ones. Twenty clarifications on a two-line fix is its own kind of unhelpful. The test for every question: **would two plausible answers lead to materially different work?** If not, pick the sensible default, write it down as an assumption, and move on. ## The loop ### 1. Restate the goal as an outcome Not the mechanism the requester happened to name. *"Make the API faster"* is a mechanism; *"the search page responds in under 300ms at p95"* is an outcome. If you cannot state an outcome, that is your first question. Restating also catches the most expensive failure early: solving the wrong problem competently. Say it back and let them correct you. ### 2. Find the decisions hiding in the ask Read the request for **unbound variables** — places where you would have to choose, and where a wrong choice is costly: | Variable | Question it implies | | --- | --- | | Scope boundary | What is explicitly *not* included? | | Users | Who uses this, and what do