The fastest way for an AI coding agent to create expensive work is to start coding too soon. A request arrives, the agent infers the missing requirements, selects an architecture, edits several files, and produces a plausible patch. The patch may compile. It may even pass a narrow test. But it can still solve the wrong problem.
Superpowers is a methodology and a set of composable skills intended to change that default. Rather than treating code generation as the first step, it asks the agent to clarify the outcome, develop and get approval for a design, make an implementation plan, use true red/green test-driven development, carry out the work in small tasks, and review what was built.
That is not bureaucracy for its own sake. It is a response to the fact that AI agents are very good at filling gaps with plausible assumptions.
The core idea: gates before generation
Superpowers describes a coding-agent workflow that begins when the agent recognizes it is building something. Instead of jumping into implementation, it steps back and asks what the user is really trying to accomplish. It then develops a specification, presents the design in readable chunks, and waits for sign-off before producing a detailed plan.
Only after approval does the workflow move to implementation. The repository emphasizes red/green TDD, YAGNI build only what is needed and DRY, avoiding needless duplication. It also describes subagent-driven development for executing and reviewing tasks.
Each gate exists because a different kind of failure is cheaper to catch early:
Clarification catches misunderstood outcomes.
Design review catches wrong shapes and missing constraints.
Planning catches hidden dependencies and sequencing errors.
Tests catch behavioral regressions.
Review catches mismatches between the intended change and the actual diff.
Why vague requests are dangerous
Consider the request: “Add team invitations.” That sounds actionable, but it leaves a large number of product and system decisions unanswered. Are invites email-based? Does an invitation expire? Can it be revoked? What role does an invited person receive? What happens if they already have an account? What happens if they belong to another organization? Is the action auditable? Can an administrator resend an invitation? Which failure states are visible to users?
A coding agent that immediately creates an invitations table has already made decisions. A structured workflow makes those decisions visible before they become database migrations, endpoints, and UI states that are expensive to unwind.
Phase one: establish the outcome
Good clarification focuses on observable success, constraints, and non-goals. Ask for the user story, affected actors, existing behavior that must remain stable, and the acceptance checks that will show the task is complete.
For the invitation example, a useful outcome might be: “Organization owners can invite an email address to a workspace. Invites expire after seven days, can be revoked, grant a selected role on acceptance, and must not expose workspace existence to unauthenticated users.” That is already more useful than “add invitations” because it gives design and tests a target.
Phase two: agree on a design
The Superpowers README describes showing design material in chunks small enough for a human to read and approve. That is a practical design principle for agent collaboration. A giant wall of architecture text is difficult to review; a sequence of focused decisions is easier to challenge.
A design should cover the parts most likely to create irreversible work:
Domain entities and ownership boundaries
API contracts and error behavior
Authorization checks
State transitions and lifecycle rules
Data migration and backward compatibility
Observability and operational failure modes
Explicit non-goals
Approval is not a ceremony. It is the moment a human says, “Yes, this is the product behavior we mean to own.”
Phase three: write an implementable plan
After design sign-off, the plan should break work into small, ordered tasks. Each task should identify the relevant files or components, the change, and the validation method. The plan should be specific enough that another competent developer or another agent can execute it without reinterpreting the original request.
For example, an invitation feature might be sliced into: define domain rules and tests; add persistence and migration; add service-layer authorization; expose API routes; implement email delivery abstraction; add UI states; add integration tests; document rollout and monitoring. The exact order depends on the codebase, but the principle is stable: build vertical, verifiable increments.
True red/green TDD with an agent
Superpowers emphasizes true red/green TDD. The important distinction is temporal: tests should express expected behavior before implementation is accepted. Writing tests after code can still be useful, but it often records what the implementation happened to do instead of what the system should do.
For an invitation flow, a red test might assert that a revoked invite cannot be accepted, that an expired invite produces a specific error, or that a non-owner cannot create an invite. The implementation then moves the tests to green. This makes behavior reviewable in a form more durable than conversational claims.
TDD does not guarantee a correct product decision. It guarantees that selected behavior is checked. That is why clarification and design must precede it.
Subagents and review
The methodology describes subagent-driven development: agents can work through specific tasks, inspect work, and review outcomes. Parallelism is useful only when task boundaries are real. Separate agents may investigate independent modules or review a completed change, but two agents editing the same design decision without coordination can multiply confusion.
Use subagents to create independent evidence: one investigates existing conventions, one drafts tests, one reviews a diff against the approved design. Keep a single source of truth for decisions and require the final reviewer to compare the result against that source.
When to use Superpowers
This approach is valuable for new features, multi-file refactors, regressions with unclear causes, public API changes, and tasks where a mistaken assumption creates real rework. It is deliberately not the fastest method for changing a typo, renaming a local variable, or making a clearly scoped configuration edit.
The question is not “Is this task large?” Ask instead: “What does it cost if the agent chooses the wrong interpretation?” If the answer is high, the structure pays for itself.
Adopting the workflow without overdoing it
Start with one medium-risk feature.
Require a written success statement and non-goals.
Review the design before code changes begin.
Require a task plan with tests attached to each behavioral slice.
Review the final diff against the approved design, not only against the tests.
Record what produced rework and tune the workflow.
Teams should not judge the method by how polished the agent’s plan sounds. Judge it by concrete outcomes: fewer late requirement changes, clearer diffs, more reliable tests, and less rediscovery during review.
What Superpowers does not replace
No agent workflow can replace product ownership, security review, or accountability for production changes. A well-structured plan can still optimize the wrong metric. A green suite can still omit a real-world edge case. Treat the framework as a way to make decisions and evidence visible not as a guarantee of correctness.
Bottom line
Superpowers is useful because it gives an eager coding agent permission to pause. It turns a vague request into an agreed design, a plan, tested behavior, and a reviewable change. For meaningful engineering work, that pause is often the fastest part of the process.
