Brainstorming & Design
The first and most important rule: CANNOT WRITE CODE UNTIL USER APPROVES DESIGN.
Why Brainstorming Comes First
The single most expensive mistake in software development is building the wrong thing correctly. You can have perfect code, full test coverage, clean architecture — and still deliver something that doesn't solve the actual problem.
Brainstorming isn't a formality. It's the phase where misunderstandings surface before they become bugs. It's where scope is clarified, approaches are compared, and everyone gets aligned on what "done" actually means.
In Superpowers, brainstorming is enforced with a hard gate: the AI is explicitly prohibited from writing any production code until the user has reviewed and approved a design. This is not a soft recommendation. It's a behavioral constraint.
The Hard Gate
╔══════════════════════════════════════════════════════════════╗
║ HARD GATE: NO CODE MAY BE WRITTEN UNTIL THE USER ║
║ HAS EXPLICITLY APPROVED THE PROPOSED DESIGN. ║
╚══════════════════════════════════════════════════════════════╝
When you invoke the brainstorming skill, the AI enters a mode where code generation is blocked. It can write pseudocode, diagrams, file structure sketches, or example snippets to illustrate an approach — but no real implementation code until you say "approved" or an equivalent confirmation.
This gate exists because premature code is the primary source of wasted effort. Once code exists, it creates psychological pressure to keep it. People argue in favor of code they've already written. Design decisions get constrained by implementation choices that were made too early. The hard gate prevents this trap.
The 7-Step Brainstorming Process
Step 1: Explore
The AI begins by restating the request in its own words to confirm understanding. It identifies the core problem being solved — not just the feature being requested.
Example: "It sounds like the real problem is that users can't track their order status after checkout. Is that correct?"
Step 2: Question
The AI asks clarifying questions — one at a time. Not a list of 10 questions upfront. One question, wait for the answer, then the next question if needed.
This rule exists because batched questions are overwhelming and often result in half-answers. Sequential questions lead to more accurate information and a more natural conversation.
Step 3: Approaches
Once the AI has enough information, it presents 2–3 distinct approaches to solve the problem. Each approach includes:
- A brief description
- Key technical decisions involved
- Trade-offs (pros and cons, not just cheerleading)
- Rough estimate of complexity
Step 4: Present
The approaches are presented clearly with a recommendation when appropriate. The AI does not hide behind "it depends" — it gives an opinion while making clear the assumptions behind that opinion.
Step 5: Spec
After you select or modify an approach, the AI writes a design specification — a concise document describing what will be built, what won't be built, and how the pieces fit together. This becomes the north star for the implementation plan.
Step 6: Review
You review the spec. You can ask for changes, clarification, or a different approach. The AI iterates until the spec is accurate.
Step 7: Transition
Once you approve the spec, brainstorming ends. The AI acknowledges the gate is lifted and transitions to the planning phase. The approved spec becomes the input to Writing Plans.
The One Question at a Time Rule
This rule is important enough to call out explicitly.
Wrong approach:
"Before I can help you, I need to know: (1) What database are you using? (2) Do you need authentication? (3) Should this be a REST or GraphQL API? (4) What's your deployment target? (5) Do you need caching?"
This is overwhelming and often produces vague answers because the user tries to answer everything at once.
Correct approach:
"What database are you using?"
Wait for answer, then:
"Do you need user authentication for this feature?"
Wait for answer, then continue.
Sequential questions feel like a conversation. Batched questions feel like a form. Conversations produce better information.
Multiple Choice When Possible
Wherever a question has known common answers, the AI should present them as options rather than open-ended questions.
Less useful:
"What kind of data storage do you need?"
More useful:
"For data storage, which fits best? A) PostgreSQL (relational, ACID compliant) B) MongoDB (document store, flexible schema) C) Redis (in-memory, caching/sessions) D) Something else (please specify)"
Multiple choice reduces cognitive load, anchors the conversation in real options, and speeds up the brainstorming phase.
Presenting 2–3 Approaches with Trade-offs
When the AI presents approaches, it should follow this structure:
## Approach A: [Name]
**Description:** [What this approach does]
**Technical decisions:** [Key choices this approach makes]
**Pros:** [What's good about it]
**Cons:** [What's bad about it, honestly]
**Best for:** [When this approach makes sense]
## Approach B: [Name]
...
## Recommendation
[AI's recommended approach and the reasoning behind it]
The AI should never present only one approach (that's not a choice) or more than three (that's decision paralysis). Two to three is the useful range.
Visual Companion (v5.0 Feature)
Superpowers v5.0 introduced Visual Companion — the ability for the AI to produce ASCII diagrams, flow charts, and architecture sketches as part of the brainstorming output.
These visuals help communicate complex designs without requiring external tools. For example:
User → [API Gateway] → [Auth Service]
↘
[Order Service] → [Database]
↗
[Inventory Service]
When a design involves multiple components, data flows, or state transitions, ask the AI to include a visual companion in its spec.
Anti-Patterns to Avoid
The brainstorming phase commonly fails in these ways:
| Anti-Pattern | What it looks like | Why it's harmful |
|---|---|---|
| Rushing to code | "I'll just start implementing and we can adjust" | Sunk cost fallacy kicks in immediately |
| False agreement | AI says "understood" but hasn't confirmed requirements | Misunderstandings survive into implementation |
| Single approach | AI proposes one option and asks for approval | Not a real design choice |
| Over-specification | Design doc covers every edge case before basic flow is agreed | Analysis paralysis |
| Scope creep acceptance | AI adds features "while we're at it" | Balloons the implementation, delays delivery |
| Vague approval | User says "sounds good" to a spec they haven't read | Gate becomes theater |
Pre-Planning Checklist
Before transitioning from brainstorming to planning, verify:
If any item is unchecked, do not proceed to planning. Return to brainstorming and fill the gap.
Starting a Brainstorming Session
To invoke the brainstorming skill explicitly:
"I want to add [feature]. Let's brainstorm before writing any code."
Or use the slash command if available:
/brainstorm I want to build a notification system
The AI will enter brainstorming mode and the hard gate will activate. Nothing gets built until you say the design is approved.
The discipline of brainstorming pays compound interest. Every hour spent aligning on requirements before coding saves 3–5 hours of rework later. The hard gate isn't a bureaucratic hurdle — it's an investment.