| name | brainstorming |
| description | Use before any creative work — features, components, functionality. Explores intent, requirements, and design before any code. |
Brainstorming
HARD GATE: Never write code, scaffold, or implement until user approves a design.
Process
- Explore context — files, docs, recent commits
- Ask questions — one at a time, prefer multiple choice
- Propose 2-3 approaches — with trade-offs, lead with recommendation
- Present design — scaled to complexity, get approval section by section
- Self-review — fix placeholders, contradictions, ambiguity inline
- User reviews spec — wait for approval
- Transition — invoke
plan-mode skill for implementation plan
Key Rules
- One question per message
- "Simple" projects still need a design (even if short)
- If project has independent subsystems → decompose first, brainstorm each separately
- YAGNI ruthlessly — remove unnecessary features
- Incremental validation — present, get approval, then proceed
Design Doc Template
# <Topic> Design
## Context
[Current state, what needs to change]
## Design
[Architecture, components, data flow]
## Success Criteria
[How we know it works]
Self-Review Checklist
- Any TBD/TODO placeholders? → fix
- Sections contradict each other? → fix
- Scope too large for one plan? → flag
- Ambiguous requirements? → pick one, make explicit