Brainstorming
Quick start
When the user wants to add a new feature, first inspect the relevant files and existing patterns. Then ask one focused clarifying question at a time, compare 2-3 viable approaches with tradeoffs, recommend the best one, and get explicit approval before writing any code.
When To Use
- Creating features, components, flows, or user-facing behavior
- Modifying behavior where intent, constraints, or tradeoffs are unclear
- Turning a vague idea into a concrete design
- Deciding between multiple possible implementation approaches
- Planning work that touches several files, modules, or user interactions
When Not To Use
- Pure bug fixes where the expected behavior is already clear
- Mechanical refactors with no product or design decision
- Code review requests
- Direct informational questions
- Requests where the user explicitly asks to skip planning
Core Rules
- Explore the project context first when the answer depends on existing code, docs, or conventions.
- Ask one clarifying question at a time.
- Provide your recommended answer with each question.
- Prefer multiple choice questions when possible.
- Do not implement until the user approves the design.
- Keep the process as small as the task allows.
- If a question can be answered by inspecting the codebase, inspect the codebase instead of asking the user.
Workflows
- Explore context: inspect relevant files, docs, and existing patterns when applicable.
- Summarize what is already known in a few sentences.
- Assess scope: if the request spans multiple independent systems, recommend decomposing it before continuing.
- Ask clarifying questions one at a time until the key decisions are resolved.
- Propose 2-3 approaches with tradeoffs.
- Recommend one approach and explain why.
- Present the design at the right level of detail for the task.
- Ask the user to approve or revise the design.
- After approval, ask whether to proceed with implementation.
Design Approval Gate
Present the design before implementation. Scale the detail to the task.
For small changes, the design may be a short paragraph covering intent, affected area, and verification.
For larger changes, cover:
- Goal
- Non-goals
- User or system behavior
- Affected areas or architecture
- Data flow or state flow, if relevant
- Error handling, if relevant
- Testing or verification
- Open risks
Ask for explicit approval before implementation.
Outputs
Default output is an approved design in chat.
Write a spec file only when the user explicitly requests it. Do not commit anything unless the user explicitly asks.
Advanced features
See REFERENCE.md for detailed question strategies, approach comparison templates, and red flags.
1---2name: brainstorming3description: Guides structured brainstorming to turn ideas into approved designs before implementation. Use when the user wants to plan creative work, new features, behavior changes, components, or ambiguous implementation requests.4---56# Brainstorming78## Quick start910When the user wants to add a new feature, first inspect the relevant files and existing patterns. Then ask one focused clarifying question at a time, compare 2-3 viable approaches with tradeoffs, recommend the best one, and get explicit approval before writing any code.1112## When To Use1314- Creating features, components, flows, or user-facing behavior15- Modifying behavior where intent, constraints, or tradeoffs are unclear16- Turning a vague idea into a concrete design17- Deciding between multiple possible implementation approaches18- Planning work that touches several files, modules, or user interactions1920## When Not To Use2122- Pure bug fixes where the expected behavior is already clear23- Mechanical refactors with no product or design decision24- Code review requests25- Direct informational questions26- Requests where the user explicitly asks to skip planning2728## Core Rules29301. Explore the project context first when the answer depends on existing code, docs, or conventions.312. Ask one clarifying question at a time.323. Provide your recommended answer with each question.334. Prefer multiple choice questions when possible.345. Do not implement until the user approves the design.356. Keep the process as small as the task allows.367. If a question can be answered by inspecting the codebase, inspect the codebase instead of asking the user.3738## Workflows39401. Explore context: inspect relevant files, docs, and existing patterns when applicable.412. Summarize what is already known in a few sentences.423. Assess scope: if the request spans multiple independent systems, recommend decomposing it before continuing.434. Ask clarifying questions one at a time until the key decisions are resolved.445. Propose 2-3 approaches with tradeoffs.456. Recommend one approach and explain why.467. Present the design at the right level of detail for the task.478. Ask the user to approve or revise the design.489. After approval, ask whether to proceed with implementation.4950## Design Approval Gate5152Present the design before implementation. Scale the detail to the task.5354For small changes, the design may be a short paragraph covering intent, affected area, and verification.5556For larger changes, cover:5758- Goal59- Non-goals60- User or system behavior61- Affected areas or architecture62- Data flow or state flow, if relevant63- Error handling, if relevant64- Testing or verification65- Open risks6667Ask for explicit approval before implementation.6869## Outputs7071Default output is an approved design in chat.7273Write a spec file only when the user explicitly requests it. Do not commit anything unless the user explicitly asks.7475## Advanced features7677See [REFERENCE.md](REFERENCE.md) for detailed question strategies, approach comparison templates, and red flags.
geril07