brainstorm - SKILL.md Agent Skill

name: brainstorm description: > Pre-code Socratic design exploration — when the options don't exist yet. Use when: "I haven't figured out the approach", "help me think through X", "what should this even be / 還沒想清楚", "explore how to do X before we build", "我不確定要怎麼做", "尚未成形 / 沒有方向". DISCOVERS the options, surfaces 2-3 genuinely different approaches, and GATES implementation until you approve a design. Not for: deciding between options that ALREADY exist on the table (→ think-tank), external best-practice research (→ survey), an approach you've already chosen (→ references/plan-template.md to author the plan, then dev-flow), or a quick known fix (→ dev-flow).

brainstorm — discover the design before any code exists

The discriminator vs neighbours: do the options exist yet?

No options yet / fuzzy need → brainstorm (this skill) — explore, then converge on a design.
Options on the table, need to decide → think-tank (multi-perspective) / think-tank-dialectic.
Need to know what others do → survey (external research).
Approach already chosen → author the plan (references/plan-template.md) → dev-flow.

This is a gate: do NOT invoke any implementation skill or write code until the user approves a design.

Protocol

1. Explore the real need — Socratic, ONE question at a time

Don't propose solutions yet. Ask one focused question, wait for the answer, then ask the next. Surface the actual problem, the constraints, the success picture, the no-go zones. Stop asking once you can restate the need in one sentence the user confirms. (One-at-a-time matters: a wall of questions gets a thin answer; a single sharp question gets a real one.)

2. Surface 2–3 genuinely different approaches

Not strawmen. Each approach: a one-line essence, its honest tradeoffs, what it's best/worst at. They must differ in kind (different architecture / different mechanism), not just in parameter. If you can only find one real approach, say so — that's a finding, not a failure.

3. Converge to a design spec

Once the user leans toward an approach, write a short design spec: the chosen approach, why it beat the others (1 line each), the key decisions made, and the open questions that remain. Keep it tight — it's the thing the plan will be built from, not the plan itself.

4. The approval gate

Present the design spec and ask for explicit approval. Nothing downstream runs without it. On approval, hand off:

to references/plan-template.md to author the plan (then dev-flow to execute), or
directly to dev-flow if the work is small enough to skip a formal plan. On "not yet" → keep exploring (back to step 1/2) — do not force forward.

Boundaries

Discovers, doesn't decide-between-knowns — the moment the options are already enumerated and the question is "which one", that's think-tank, not this.
Explores internally, doesn't research externally — if the gap is "what do others do", chain to survey first, then bring its findings back here.
Designs, doesn't author the plan — the structured plan doc is references/plan-template.md's job; this skill produces the design spec that feeds it.
Fits research-to-ship as an optional Phase-0 (discover the design before its Phase-1 research/plan), for topics that start fuzzy rather than from a clear question.