brainstorm-socratic

This is the mode with a person in it. It applies when the answer is the owner's to give: what to build, for whom, what counts as done, which tradeoff they have to live with. When the decision is the session's own, use docs/graph/skills/brainstorm-internal.md; brainstorm.mode-selection in docs/graph/protocols/brainstorm.md owns the test.

A goal that arrives as "build me a thing" is not yet ready to specify or plan. This skill ONLY converges the goal from vague to precise: the UI emerges later from the user flow, and framework and architecture wait for architect, after research. It is applied inside docs/graph/protocols/brainstorm.md, which owns entry conditions, the grill.md output map, and the explicit-confirmation exit; this file owns the method.

How to brainstorm

Ask the smallest set of questions that change the design the most

Bad: "What colour?", "What should the homepage look like?", "What framework?"

Good: "Who is this for and what do they do today instead?", "What counts as success one month in?", "What is explicitly out of scope?"

Limit: one to three questions per turn, and the main flow before its edge cases, because each set of answers reshapes the next question and twenty questions at once get answered with platitudes.

Reflect every two answers

After every two answers, write a one-paragraph reflection: "I now believe X. Tell me where I'm wrong."

This forces the brainstorm to converge and lets the user disagree precisely.

Hard cap at nine questions total

If you haven't converged in nine questions, accept the gaps. Mark each one as an assumption in grill.md §12, write what you have, and proceed to specify.

A brainstorm that drags past nine questions is usually trying to specify and plan at the same time. Stop; move to specify. Brainstorm is a step: it converges enough to start specifying, and the spec refines further.

The convergence checklist

By the end of brainstorm, you can write the following without hand-waving:

1. Problem statement. One sentence. "X user does Y today; we want them to be able to Z instead."
2. Primary user. A specific role and context, not "developers" or "users".
3. First useful slice. The smallest end-to-end thing that delivers the outcome for one well-defined case.
4. Success criteria. Measurable, with a time horizon. Quantitative where possible; qualitative with explicit rubrics where not.
5. Non-goals. Three to five things this is explicitly not; they are what holds scope.
6. Operating constraints. Runtime, security, privacy, data, cost, latency, compliance, maintenance: at least the ones that bind.
7. Shaped options. Two to four named technical approaches with one-line summaries, not full designs. Each option names the tradeoff it makes.
8. Risks and assumptions. The top three risks; every assumption that, if false, changes the plan.

What the owner actually reads

Converging is half the job. The other half is that the person can tell what they are agreeing to.

Everything this mode puts in front of the owner (the reflections, the options, the problem statement they are asked to confirm) goes through docs/graph/skills/humanizer.md as it is drafted, carrying every fact intact.

An options table is a working artifact. A person confirming "yes, that one" off a table has agreed to a row, not to a decision, and the difference surfaces later as "that isn't what I thought I picked". State what is being decided, why it is on the table now, what each option commits them to, and what it would cost to change later. The confirmation this mode waits for is only worth waiting for if it was informed.

Reference files

• docs/graph/protocols/brainstorm.md: the workflow: entry, output map, exit.
• docs/graph/protocols/specify.md: the protocol that consumes brainstorm output.
• docs/graph/templates/grill.template.md: where brainstorm output is recorded.