The most dangerous moment in AI-assisted development is often not when the model cannot write code. It is when the model writes quickly in the wrong direction.
A vague request such as "support bulk processing" can describe several different products. Without clarification, an agent may modify the database, API, and interface in minutes, then produce internally consistent tests for an implementation nobody requested. Faster output makes a mistaken decision spread faster.
obra/superpowers is designed around that failure mode. It is not primarily a collection of new tool integrations. It is a software development methodology expressed as composable skills: establish a design before implementation, turn the design into an inspectable plan, and require fresh evidence before declaring completion.
The workflow changes the order of decisions
The project's current public workflow includes:
- brainstorming to clarify goals, constraints, and alternatives;
- using-git-worktrees to isolate work and verify a baseline;
- writing-plans to create small tasks with paths and checks;
- subagent-driven-development or executing-plans for implementation;
- test-driven-development using RED-GREEN-REFACTOR;
- requesting-code-review against the specification and code quality;
- finishing-a-development-branch with final verification and integration choices.
None of these practices is novel in isolation. The strong opinion is that they are mandatory operating rules for the agent rather than advice in a team handbook.
Design prevents the wrong problem from entering code
An experienced engineer responds to ambiguity with questions: who uses this, what happens on failure, which existing behavior should be preserved, and what is explicitly out of scope?
Language models tend to complete missing details. That is useful for drafting and risky for production changes. The brainstorming skill puts clarification and alternative comparison before code and asks for an approved design.
This creates more conversation at the beginning. It can also move mistakes to the cheapest place to fix them. Changing a design paragraph is inexpensive; recovering data after a mistaken migration is not.
A plan exposes unresolved ambiguity
"Implement authentication" is not a plan. A plan identifies files, the first failing check, the expected failure, the smallest implementation step, and the command that proves the change works.
Superpowers favors small tasks with explicit paths and verification. The benefit is not mechanical obedience. Writing a concrete step forces the design to answer interface boundaries and completion criteria. If a step cannot be stated clearly, the work probably is not ready to execute.
The plan also gives review a reference. A reviewer can compare behavior with the agreed design rather than judging only whether the code looks polished.
Why TDD is unusually constraining for an agent
A model can generate plausible implementation code and then write a test that conveniently proves its own behavior. Seeing the test fail first establishes that it covers behavior not already present.
textwrite failing test -> confirm the failure reason -> minimal implementation -> confirm the pass -> refactor
This loop cannot prove that the requirement itself is correct, and it does not replace integration or visual tests. It does reduce the room for implementation and tests to become a self-confirming pair.
Fresh verification is the trust mechanism
Coding agents often use "should work" or "looks correct" as completion signals. Superpowers defines verification-before-completion as a separate discipline: claims must be supported by tests, builds, or checks run after the relevant change.
The rule is simple and central to trustworthy collaboration. "I am done" becomes "these commands just passed, so I have evidence that the requested behavior is complete."
The process has a real cost
Superpowers is not the optimal default for every task.
A one-off script, exploratory prototype, or two-line configuration fix may not justify a design document, worktree, TDD loop, and independent review. Visual exploration also cannot reduce every valuable outcome to a unit test written first.
The deeper risk is ritual. An agent can produce an impressive plan, add low-value tests, and check every box. If a team inspects only process compliance rather than design judgment and test quality, the methodology becomes another performance.
Process intensity should scale with blast radius and uncertainty, not with the name of the framework.
The three rules I would adopt first
A team does not need the entire workflow on day one. Start with three constraints that change outcomes:
- Before implementation, state the goal, non-goals, and observable acceptance behavior.
- Before changing shared logic, establish a check that can fail.
- Before claiming completion, rerun checks proportional to the change.
Add isolated worktrees, independent review, subagents, and finer planning as risk grows. The team then gains engineering discipline without becoming dependent on a specific skill vocabulary.
My view
Superpowers does not make a model smarter. It makes the pauses used by strong engineers explicit: when not to code yet, when evidence is required, and when a second perspective should challenge the work.
AI coding is moving from "who generates more code on the first pass" toward "who delivers the correct change with less rework." In that contest, speed is not uniformly good. The system should be fast at execution and deliberate around irreversible decisions.