using-superpowers and brainstorming: Why You Can't Skip Design and Jump Straight to Building

A lot of people's default opening move with AI coding assistants is: "Add a feature for me." Sounds reasonable — but if the agent immediately starts modifying files, you'll quickly enter a classic scenario: three revisions in, you realize the AI Agent misunderstood you from the very first version. This article covers two roles that often appear together: using-superpowers (how to properly activate the whole system of habits) and brainstorming (think it through before starting). The single goal: get design and alignment first, then let the AI Agent start building.

What using-superpowers Manages

Think of using-superpowers as a coach: it's not writing code for you — it's reminding the agent (and incidentally reminding yourself) — how to actually use Superpowers, so the installation wasn't wasted.

In practice, it's often doing a few things: figuring out which skills are available in the current conversation, which to read first in which context, and — before any implementation work begins — which process skill to invoke. Simply put: it manages "opening moves and routing" — keeping you from diving straight into implementation and letting the whole line go off-course.

using-superpowers and the often-following brainstorming will also pull you back to "explore context first": look at what files and conventions already exist in the project, what constraints your team or environment has that can't be crossed, what's been recently changed — not out of habit for its own sake, but because if your mental model of requirements doesn't match the real codebase, your first implementation attempt is likely to be thrown out entirely. Taking a brief moment to scan the situation is almost always cheaper than rewriting later.

The Core Flow of brainstorming

The core of a brainstorming skill isn't "casual conversation to pass the time" — it's a practical production line that roughly goes like this (in concept, no need to memorize jargon):

Surface the intent: What problem are you actually trying to solve, for whom? What does success look like?
Clarify the constraints: Time, tech stack, legacy code that can't be touched, deployment risk — state what you can up front.
List viable directions: More than one path, turning trade-offs into "multiple choice" instead of "telepathy."
Align before moving forward: Only after you've confirmed (or explicitly chosen a direction) does the workflow advance to more detailed planning or implementation.

So it's not "brainstorming just needs to feel lively" — it's about turning uncertainty into selectable options and leaving a record of "which option we actually chose." Without this step, implementation easily becomes a parallel sprint with everyone talking past each other.

Why You Need Design Approval First

"Design approval" doesn't need to be polished — but it needs to hit a baseline: you and the agent have a consistent answer to "what to build, what not to build yet, and what counts as done."

If you skip this, common consequences include: the agent thinks you want a refactor, but you just want a small button; the agent thinks it can swap out a package, but your team has a policy against it; the agent thinks "done" means the screen renders, but you need passing tests and accessibility checks.

Getting approval first isn't bureaucracy — it's moving expensive misunderstandings to the cheap word-count stage to resolve them. Truly, this is so much more pleasant than midnight diff hell.

Which Tasks Should Go Through brainstorming First

An easy heuristic for beginners: whenever you have a thought like "I'm not really sure what the best approach is," brainstorm first. For example:

New features: user flow, data sources, and edge cases are still in the fog.
Modifying old code: worried about breaking behavior others depend on, or you're unsure where the side effects are.
Architectural trade-offs: two or more approaches, each with costs.
You can say "I want X" but can't say "and not Y": scope is still expanding.

Conversely, if you already have a clear ticket, clear files, clear acceptance criteria, and the change is genuinely small enough that misunderstanding is nearly impossible — then you might consider a shorter workflow. (But during your beginner phase, I'd still suggest: err on the side of asking two more questions.)

Common Misconceptions

Treating brainstorming as just chat: No options, no trade-offs, no conclusions, then "okay you just go do it" — this is the same as not doing it at all.
Already decided on a solution, but pretending to discuss it: Wastes steps and wastes the agent's compute; better to just say "I'm choosing A, please help me check for risks."
Skipping the using-superpowers rhythm: Walking straight into code the moment you open a conversation removes your own quality guardrails. It won't always blow up, but when it does blow up, it's usually very hard to recover.
Thinking design approval = can never change: Discovering new information later and adjusting is totally fine. The key is communicate changes clearly when adjusting, not silently refactoring until it's unrecognizable.

Next Steps

What's the Difference Between spec, plan, and implementation? The Right Workflow for Superpowers
To lay out the whole path from start to finish: Superpowers Beginner Course.

Back to Series Overview

This article covers the roles and timing for using-superpowers and brainstorming. To return to the series reading map and recommended order, open the Superpowers Beginner Course.