jessedegans Brainstorm
The Rule
No code until you understand the problem. No scaffolding, no "let me just set up the structure," no implementation. Explore first.
The Process
1. Explore what exists
Before asking a single question:
- Read relevant files, check recent commits, understand the current state
- If there's a codebase, understand its patterns before proposing anything new
- If there's prior work, understand why it was done that way
2. Ask clarifying questions
One question at a time. Prefer multiple choice when possible.
Focus on:
- Purpose: What problem does this solve? Who is it for?
- Constraints: What can't change? What's the budget (time, complexity, scope)?
- Success criteria: How will we know this works?
- Scope: What's in, what's explicitly out?
Don't ask questions you can answer by reading the code or docs.
3. Propose 2-3 approaches
For each approach:
- What it is (one sentence)
- Key trade-off (what you gain vs. what you give up)
- Your recommendation and why
Lead with your recommended option. Be opinionated, not neutral.
4. Get approval
Present the chosen direction clearly. Wait for explicit approval before writing any code.
If the user says "just do it" without engaging with the design, that's fine. The point isn't ceremony. The point is that you've thought about it even if they haven't.
Rationalization Prevention
| Thought | Reality |
|---|---|
| "This is too simple to need brainstorming" | Simple things have hidden assumptions. Ask one question. |
| "I already know what to build" | Then it'll take 30 seconds to confirm. Do it anyway. |
| "Let me just scaffold the structure first" | Structure IS a design decision. Brainstorm first. |
| "The user seems impatient" | A 2-minute brainstorm prevents a 2-hour rewrite. |