Superpowers' Promise—and Its Boundaries
This final examination of obra/superpowers returns to the question that gives the methodology its shape: how can a coding agent remain autonomous without being allowed to turn fluency into unreviewed authority? The answer is a chain of evidence and permissions. Superpowers changes what happens before coding, where coding happens, how behavior is tested, how failures are investigated, how work is delegated, and what “complete” is allowed to mean. The useful judgment is not whether every team should adopt every step. It is whether the workflow places the right boundary around the risk of the task.
A governed form of autonomy
Superpowers does not make the agent passive. A passive agent waits for a human to specify every detail, chooses no approach, and contributes little judgment. Superpowers asks for the opposite: the agent should inspect context, recognize which process applies, ask questions, propose an approach, decompose work, write tests, investigate failures, select an appropriate delegation pattern, and explain trade-offs. What changes is the status of those actions. They are not all equally authorized, and they are not all accepted as evidence merely because the agent performed them confidently.
The workflow can be understood as a sequence of ownership transitions.
At session start, the bootstrap owns attention. It places process guidance in front of the agent before the first consequential request is handled. This is where the system counters the tendency to act on a familiar pattern immediately. The agent still decides which relevant process applies, but it is expected to make that choice before exploring or implementing.
During brainstorming, the human partner owns intent approval. The agent classifies the request, asks what matters, presents alternatives, and surfaces hidden scope. The person directing the work decides whether the resulting interpretation is the one to implement. A short design is enough for a bounded change; architectural work may need a written specification. The artifact scales, while the approval boundary remains.
After approval, the workspace and plan own execution conditions. The worktree separates implementation state from the current branch, subject to consent and repository safeguards. The plan carries the design into responsibilities, interfaces, constraints, and tests that another context can follow. These mechanisms make the work safer to start, but they do not claim that the design is correct.
During implementation, tests and debugging own behavioral evidence. A failing test shows that the test can detect a missing behavior. A passing test shows that one observed contract now holds. A root-cause investigation explains a particular failure and tests a particular hypothesis. None of these becomes a license to generalize beyond what it actually observes.
During delegated execution, the controller, implementer, and reviewer own different parts of coordination and scrutiny. A fresh implementer receives a bounded task. A reviewer checks specification compliance and code quality. A ledger preserves decisions and progress. The controller decides how to route questions, findings, and residual risks. The agent remains active at each stage, but no single fluent response is allowed to stand in for the entire chain.
At the end, fresh verification and branch finishing own claim calibration and integration authority. The agent runs the command that supports the claim it is about to make. The person directing the work chooses whether to merge, create a pull request, or keep the branch. Autonomy reaches the end of the process without silently becoming the right to publish or destroy work.
This is the central synthesis: Superpowers does not reduce autonomy by removing decisions. It governs autonomy by assigning each decision an owner, a boundary, and—where possible—an observation that could contradict it.
Completion is a claim with a boundary
The phrase “the work is done” compresses several different claims. A focused test may show that one behavior passes. A full suite may show that the current tree has no detected regressions under that suite. A review may show that a diff appears to satisfy its task and meet quality expectations. A clean branch may show that the change is ready for a human integration choice. These are related forms of evidence, not interchangeable certificates.
Superpowers' verification rule makes that distinction explicit.