Superpowers · Jesse Vincent (Prime Radiant) · as of September 30, 2026
Superpowers answers your agent’s excuses before it makes them
Its makers tested the rules agents most want to skip by putting agents under pressure and writing down, word for word, how they talked their way out. That is how Superpowers means to keep an agent testing first, hours into a build you aren’t watching.
This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.
Two philosophies at a glance
Superpowers
Evidence over claims: settle the design with your human partner, then build it test-first, with a fresh reviewer and rulings, not stalls.
The Enso Method
Define the whole body of work first, prove each requirement against real systems, and keep the requirements true for the life of the system.
Where they differ
- Tests optional, or after the code Test-first, enforced Superpowers sits at the “Test-first, enforced” end; the Enso Method sits toward “Tests optional, or after the code”.
- The developer at the keyboard decides Someone who isn’t at the keyboard decides Superpowers sits at the “The developer at the keyboard decides” end; the Enso Method sits at the “Someone who isn’t at the keyboard decides” end.
- One change at a time The whole body of work up front Superpowers sits toward “One change at a time”; the Enso Method sits at the “The whole body of work up front” end.
- Specs serve one change Specs live as long as the system Superpowers sits at the “Specs serve one change” end; the Enso Method sits at the “Specs live as long as the system” end.
What they share
- Starts from a prompt Intent written down first Superpowers sits at the “Intent written down first” end; the Enso Method sits at the “Intent written down first” end.
- Stops and asks Decides, records it, keeps going Superpowers sits toward “Decides, records it, keeps going”; the Enso Method sits at the “Decides, records it, keeps going” end.
Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.
Nothing counts until you’ve watched it fail
“If you didn’t watch the test fail, you don’t know if it tests the right thing.” That’s the core of Superpowers’ test-driven development (TDD) skill, and its skill-writing guide turns it on its own rules: “If you didn’t watch an agent fail without the skill, you don’t know if the skill teaches the right thing.”
So each rule an agent is tempted to skip, like test-first, is tried on agents under combined pressure (a production outage, dinner at 6:30), and every excuse the agent gives goes into the skill with an answer: “Too simple to test” meets “Simple code breaks. Test takes 30 seconds.” The README sums up the stance: “Evidence over claims.”
Up to three sign-offs, then hours on its own
- Brainstorm. The agent sorts the request into a spike, a bounded change or architectural work, and asks one question at a time. A spike needs a nod and a bounded change a short design; architectural work needs your approval of the design, then of a written spec.
- Plan. Architectural work becomes tasks for “an engineer who has not seen this codebase”: files, signatures, the failing test, the command that proves it. You approve it and pick how it runs.
- Build. A fresh builder and reviewer per task, or, in Native mode, one session and one final review. No check-ins; a conflict gets a written ruling with “what it costs if wrong.”
- Finish. With the suite green, you merge, open a pull request or keep the branch.
The README: “It’s not uncommon for your agent to work autonomously for a couple hours at a time without deviating from the plan you put together.”
Built for the developer who owns the design
Superpowers fits a developer who decides what gets built, settles the design in one sitting, then steps away; it suits work where a shipped bug costs more than a slow build.
Its makers name the price: users’ most common lament is that “tokens are expensive and Superpowers uses a ton of them,” and builds are slower. That buys up-front planning, strict TDD and per-task review, and they keep cutting it: version 6 cut token use by almost half, and Native mode, reviewing once at the end, halves the cost again on a frontier model. Setup is one plugin install.
It suits you less if you want to steer each step, or need a structured way to iterate once a plan has run, a gap the project says it wants to close.
Where the Enso Method made a different call
Both write the intent down before code, and neither stalls on a question the agent can answer.
What a test has to prove
Superpowers
Each test is written first and seen failing before its code exists.
The Enso Method
Tests follow the code; a later pass checks that every acceptance criterion has evidence and replaces mocked integrations with real sandbox systems.
Choose by situation: worried about tests that could never fail? Superpowers guards against them. Worried about integrations only ever tested against a stand-in? The Enso Method does.
Who settles the design
Superpowers
You do. You pick from two or three approaches and approve the design, and for bigger work the spec and plan.
The Enso Method
The agent researches and makes the technical calls itself, rather than handing you “Option A or B?”. Business questions become proposals for their owners, and the build continues.
Choose by situation: to keep the design in your hands, Superpowers; to hand off the technical calls while someone else owns the business ones, the Enso Method.
How much it plans up front
Superpowers
One piece of work at a time. Architectural work gets its own dated spec and plan; smaller changes are agreed in chat.
The Enso Method
The whole body of work is defined first and built in session-sized phases, and its requirements are amended before any change to what the system does.
Choose by situation: for self-contained changes, Superpowers stays light; for a system others will maintain for years, the Enso Method’s upkeep leaves them a current description of it.
Where Superpowers shines
- Tests that can catch bugs. Each test is seen failing before its code exists, and a bug fix’s test is checked by undoing the fix.
- A fresh reviewer on every task in subagent-driven mode, told to treat the builder’s report as “unverified claims.”
- Debugging with a brake. Root cause before any fix; after three failed fixes, it stops to question the architecture with you. The Enso Method has no debugging procedure.
- Tested rules, 15 agents. Skill changes must show eval results, and it installs into 15 coding agents. The Enso Method has no skill tests and supports Claude Code and Codex.
How the Enso Method differs, and why
Superpowers settles the design with you, then builds it strictly test-first: every test is seen failing before its code exists. The Enso Method writes tests after the code and proves each requirement against real systems wherever they exist; it also defines the whole body of work up front and keeps those requirements current, so every later change starts from what was decided.
Get started
Superpowers is free and open source (MIT) and installs into 15 coding agents; each one’s install steps are in the README at github.com/obra/superpowers.