How Superpowers Brainstorming Skill Improves Design Before Coding

Mar 18, 2026

The Problem

When I ask an AI coding assistant to build something, it usually jumps straight to code. I describe a feature, and within seconds, the AI starts generating implementation files.

This seems efficient. But I’ve learned that this eagerness causes problems:

The AI builds what I said, not what I meant
Hidden assumptions surface mid-implementation
Edge cases I didn’t consider create bugs later
“Simple” features turn out to be more complex than expected

What I need is a way to force the AI to slow down and understand the problem before writing any code. That’s exactly what the Superpowers brainstorming skill does.

What the Brainstorming Skill Does

The brainstorming skill is a hard gate. It blocks all implementation until the AI has:

Explored project context
Asked clarifying questions (one at a time)
Proposed 2-3 approaches with trade-offs
Presented a design and gotten my approval
Written a design document
Gone through a spec review loop

The skill is explicit about this:

“Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.”

This isn’t optional. It’s mandatory for all creative work—creating features, building components, adding functionality, or modifying behavior.

The Anti-Pattern: “This Is Too Simple To Need A Design”

The most common objection I hear is: “This feature is simple. Can’t we just code it?”

The brainstorming skill has a response to this:

“‘Simple’ projects are where unexamined assumptions cause the most wasted work.”

I’ve experienced this many times. A “simple” todo list turns out to need priorities, categories, due dates, and recurring tasks. A “simple” config change breaks backward compatibility. A “simple” utility function needs to handle null values, empty strings, and malformed input.

Every project—no matter how small—goes through the brainstorming process. This isn’t bureaucracy. It’s insurance against misunderstandings.

The Brainstorming Checklist

When I trigger the brainstorming skill, the AI follows a 9-step process:

Step 1: Explore Project Context

The AI starts by checking the codebase:

Recent git commits
Existing documentation
Related files and patterns
Project structure

This ensures the design fits the existing architecture.

Step 2: Offer Visual Companion (If Needed)

For topics involving visual questions—mockups, layouts, diagrams—the AI offers to use a browser-based companion. This offer is sent as a separate message, not combined with questions.

Step 3: Ask Clarifying Questions

The AI asks questions one at a time. Not a laundry list. One question, then wait for my answer.

The skill prefers multiple choice when possible:

AI: Should this be a REST API or GraphQL endpoint?

    A) REST API - simpler, widely understood
    B) GraphQL - flexible queries, but more setup

Open-ended questions are fine too, but always one per message. This keeps the conversation focused and prevents me from skipping important decisions.

Step 4: Propose 2-3 Approaches

Once the AI understands what I’m building, it presents options:

## Design Options

### Option A: In-Memory Cache
- Pros: No external dependencies, fast reads
- Cons: Lost on restart, not distributed
- Best for: Single-instance deployments

### Option B: Redis Cache
- Pros: Persistent, distributed, battle-tested
- Cons: Additional infrastructure, network latency
- Best for: Multi-instance deployments

### Option C: Database Query Cache
- Pros: No new infrastructure, transactional consistency
- Cons: Adds load to database, limited eviction control
- Best for: Low-traffic applications

My recommendation: Option B (Redis) - your app already uses Redis for sessions, and the multi-instance deployment pattern is likely in your future.

Each option includes trade-offs and a recommendation. The AI doesn’t just present choices—it helps me make informed decisions.

Step 5: Present Design

The AI presents a design, scaled to the complexity of the project:

Small change: brief design in chat
Medium feature: structured design document
Large system: full specification with diagrams

I get to approve each section before moving forward.

Step 6: Write Design Document

After approval, the AI saves the design to:

docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

This creates a record of decisions that I can reference later.

Step 7: Spec Review Loop

The AI dispatches a reviewer subagent to check the spec. Issues are fixed, then re-reviewed. The loop continues until approved, with a maximum of 3 iterations.

Step 8: User Reviews Written Spec

The AI asks me to review the written spec before proceeding. This catches any misunderstandings before code is written.

Step 9: Transition to Implementation

Only after all these steps does the AI invoke the writing-plans skill to begin implementation.

The Question Format

The skill uses a specific format for questions. Multiple choice is preferred:

AI: What's your read/write pattern?

    A) Read-heavy (90% reads, 10% writes)
    B) Balanced (50% reads, 50% writes)
    C) Write-heavy (10% reads, 90% writes)

This forces me to think in concrete terms rather than vague descriptions.

When open-ended questions are needed, they’re still asked one at a time:

AI: What's your cache invalidation strategy? I need to understand how stale data can be before it causes problems.

Design for Isolation

The brainstorming skill emphasizes modular design:

“Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently.”

For each unit, the AI answers three questions:

What does it do?
How do you use it?
What does it depend on?

This creates designs that are inherently testable and maintainable.

Process Flow

The complete flow looks like this:

User Request
    |
    v
+-------------------+
| Explore Context   |
+-------------------+
    |
    v
+-------------------+
| Ask Questions     |<---+
| (one at a time)   |    |
+-------------------+    |
    |                    |
    v                    |
+-------------------+    |
| Propose Options   |----+ (if more questions needed)
+-------------------+
    |
    v
+-------------------+
| Present Design    |<---+
+-------------------+    |
    |                    |
    v                    |
+-------------------+    |
| User Approval?    |--No-+
+-------------------+
    | Yes
    v
+-------------------+
| Write Design Doc  |
+-------------------+
    |
    v
+-------------------+
| Spec Review Loop  |
+-------------------+
    |
    v
+-------------------+
| User Reviews Spec |
+-------------------+
    |
    v
+-------------------+
| writing-plans     |
| (implementation)  |
+-------------------+

The key insight: writing-plans is the only skill that brainstorming ever invokes. It’s the single exit point to implementation.

My Experience

When I first started using the brainstorming skill, I found it frustrating. I wanted code, not questions. But I noticed something after a few sessions:

Before brainstorming skill:

I’d describe a feature
AI would generate code
Code would work… mostly
I’d find edge cases later
Rework, debugging, patches

After brainstorming skill:

I’d describe a feature
AI would ask questions
I’d realize I hadn’t thought things through
We’d design together
Code would be generated
Code would work, with tests, handling edge cases

The “extra” time spent in brainstorming was repaid many times over in reduced debugging and rework.

The Visual Companion Feature

One feature that sets this skill apart is the visual companion. When the AI knows that questions will involve visual content—mockups, layouts, diagrams—it offers a browser-based tool.

The offer is sent as its own message:

AI: I'll be asking some questions about visual layout. Would you like me to open a browser-based companion where we can sketch together?

This keeps visual discussions in a visual medium rather than trying to describe layouts in text.

Why This Matters

The difference between a junior and senior developer isn’t raw intelligence. It’s the discipline to understand requirements before implementing.

The brainstorming skill gives AI agents this discipline. It forces them to:

Ask instead of assume
Clarify instead of guess
Design before coding
Get approval before proceeding

This doesn’t slow down development. It speeds it up by preventing the rework that comes from misunderstood requirements.

Summary

In this post, I showed how the Superpowers brainstorming skill improves design before coding. The key point is that no project is too simple to skip design—unexamined assumptions in “simple” projects cause the most wasted work.

The skill enforces a 9-step process: explore context, ask questions one at a time, propose options with trade-offs, present design, write documentation, review, and only then proceed to implementation. This creates a hard gate between requirements and code.

If you’re using Superpowers, you already have this skill. If you’re not, consider how much rework you do because requirements weren’t clear. The brainstorming skill is your insurance policy against that rework.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Superpowers Repository
👨‍💻 Claude Code

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!