brainstorming
Transform rough ideas into detailed designs through structured dialogue. Use before implementation to refine requirements.
When & Why to Use This Skill
This Claude skill facilitates structured brainstorming and design refinement, helping developers transform vague concepts into actionable technical specifications through Socratic dialogue and iterative validation. It ensures that requirements are fully understood and architectural trade-offs are evaluated before implementation begins, significantly reducing development rework.
Use Cases
- Refining ambiguous feature requests into concrete technical requirements using a sequential, one-question-at-a-time Socratic approach.
- Evaluating multiple architectural solutions by comparing pros, cons, and trade-offs to select the most efficient path forward.
- Applying YAGNI (You Aren't Gonna Need It) principles to prune speculative features and focus strictly on MVP (Minimum Viable Product) goals.
- Generating comprehensive design documentation that covers system architecture, data flow, error handling, and testing strategies for team alignment.
| 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