| name | brainstorming |
| description | Use when starting any feature, project, or design work. Guides collaborative design refinement through incremental questioning before any code is written. |
Brainstorming
Core Principle
Design before code. Always.
Don't jump into implementation. Tease out the spec through conversation first.
The Brainstorming Process
Step 1: Understand the Goal
Ask clarifying questions:
- What problem are we solving?
- Who is the user?
- What does success look like?
- What are the constraints?
One question at a time - Don't overwhelm with multiple questions.
Step 2: Explore the Space
- What are the possible approaches?
- What are the trade-offs?
- What similar problems exist?
- What patterns apply?
Step 3: Propose Alternatives
Always present 2-3 approaches before settling:
## Option A: [Name]
- Pros: ...
- Cons: ...
- Best when: ...
## Option B: [Name]
- Pros: ...
- Cons: ...
- Best when: ...
## Option C: [Name]
- Pros: ...
- Cons: ...
- Best when: ...
**Recommendation:** Option [X] because...
Step 4: Incremental Validation
Present design in digestible chunks:
- Show one section at a time
- Get sign-off before moving on
- Allow for course corrections
Step 5: Document the Design
Save to: docs/plans/YYYY-MM-DD-<topic>-design.md
YAGNI Ruthlessly
During brainstorming, actively remove:
- Features that "might be nice"
- Edge cases that "could happen"
- Abstractions for "future flexibility"
- Optimizations for "scale we might need"
Ask: "Do we need this for the MVP?"
Question Techniques
Multiple Choice Preferred
Instead of: "How should we handle errors?" Ask: "For error handling, should we: A) Return error codes, B) Throw exceptions, C) Use Result types?"
Constrained Questions
Instead of: "What should the API look like?" Ask: "Should this be REST, GraphQL, or RPC?"
Assumption Surfacing
- "I'm assuming X. Is that correct?"
- "This depends on Y. Is that available?"
- "The constraint seems to be Z. Agreed?"
Output: Design Document
# [Feature Name] Design
## Problem Statement
What problem are we solving?
## Goals
- Goal 1
- Goal 2
## Non-Goals
- Explicitly out of scope item 1
- Explicitly out of scope item 2
## Proposed Solution
Overview of the approach
## Alternatives Considered
Why we didn't choose other approaches
## Technical Design
### Component A
...
### Component B
...
## Open Questions
- Question 1
- Question 2
## Next Steps
1. Step 1
2. Step 2
Transition to Implementation
After design is approved:
- Ask: "Ready to set up for implementation?"
- Use
using-git-worktreesskill to create isolated workspace - Use
writing-plansskill to create detailed implementation plan
Anti-Patterns
Don't Do This
- Start coding before design is clear
- Present only one option
- Ask open-ended questions when specific ones work
- Skip validation of each section
- Assume requirements are complete
- Over-engineer the initial design