Why Superpowers Forces Brainstorming Before Any Code Is Written

What Brainstorming Solves

Prevent agents from entering implementation too early. Agents can quickly generate file structures, component names, interfaces, and page skeletons, which looks efficient but often wraps an ill‑defined problem into a hard‑to‑modify draft.

Before any design is shown and approved, no implementation actions, no code, no scaffolding, no calling implementation‑type skills are allowed.

This rule is the core of the skill: it is not merely a warm‑up, but the main gate.

Brainstorming vs. Simple Requirement Clarification

Many people mistake brainstorming for a simple “requirements discussion”. In reality, it pushes a vague idea into a approved, documented, and plan‑ready design state . The process follows a strict sequence:

Review project context.

Clarify the problem step by step.

Propose 2–3 solution approaches.

Present the design in segments and confirm each.

Write a spec document.

Self‑review the spec.

Have the user review the spec.

Only then switch to the writing-plans skill.

The endpoint is not “the discussion feels clearer”, but a design that is written, checked, confirmed, and usable as input for subsequent planning.

Key Distinctions

Brainstorming forces multiple solutions with explicit trade‑offs, exposing the decision space instead of silently picking one. It also requires segment‑by‑segment confirmation, reducing the risk of an entire design being wrong.

Actual Output: Spec, Not Chat

The final deliverable is a spec file, e.g. docs/superpowers/specs/2023-09-15‑feature‑design.md, followed by:

Self‑review of the spec (checking for TODOs, contradictions, scope issues, ambiguous statements).

User review of the spec.

This documentation protects the quality of later implementation because a vague spec leads to precise but misguided execution.

Why Even Simple Changes Must Pass Brainstorming

The skill applies to todo lists, single‑function utilities, and config changes. It warns against the anti‑pattern “this is too simple, no design needed”, because simple changes often cause hidden refactorings such as unintended behavior changes, boundary violations, or default‑behavior modifications.

“This is too simple, not worth designing first.” – identified as a common mistake.

Many reworks happen not on complex features but on those prematurely judged as simple.

Brainstorming as the First Pillar Between Design and Implementation

It is not a demand‑gathering skill but the foundational step that turns ideas into a stable, reviewable, inheritable design.

Practical Tips When Using Brainstorming

Do not use it for endless back‑and‑forth without converging on boundaries, constraints, and success criteria.

It excels when you have a direction but haven’t solidified it; it stops the “let’s start coding while we figure it out” illusion.

Ask one question at a time to reduce noise and keep each query focused on reducing uncertainty.

If the problem is large, split the project into sub‑projects and run the full spec‑>plan‑>implementation loop on the first sub‑project only.

One‑Sentence Summary

Superpowers doesn’t let the agent “think of ideas”; it stops the agent from sliding into implementation before the design is solidified.

Next Step

After a completed brainstorming spec, the next article will explore why the writing-plans skill is written in such detail, covering failing tests, verification commands, commit messages, and file‑by‑file change plans.