Brainstorming

Core Principle

Design before code. Always.

Don't jump into implementation. Tease out the spec through conversation first.

The Brainstorming Process

Step 1: Understand the Goal

Ask clarifying questions:

• •What problem are we solving?
• •Who is the user?
• •What does success look like?
• •What are the constraints?

One question at a time - Don't overwhelm with multiple questions.

Step 2: Explore the Space

• •What are the possible approaches?
• •What are the trade-offs?
• •What similar problems exist?
• •What patterns apply?

Step 3: Propose Alternatives

Always present 2-3 approaches before settling:

## Option A: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

## Option B: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

## Option C: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

**Recommendation:** Option [X] because...

Step 4: Incremental Validation

Present design in digestible chunks:

• •Show one section at a time
• •Get sign-off before moving on
• •Allow for course corrections

Step 5: Document the Design

Save to: docs/plans/YYYY-MM-DD-<topic>-design.md

YAGNI Ruthlessly

During brainstorming, actively remove:

• •Features that "might be nice"
• •Edge cases that "could happen"
• •Abstractions for "future flexibility"
• •Optimizations for "scale we might need"

Ask: "Do we need this for the MVP?"

Question Techniques

Multiple Choice Preferred

Instead of: "How should we handle errors?" Ask: "For error handling, should we: A) Return error codes, B) Throw exceptions, C) Use Result types?"

Constrained Questions

Instead of: "What should the API look like?" Ask: "Should this be REST, GraphQL, or RPC?"

Assumption Surfacing

• •"I'm assuming X. Is that correct?"
• •"This depends on Y. Is that available?"
• •"The constraint seems to be Z. Agreed?"

Output: Design Document

# [Feature Name] Design

## Problem Statement
What problem are we solving?

## Goals
- Goal 1
- Goal 2

## Non-Goals
- Explicitly out of scope item 1
- Explicitly out of scope item 2

## Proposed Solution
Overview of the approach

## Alternatives Considered
Why we didn't choose other approaches

## Technical Design
### Component A
...
### Component B
...

## Open Questions
- Question 1
- Question 2

## Next Steps
1. Step 1
2. Step 2

Transition to Implementation

After design is approved:

1. •Ask: "Ready to set up for implementation?"
2. •Use using-git-worktrees skill to create isolated workspace
3. •Use writing-plans skill to create detailed implementation plan

Anti-Patterns

Don't Do This

• •Start coding before design is clear
• •Present only one option
• •Ask open-ended questions when specific ones work
• •Skip validation of each section
• •Assume requirements are complete
• •Over-engineer the initial design