Brainstorming

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

Converted and distributed by TomeVault — claim your Tome and manage your conversions.