brainstorming

When to use this

Fire when any of these are true:

• The user describes something they want to build, change, or explore and the shape isn't settled yet — "I want to add X", "we should rethink Y", "how should we approach Z".
• A request is ambiguous in a way that changes what you'd build, not just a detail you can pick a default for.
• You're tempted to start writing a spec, a plan, or code from a one-line prompt. Stop — align on the shape first.

Don't fire for well-specified tasks ("rename this function", "fix this failing test") or where the user has already decided and wants execution. This is for the fuzzy front end, not for things that are clear.

The output of brainstorming is a shared understanding, not an artefact. When it's settled, hand off: to /requirement to write up what the product must do, to planner for sequencing, or straight to [[test-driven-development]] for small work.

The rule

Ask one question at a time. Diverge before you converge. Reach agreement on the shape before producing anything — don't write a spec, a plan, or code while the problem is still fuzzy.

Why

A vague idea contains hidden decisions. If you guess at them and start producing, you bake your guesses into a spec or code, and the user only discovers the mismatch after you've spent effort on the wrong thing. Surfacing those decisions as questions, before any artefact exists, is far cheaper to correct — a sentence, not a rewrite.

One question at a time is the part that's easy to skip and matters most. A wall of five questions makes the user triage and answer shallowly, and your later questions are often invalidated by the answer to the first. Asking one, hearing the answer, and letting it shape the next question is how a real design conversation converges — each answer narrows the space the next question explores.

Diverge-then-converge keeps you from premature commitment. Early, widen: surface alternatives, name the non-goals, question the framing. Late, narrow: pick, and write it down. Doing those in the wrong order — converging before you've explored — is how you end up with a confidently-built wrong answer.

How to apply

1. Separate the problem from the proposed solution. Users often arrive with a solution ("add a cache"). Find the problem underneath ("this page is slow") — the best shape may not be the one they named. Reflect it back to check you've got it.
2. Diverge first. Name the real goal, the non-goals (what this is explicitly not), the constraints, and a couple of genuinely different approaches. Make the option space visible before collapsing it.
3. Ask one question at a time. Pick the single highest-leverage unknown — the one whose answer most changes the shape — and ask just that. Offer options with a recommendation when it helps the user decide. Wait for the answer. Let it determine the next question. Repeat.
4. Converge. When the decisions that change the shape are settled, stop diverging and state the agreed shape back: problem, approach, non-goals, open risks. Get explicit agreement.
5. Hand off. Route the agreed shape to the right next step — /requirement for a written requirement, planner for phased sequencing, or directly into implementation for small work. Don't let brainstorming bleed into producing the artefact; that's the next tool's job.

Foot-guns

• Asking everything at once. A numbered list of five questions isn't a conversation; it's a form. The user answers shallowly and your follow-ups are stale. One question, then listen.
• Converging too early. Latching onto the first plausible approach before the space has been explored. Spend the cheap divergence now; it's far cheaper than rebuilding.
• Solving the stated problem instead of the real one. Taking the user's proposed solution at face value when the underlying need points somewhere better. Always surface the problem under the solution.
• Brainstorming the obvious. Interrogating a task that was already clear wastes the user's time and reads as evasion. If there are no shape-changing unknowns, skip straight to doing the work.
• Never landing. Endless questions with no convergence. The goal is an agreed shape, then a handoff — once the shape-changing decisions are made, stop and write it down.
• Producing the artefact mid-conversation. Quietly drafting the spec or the code while still asking questions. Keep the phases separate: agree first, produce second, via the right tool.