Brainstorm

Brainstorm

Sharpen a vague idea into a confirmed proposal through one-question-at-a-time dialogue. The cheapest moment to find ambiguity is before any plan, spec, or code exists — once building starts, switching costs lock in the wrong thing.

When to use

• The ask is underspecified — missing who, why, what success looks like, or the binding constraint.
• New feature, project, or "refine this idea" / "stress-test my thinking."
• User says "brainstorm", "grill me", "interview me", "refine this idea", "头脑风暴", "帮我打磨想法", or "盘问我".
• You're tempted to silently fill ambiguous requirements before a spec exists.

Not for: unambiguous asks ("rename this variable"), pure info requests, or when the user has explicitly asked for speed over verification.

Steps

1. Hypothesize with a confidence number. If in a codebase, explore project context first (Glob/Grep/Read for architecture, patterns, constraints) before forming the hypothesis. Before asking anything, write your best read of what the user wants in one sentence, plus an honest confidence (0–100%):

   HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
   CONFIDENCE: ~30% — missing: who it's for, what "metrics" means, what success looks like
   

   Below ~70%, append what's still unresolved. The number forces honesty — if you can't predict the user's reaction to the next three questions, the number is wrong.

2. Ask ONE question, with a guess attached.

   Q: <one focused question>
   GUESS: <your hypothesis for the answer, with reasoning>
   

   One question per message — never a batch. Batching encourages skim-reading and surface answers; the third question often depends on the first. Attach a guess so the user reacts to a wrong hypothesis faster than generating from scratch. Be visibly willing to be wrong.

3. Listen for "want vs. should want." The most dangerous answers pattern-match best-practice talk ("scalable", "clean architecture", "the standard approach") without specifics. When you hear these, ask: "If you didn't have to justify this to anyone, what would you actually want?" That question often does more work than the previous five. For structured problem-validation methods — the Mom Test interview (past behavior, not future opinion), JTBD switching interview, opportunity-solution tree, working backwards / PR-FAQ — load references/discovery-methods.md.

4. Diverge then converge. Once intent is clear, generate 3–8 idea variations using lenses from references/techniques.md (inversion, constraint removal, simplification, SCAMPER, first principles). Cluster into 2–3 directions and stress-test each against user value, feasibility, and differentiation. Surface hidden assumptions explicitly: what you're betting is true, what could kill it, what you're choosing to ignore.

5. Repeat until ~95% confidence. The stop test: can you predict the user's reaction to the next three questions you'd ask? If yes, you have shared understanding. If no, ask the next question. If several rounds pass without confidence rising, step back and reframe — something foundational is missing. Tell the user.

6. Self-review the proposal. Before presenting, scan for placeholders, internal contradictions, ambiguity (could any line be read two ways?), and scope (is this one proposal or three?). Fix inline. A "Not Doing" list makes trade-offs explicit — focus is about saying no to good ideas.

7. Propose — restate and confirm. Write back what you now think the user wants, tight (5–8 lines), in their language:

   - Outcome:      <one line>
   - User:         <one line — who benefits>
   - Why now:      <one line — what changed>
   - Success:      <one line — how we know it worked>
   - Constraint:   <one line — the binding limit>
   - Out of scope: <one line — non-negotiable; silent disagreement about non-goals is half of misalignment>
   

   The gate is an explicit "yes." "Whatever you think," "sounds good," and silence are not yes — re-ask with two concrete options framed as a choice. Loop until explicit confirmation, then hand off to the spec skill.

Output: ROADMAP.md — product positioning, target users, core features, multi-version plan with per-version acceptance items. Concise (mermaid-heavy); it is the project-wide view on main. Each version's detailed PRD/TECH/PLAN live under docs/vX.Y/ on the version branch (see spec / architecture / breakdown Output). When discovery interviews ran (Step 3, references/discovery-methods.md), also produce docs/research/interview.md — consolidated user-interview findings (past behavior, workarounds, willingness to pay) that justify the roadmap.

Verify

• An explicit hypothesis with a confidence number was stated in the first turn.
• Every confidence below ~70% had a one-line reason attached.
• Questions were asked one at a time, each with a guess attached.
• Multiple directions were explored, not just the first idea.
• A want-vs-should-want probe ran when sophistication-signaling answers appeared.
• A Not-Doing list makes trade-offs explicit.
• A concrete restate (Outcome / User / Why now / Success / Constraint / Out of scope) was written.
• The user confirmed with an explicit yes — not delegation, not ambiguity.
• A spec is writable from the confirmed proposal.

References

• ${CLAUDE_PLUGIN_ROOT}/references/engineering-principles.md — discipline shared by every skill.
• ${CLAUDE_PLUGIN_ROOT}/references/product-principles.md — product discipline (need≠feature, behavior is data, validate before building, say no to good ideas, discovery precedes delivery).
• references/techniques.md — ideation frameworks (SCAMPER, HMW, first principles, JTBD), decision techniques (design tree, questionnaire handoff), evaluation rubric, and worked examples.
• references/discovery-methods.md — problem-validation methods (Mom Test interview, JTBD switching interview, opportunity-solution tree, working backwards / PR-FAQ, Lean Canvas, MVP validation loop).