Brainstorming

Brainstorming

> From obra/superpowers

Purpose

Turn rough ideas into fully-formed designs through collaborative dialogue, NOT immediate implementation.

Use for: Exploring ideas, designing features, architecture decisions

NOT for: Clear mechanical processes with obvious implementation

The Three Phases

Phase 1: Understanding the Idea

• Review existing context
• Read relevant project files
• Understand current architecture
• Note constraints and requirements

• Ask clarifying questions
• ONE question at a time
• Prefer multiple choice when possible
• Open-ended questions are fine too
• Wait for answer before next question

Good: "Should this feature support offline mode?
       A) Yes, full offline support
       B) Yes, limited offline (read-only)
       C) No, online only"

Bad: "What about offline support? And caching?
      Also, how should errors be handled?"

Phase 2: Exploring Approaches

• Present 2-3 different solutions
• Each with clear trade-offs
• Lead with recommended option
• Explain reasoning

## Approach A: Event-Driven (Recommended)
- Pros: Decoupled, scalable, easy to extend
- Cons: More complex debugging, eventual consistency
- Best for: Systems needing flexibility

## Approach B: Direct Integration
- Pros: Simple, immediate consistency
- Cons: Tight coupling, harder to scale
- Best for: Small, stable systems

## Approach C: Hybrid
- Pros: Balance of both
- Cons: Complexity of managing two patterns
- Best for: Gradual migration scenarios

• Discuss trade-offs
• Performance vs simplicity
• Flexibility vs maintainability
• Short-term vs long-term

Phase 3: Presenting the Design

• Present in sections (200-300 words each)
• Architecture overview
• Key components
• Data flow
• Error handling
• Testing strategy

• Validate incrementally
• Get confirmation after each section
• Adjust based on feedback
• Don't dump everything at once

Key Principles

Ask Questions Sequentially

❌ Wrong:
"What's the expected load? How many users?
 What about mobile? Should it work offline?
 What's the budget? Timeline?"

✅ Right:
"What's the expected user load?
 A) <100 concurrent users
 B) 100-1000 concurrent users
 C) 1000+ concurrent users"
[Wait for answer]
"Given that load, should we prioritize...?"

YAGNI Ruthlessly

Remove unnecessary features from ALL designs:

• Don't add "just in case" features
• Don't over-engineer for hypothetical scale
• Don't add flexibility that isn't needed yet

Explore Before Deciding

Never jump to first solution:

• Consider at least 2-3 approaches
• Understand trade-offs of each
• Make informed recommendation

Present Incrementally

Don't dump full design at once:

• Section by section
• Validate understanding
• Adjust as needed

Follow-up Actions

After design is validated:

• Document the design
• Create design doc or ADR
• Include key decisions and rationale

• Commit to version control
• Design docs belong in repo
• Track changes over time

• Move to implementation planning
• Break into tasks
• Estimate effort
• Identify dependencies

Example Session

User: "I want to add notifications to the app"