brainstorm

Turn a vague idea into a right-sized spec through a short design dialogue — before any code.

What it does

Most wasted work comes from building the wrong thing confidently. brainstorm front-loads that disagreement with a sharp YAGNI bias: the first real question is always should this exist at all — is there a stdlib, native, or existing-code path that removes the work entirely?

A hard rule holds throughout: no implementation actions until the spec is presented and approved — no files, no scaffolding, no "I'll just start" — even for "trivial" tasks, since those hide the unexamined assumption that costs you a day.

Flow

1. Ground it. Read the relevant code and docs before asking anything — come in with context, not a blank stare.
2. Interrogate the premise. First question is whether the thing needs to exist. If a stdlib/native/existing path removes the work, say so and stop.
3. One question at a time. Ask the single highest-leverage clarifying question, wait, then decide the next from the answer. Never dump a questionnaire.
4. Propose 1–3 approaches. For each: what it is, the main tradeoff, and why you'd pick it — with a plain recommendation.
5. Present the spec. Problem, chosen approach, scope boundaries (explicitly what is out), key decisions, open risks — right-sized to the task.
6. Loop until sign-off. Revise on feedback; never proceed on silence.
7. Save + hand off. Write the spec to docs/specs/<slug>.md and hand off to implement.

When to use it

When you say "brainstorm", "help me think through X", "what should we build", or present a fuzzy, ambitious, or unscoped request. It ends with an approved spec doc ready for /commonkit:implement.