brainstorming

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

1. Review existing project context (files, docs, patterns)
2. Ask clarifying questions sequentially - one per message
3. Use multiple-choice when feasible (easier to answer)
4. Focus on:
5. What is the purpose/goal?
6. What are the constraints?
7. What does success look like?
8. Who/what is affected?

Key rule: One question at a time - avoid overwhelming

Phase 2: Exploring Options

1. Present 2-3 different approaches
2. Lead with your recommended approach
3. 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]

1. Discuss conversationally, not prescriptively
2. Be open to hybrid approaches

Phase 3: Design Presentation

1. Break design into digestible sections (200-300 words each)
2. Validate incrementally after each section
3. Cover:
4. Architecture overview
5. Key components
6. Data flow
7. Error handling
8. Testing approach
9. 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

1. Save design to docs/plans/YYYY-MM-DD-[feature].md
2. Commit the design document
3. Transition to implementation using writing-plans skill