brainstorm

Brainstorm a Feature or Improvement

Brainstorming answers WHAT to build through collaborative dialogue. It precedes the deeper technical planning that determines HOW.

The durable output is a requirements-only plan under docs/plans/. Write it with source: brainstorm so planning does not invent product behavior, scope boundaries, or success criteria.

This skill does not implement code. It explores, clarifies, and documents decisions for later planning or execution.

Core Principles

1. Assess scope first. Match ceremony to the size and ambiguity of the work.
2. Be a thinking partner. Suggest alternatives, challenge assumptions, and explore what-ifs instead of only extracting requirements.
3. Resolve product decisions here. User-facing behavior, scope boundaries, and success criteria belong in this workflow. Detailed implementation belongs in planning.
4. Keep implementation out by default. Do not include libraries, schemas, endpoints, file layouts, or code-level design unless the brainstorm itself is inherently technical or architectural.
5. Right-size the artifact. Simple work gets a compact requirements-only plan or brief alignment. Larger work gets a fuller plan. Do not add ceremony that does not help planning.
6. Apply YAGNI to carrying cost, not coding effort. Prefer the simplest approach that delivers meaningful value. Avoid speculative complexity, but low-cost polish or delight is worth including when its ongoing cost is small.

Interaction Rules

These rules apply to every brainstorm, including the universal (non-software) flow routed to references/universal-brainstorming.md.

1. Ask one question at a time. One per turn, even when sub-questions feel related.
2. Prefer single-select multiple choice. Use it when choosing one direction, one priority, or one next step.
3. Use multi-select rarely and intentionally. Only for compatible sets such as goals, constraints, non-goals, or success criteria that can all coexist.
4. Default to the platform's blocking question tool. Use AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema is not loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi. Fall back to numbered options in chat only when no blocking tool exists or the call errors, not because a schema load is required. Never silently skip the question. Exception. Visual-probe gate: on an inherently visual topic, the first shape/behavior/state/layout/flow/diagram decision must be preceded by the separate text-vs-visual offer before it is raised. See Phase 1.3.
5. Use an open-ended question only when the question is genuinely open. Drop the blocking tool when the answer is inherently narrative, when options would steer a diagnostic answer, or when you cannot write 3-4 genuinely distinct, plausibly-correct options without padding.
6. Open-ended questions must be specific enough to elicit a substantive answer. Give the user something concrete to anchor on. Good: "What is the most concrete thing someone's already done about this: paid for it, built a workaround, quit a tool over it?" Too thin: "What's your take?"