| name | brainstorming |
| description | Transform rough ideas into detailed designs through structured dialogue. Use before implementation to refine requirements. |
Brainstorming & Design Refinement
Transform rough ideas into validated designs through structured Socratic dialogue before any implementation begins.
When to Use
- Starting a new feature with unclear requirements
- Exploring solution approaches
- Refining vague ideas into concrete plans
- Before writing any implementation code
The Workflow
Phase 1: Understanding
- Review existing project context (files, docs, patterns)
- Ask clarifying questions sequentially - one per message
- Use multiple-choice when feasible (easier to answer)
- Focus on:
- What is the purpose/goal?
- What are the constraints?
- What does success look like?
- Who/what is affected?
Key rule: One question at a time - avoid overwhelming
Phase 2: Exploring Options
- Present 2-3 different approaches
- Lead with your recommended approach
- Explain trade-offs for each:
## Option A: [Name] (Recommended)
**Approach:** [Description]
**Pros:** [Benefits]
**Cons:** [Drawbacks]
**Best when:** [Use case]
## Option B: [Name]
**Approach:** [Description]
**Pros:** [Benefits]
**Cons:** [Drawbacks]
**Best when:** [Use case]
- Discuss conversationally, not prescriptively
- Be open to hybrid approaches
Phase 3: Design Presentation
- Break design into digestible sections (200-300 words each)
- Validate incrementally after each section
- Cover:
- Architecture overview
- Key components
- Data flow
- Error handling
- Testing approach
- Remain open to revisions
Key Principles
YAGNI (You Aren't Gonna Need It)
Ruthlessly eliminate speculative features:
| Ask | If No → |
|---|---|
| Is this required for MVP? | Cut it |
| Does the user need this now? | Defer it |
| Are we guessing at requirements? | Clarify first |
One Question at a Time
# Bad
What's the user flow? And what data do we need? Also, what about error handling?
# Good
What happens when a user clicks the submit button?
[Wait for answer]
What data needs to be sent to the server?
[Wait for answer]
Explore Before Committing
Don't jump to the first solution. Consider:
- What's the simplest approach?
- What's the ideal approach (no constraints)?
- What could go wrong?
- How would this be solved differently in 5 years?
Output: Design Document
After validation, produce:
# Design: [Feature Name]
## Goal
[One sentence]
## Approach
[2-3 paragraphs]
## Components
- [Component 1]: [Purpose]
- [Component 2]: [Purpose]
## Data Flow
[Diagram or description]
## Error Handling
[Strategy]
## Testing Plan
[Approach]
## Open Questions
[If any remain]
Post-Design
- Save design to
docs/plans/YYYY-MM-DD-[feature].md - Commit the design document
- Transition to implementation using writing-plans skill