| name | brainstorming |
| description | Design and planning before coding. Explores problem space, generates approaches, evaluates tradeoffs, and recommends a path forward. |
Brainstorming
Core Purpose
Explore the problem space thoroughly BEFORE writing any code. Generate multiple approaches, evaluate tradeoffs, and recommend a clear path forward with rationale. This prevents wasted effort on wrong approaches.
Operating Philosophy
What This Skill IS
- Problem explorer who fully understands the requirements
- Option generator who produces multiple viable approaches
- Tradeoff analyst who honestly evaluates each option
- Decision recommender who provides clear guidance
- Risk identifier who surfaces potential issues early
What This Skill IS NOT
- A rubber stamp for the first idea
- A perfectionist who demands the "best" solution
- A delayer who explores indefinitely
- A decision-avoider who presents options without recommendation
Activation Protocol
When activated:
- Clarify the goal - What are we trying to achieve?
- Identify constraints - Time, tech, team, existing patterns
- Explore the problem space - Research relevant code, patterns, dependencies
- Generate options - At least 2-3 viable approaches
- Evaluate tradeoffs - Honest pros/cons for each
- Recommend - Clear recommendation with rationale
Phase 1: Problem Understanding
Gather Context
Questions to answer:
- What exactly needs to be built or changed?
- Who/what will use this? (users, other code, external systems)
- What are the success criteria?
- What constraints exist? (performance, compatibility, timeline)
- What existing patterns should be followed?
Context to gather:
- Read relevant project CLAUDE.md
- Check existing similar implementations
- Understand data flow and dependencies
- Identify integration points
Define Scope Boundaries
Be explicit about:
- What IS in scope
- What is NOT in scope
- What assumptions are being made
Phase 2: Option Generation
Generate Multiple Approaches
Always produce at least 2-3 options. Force yourself to think beyond the obvious first answer.
Option generation techniques:
- The obvious approach - What would a typical implementation look like?
- The simple approach - What's the minimum viable solution?
- The robust approach - What handles all edge cases elegantly?
- The existing pattern - What does this codebase already do for similar problems?
- The opposite approach - What if we inverted our assumptions?
For Each Option, Document:
| Aspect | Description |
|---|
| Summary | One-line description |
| Implementation | Key steps/changes required |
| Pros | Advantages of this approach |
| Cons | Disadvantages and risks |
| Effort | Relative complexity (Low/Med/High) |
| Fits Pattern | Does it match existing codebase patterns? |
Phase 3: Tradeoff Analysis
Evaluation Criteria
Rate each option against relevant criteria:
| Criterion | Weight | Option A | Option B | Option C |
|---|
| Simplicity | | | | |
| Maintainability | | | | |
| Performance | | | | |
| Testability | | | | |
| Fits existing patterns | | | | |
| Future flexibility | | | | |
| Risk level | | | | |
Risk Assessment
For each option, identify:
- Technical risks - What could go wrong during implementation?
- Integration risks - What could break existing functionality?
- Maintenance risks - What creates future pain?
Phase 4: Recommendation
Make a Clear Recommendation
Don't just present options - recommend one with clear rationale.
## Recommendation: Option [X]
**Why this option:**
- [Primary reason]
- [Secondary reason]
**Key tradeoffs accepted:**
- [What we're giving up and why it's acceptable]
**Risks to monitor:**
- [What could still go wrong]
**Implementation approach:**
1. [First step]
2. [Second step]
3. [etc.]
When to Escalate
Escalate to human decision if:
- Options have dramatically different long-term implications
- Technical constraints conflict with stated requirements
- No clear winner emerges from analysis
- Decision requires business/product context you don't have
Output Format
# Brainstorming: [Feature/Change Name]
## Problem Statement
[Clear description of what we're trying to achieve]
**Success criteria:**
- [ ] [Criterion 1]
- [ ] [Criterion 2]
**Constraints:**
- [Constraint 1]
- [Constraint 2]
**Scope:**
- IN: [What's included]
- OUT: [What's explicitly excluded]
---
## Context Gathered
- [Relevant existing patterns found]
- [Dependencies identified]
- [Integration points]
---
## Options
### Option A: [Name]
**Summary:** [One line]
**Implementation:**
1. [Step]
2. [Step]
**Pros:**
- [Pro]
**Cons:**
- [Con]
**Effort:** Low / Medium / High
---
### Option B: [Name]
[Same structure]
---
### Option C: [Name]
[Same structure]
---
## Comparison
| Criterion | Option A | Option B | Option C |
| --------------- | -------- | -------- | -------- |
| Simplicity | | | |
| Maintainability | | | |
| Fits patterns | | | |
| Risk | | | |
---
## Recommendation
**Recommended:** Option [X]
**Rationale:**
[Why this is the best path forward]
**Tradeoffs accepted:**
[What we're consciously giving up]
**Next steps:**
1. [First implementation step]
2. [Second step]
3. [etc.]
---
## Open Questions
- [Any remaining uncertainties for human input]
Integration with Workflow
This skill should be invoked:
- BEFORE starting any non-trivial implementation
- When requirements are ambiguous
- When multiple approaches seem viable
- When changing existing architecture
- When the "obvious" solution feels too simple
The output of this skill feeds directly into implementation planning.
Calibration Guidelines
Match Depth to Complexity
| Task Complexity | Brainstorming Depth |
|---|
| Simple change | 5 min - Quick sanity check |
| Standard feature | 15-20 min - Full analysis |
| Architectural change | 30+ min - Deep exploration |
| Multi-system integration | Extensive - May need multiple sessions |
Avoid Common Pitfalls
- Don't skip brainstorming for "obvious" solutions (they often aren't)
- Don't generate options just to generate options (each must be viable)
- Don't hide behind analysis paralysis (make a recommendation)
- Don't ignore existing codebase patterns (consistency matters)
- Don't over-engineer the analysis (match effort to stakes)
Time-Boxing
If analysis is taking too long:
- Document what's known so far
- Identify the key uncertainty blocking progress
- Make a provisional recommendation
- Note what would change the recommendation
- Move forward with implementation
Special Protocols
When Existing Code Constrains Options
If the codebase strongly suggests a particular approach:
- Acknowledge it as the "path of least resistance"
- Still generate at least one alternative
- Evaluate whether the constraint is worth challenging
- Default to consistency unless there's strong reason to deviate
When Time Pressure Exists
- Focus on viable vs non-viable rather than optimal
- Reduce to 2 options maximum
- Make faster recommendation with noted assumptions
- Flag what analysis was skipped for later review
When Requirements Are Unclear
- Document assumptions explicitly
- Present options that cover different interpretations
- Recommend asking for clarification on specific points
- Don't proceed with implementation until key ambiguities resolved
