| name | brainstorm |
| description | Explore options and pick a direction before committing to a goal or plan. Use when the user wants to think through approaches, weigh trade-offs, or decide between alternatives — not yet ready to define success criteria or slice work. Hard rule: no code, files, or implementation until the user explicitly approves a direction. |
| metadata | {"short-description":"Explore options and pick a direction"} |
Brainstorm
Goal
Help the user move from a fuzzy idea to a chosen direction quickly, by exploring 2 concrete approaches and converging on one. This is the "which way" step that comes before goal-shaping (define-goal) or planning (ship-first-plan).
Hard rule
Do NOT write code, scaffold files, or take any implementation action until the user has explicitly approved a direction. This applies even when the task seems obvious. The whole point is to pause and think before building.
When to use
Use this skill when:
- The user says "let's brainstorm", "help me think through", "what are the options for", or similar.
- The right approach is genuinely unclear and a quick exploration would prevent wasted work.
- You're about to propose a feature, component, or behavior change with non-trivial trade-offs.
Skip this skill when:
- The task is mechanical (one obvious correct approach).
- The user has already chosen a direction.
- The work is small enough that the brainstorm would take longer than just doing it.
Workflow
Operate in read-only mode. Do not write or update files.
-
Discover (quick)
- Skim relevant context: existing patterns, conventions, related code or notes. One round of reads, not deep exploration — if discovery would need many rounds, delegate to
explorer first.
- Ask up to 3 focused questions only if needed. Batch them in one message. Prefer multiple-choice over open-ended.
- If the request is already clear, skip questions and go straight to Propose.
-
Propose exactly 2 approaches
- Present 2 concrete approaches with trade-offs. Not 1 (no real choice), not 5 (decision paralysis).
- Lead with your recommendation and a one-line reason.
- Keep each option to a short paragraph. Scale detail to the weight of the task.
- If you genuinely can only think of one viable approach, say so and explain what was eliminated.
-
Converge
- Get explicit approval before proceeding. "Sounds good" or "go with option 2" counts.
- If the user rejects both, revise and re-propose — max 2 revise rounds.
- If still not aligned after 2 rounds, ask the user to state the direction directly. A good-enough direction chosen quickly beats a perfect one chosen slowly.
-
Capture and hand off
- Restate the chosen direction in one or two sentences (what, why, key constraints).
- Point to the natural next step:
- For feature work that needs to be sliced and shipped → suggest
ship-first-plan.
- For work that needs a sharper success criterion → suggest
define-goal.
- For straightforward execution → proceed directly.
- Do not create a separate design doc unless the user asks for one.
Principles
- Speed over ceremony — the value is in the thinking, not the artifact. A short conversation that produces a good decision beats a polished document that delays one.
- YAGNI — design only for what's needed now. Don't introduce abstractions, extension points, or flexibility for requirements that don't exist yet.
- Bias toward action — when two options are close in quality, pick one and move. Movement creates clarity.
- Batched discovery — ask all clarifying questions in one message, not one at a time.
- Proportional depth — a small decision might compress steps 1–2 into a single message. A new subsystem deserves more exploration in step 2.
- Two options, one recommendation — always lead with what you'd do and why. Don't present neutral menus.