Superpowers: Why Agent Autonomy Needs a Process
This series examines obra/superpowers, a software-development methodology designed to guide coding agents from an initial request to a tested, reviewed, and deliberately integrated change. Its central question is not whether an agent can write code quickly. It is whether that speed can remain accountable when the request is vague, the codebase is unfamiliar, the conversation is long, and a plausible answer is easier to produce than a reliable one. Understanding Superpowers gives readers a practical way to distinguish an autonomous coding agent from a governed development workflow.
A coding agent can search files, edit them, run commands, and sometimes delegate work to other agents. Those abilities are useful, but they do not by themselves establish what should be built, which branch is safe to change, whether a test can catch a regression, or whether “done” means anything beyond the agent's confidence. Superpowers addresses those gaps by treating development as a chain of decisions and evidence. It places some decisions before implementation, some inside the implementation loop, and some at the point where work is reported or integrated.
The problem is not simply writing code
Imagine asking an agent to “add a small feature.” The phrase sounds actionable, but it leaves several questions hidden. What user problem does the feature solve? What existing behavior must remain unchanged? Is the change really small in this codebase? Does “working” mean a successful local example, a passing test, or a safe change on a separate branch? An agent that answers these questions privately may still produce a polished solution to the wrong problem.
The risk grows because agent output often looks finished before it is trustworthy. A code block can be syntactically correct while violating an unstated constraint. A test can pass because it checks a mock or repeats the implementation's own calculation. A fix can remove an error at the point where it appears while leaving the invalid value that caused it untouched. A final message can say “done” because a command was run earlier, even though the current tree has changed since then.
Superpowers' response is not to eliminate autonomy. It is to place boundaries around the transitions where an unsupported assumption becomes expensive. The workflow asks the agent to look for a relevant process skill before acting, refine intent before implementation, isolate the workspace, turn the design into an executable plan, write tests that can fail for the right reason, investigate failures before patching them, and submit work to review. Fresh verification and an explicit integration choice close the loop.
That sequence is the subject of this series. The individual practices matter, but their relationship matters more: each one prepares evidence or a boundary that the next one can use.
What Superpowers is—and is not
obra/superpowers describes itself as a complete methodology built on composable skills and initial instructions. A skill is not just a page of advice that a person may consult if they remember it. In the intended system, skills shape what the agent notices and what action it takes next. One skill establishes how to find and invoke other skills. Another governs brainstorming. Others govern worktrees, plans, testing, debugging, delegation, review, and delivery.
This makes Superpowers different from a single “better prompt.” A prompt may ask an agent to be careful, but it does not necessarily define where care must appear in the lifecycle or what counts as evidence. Superpowers instead gives separate responsibilities to separate stages. Brainstorming handles intent and scope. Planning preserves design decisions in a form an implementer can follow. TDD tests the desired behavior before production code exists. Debugging investigates an unexpected result rather than accumulating guesses. Review creates a second inspection surface. Verification controls the claims made at the end.
The distinction is important because the methodology does not promise that every skill will be needed in full for every request. Its brainstorming workflow classifies work as a spike, a bounded change, or an architectural effort. A feasibility probe may need only a short question and a recommendation. A small change to an existing flow may need a short in-chat design. A new subsystem may justify a written specification and a detailed plan. The amount of ceremony changes with the shape of the task; the responsibility to clarify intent before implementation does not disappear merely because the task sounds easy.
Nor is Superpowers a substitute for the person directing the work. Its own instructions give explicit user instructions higher priority than the skills. Its finishing workflow leaves the decision to merge, create a pull request, or keep a branch as-is with the human partner. The system is therefore better understood as a way to organize agent initiative under human authority, not as an attempt to make the agent the final decision-maker.
A lifecycle of controlled transitions
The workflow begins before code because the first failure may be a failure of interpretation. At session start, a bootstrap supplies the agent with the rule to check for relevant process skills before responding or exploring. That rule is a control-plane decision: it changes the agent's default from “start solving” to “first decide how this request should be handled.” The repository supports several harnesses, so the shared skills describe actions—read a file, invoke a skill, dispatch a subagent—while a harness-specific layer translates those actions into real tools.
The next transition is from intention to design. Brainstorming asks what the work is for, what constraints matter, and how success will be recognized. It may present alternatives and recommend one, while removing features that are not necessary. For architectural work, the design is written and reviewed before planning. That sequence protects a distinction that is easy to lose in an agent conversation: understanding the request is not the same as being authorized to implement an interpretation of it.
After approval, the risk changes. The question is no longer only “What does the person want?” It becomes “Where can this work happen, and how will another worker know what to preserve?” Superpowers answers with an isolated workspace and a plan. Isolation protects the current branch from accidental changes and establishes a clean baseline. The plan records responsibilities, constraints, interfaces, test commands, expected results, and task-sized commits. The plan is not proof that the design is correct; it is an interface that prevents the approved design from dissolving when implementation is handed to a different context.
Implementation then enters a feedback loop. TDD requires a failing test before production code, minimal code to make it pass, and refactoring only after the behavior is green. The point of watching the failure is not ritual. It demonstrates that the test can detect the missing behavior. When reality disagrees with the test or the implementation, systematic debugging sends the agent back to reproduction, recent changes, data flow, working examples, and a single explicit hypothesis. A fix is evidence-backed only after the cause is investigated and the resulting behavior is verified.
For larger plans, Superpowers separates implementation from coordination through subagent-driven development. A fresh implementer handles a focused task; a reviewer checks both whether the requirements were met and whether the change is good code; fix rounds remain bounded; and a ledger records what happened. The controller does not paste an entire conversation into every new prompt. It hands over the task's relevant artifacts and interfaces. This is another controlled transition: context is treated as a resource to allocate, not as a history that every participant must inherit.
Evidence is the through-line
The word “evidence” can sound more formal than software work usually feels, but Superpowers uses it in a practical sense. A claim should be tied to an observation that could have contradicted it. A test should fail when a realistic production change breaks the behavior. A debugging hypothesis should be tested with the smallest useful change. A review finding should point to the code and be evaluated against the actual repository rather than accepted as a social cue. A completion claim should follow fresh command output, not memory of an earlier run.
This standard also explains why the repository is skeptical of certain shortcuts. A test that checks only that a mock exists can pass while the real component is broken. A test that compares a value with one computed by the same helper may be a tautology. A document that contains a prescribed sentence has not necessarily changed an agent's behavior. The repository therefore recommends testing boundaries and observable effects, and it applies the same logic to the skills themselves: process documents are evaluated by pressure scenarios in which agents either comply or rationalize their way around a rule.
Evidence does not remove judgment. Someone still decides whether a task is architectural, whether a dependency is truly external, whether two failures are independent enough for parallel investigation, or whether a review finding reveals a real design problem. What the methodology changes is the visibility of those decisions. Important transitions carry a test, an approval, a review verdict, a ledger entry, or a fresh verification result instead of relying only on fluent explanation.
The promise has boundaries
Superpowers can make a development process more explicit, but it cannot make weak requirements precise by itself, make an incomplete test suite complete, or guarantee that a model follows every instruction in every harness. The repository's release notes report improvements from its own evaluations, including changes in speed and token use; those results are bounded by the harnesses, models, tasks, and evaluation conditions involved. They are not universal laws of agentic development.
The workflow also has costs. Approval pauses momentum. Worktrees and plans require setup. Reviews consume time and model calls. Evidence artifacts need maintenance. Parallelism is useful only when work is genuinely independent; otherwise it can multiply conflicts. A small, disposable experiment may not justify the same process as a production change, while a supposedly small change can become dangerous precisely because its hidden scope was never examined.
The durable idea is therefore narrower and stronger than “use every Superpowers ritual.” Let the agent remain capable of acting, but make the transitions that matter observable, reversible where possible, and subject to the right authority. The next question is how the bootstrap enforces that discipline before the first line of code is written.