If you've spent any time working with coding agents, you've probably noticed that they have this deeply ingrained instinct to just start writing code the moment you give them anything resembling a task. They don't want to brainstorm. They don't want to write a spec. They especially don't want to write tests first. They want to skip to the part where they're generating files and then ask you to check whether any of it was right, which, if you think about it, is sort of the worst possible workflow for producing reliable software.
Superpowers is a framework by Jesse Vincent that refuses to let this happen. It's a set of composable Claude Code skills that impose a very deliberate sequence on your agent: brainstorm first, then write a spec, then create a detailed plan, then execute, then review. And the skills aren't optional in the way that, say, a linter rule you can slap a // eslint-disable on is optional. They activate automatically based on what you're doing. The agent literally cannot skip ahead.
I've been using it for a few weeks now and the planning phase alone has been worth the whole setup. But I kept running into the same friction during execution, so I wrote a skill to get rid of it.
What Superpowers gets right
The core idea is that agents produce dramatically better work when you force them to think before they code, which sounds obvious when you say it out loud but almost no one actually enforces it. Superpowers does.
The brainstorming phase makes the agent stop and genuinely ask you what you're trying to build, rather than pattern-matching on your prompt and charging off in whatever direction seems most likely. Then it writes a design spec. Then it creates an implementation plan that breaks the work into tiny tasks, each around 2-5 minutes, and each one includes the exact file paths to modify, code snippets, what the tests should look like, and what the commit message should say. The level of detail is almost comical until you realize that's exactly the point.
The Superpowers docs describe the intended audience for these plans as "an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing," which made me laugh when I first read it, but the more I think about it the more I think it's exactly the right bar to set. If the plan is clear enough for that person to execute correctly, it's clear enough for an agent running without supervision. And if it's not clear enough for that person, you're going to have a bad time no matter what.
The other thing Superpowers does that I haven't seen anywhere else is enforce TDD as a hard constraint, not a suggestion you can ignore when you're in a hurry. The agent has to write a failing test, verify that it actually fails, implement the minimum code to make it pass, verify that it passes, and then commit. If code appears before a test exists, the framework tells the agent to delete what it wrote and start over. That sounds harsh but it means you end up with a test suite that actually reflects what the code is supposed to do, rather than tests that were written after the fact to make CI green.
Most agentic setups I've tried tend to fall into one of two failure modes: they're either way too loose, where you're basically just prompting and hoping for the best, or they're way too rigid, like some kind of YAML pipeline that works beautifully for the exact scenario it was designed for and falls apart the moment anything is slightly different. Superpowers manages to land in this spot where the structure is real and enforced but flexible enough that it doesn't get in the way of actually building things. Which is hard to do, and I think Jesse nailed it.
The gap I kept hitting
So here's where my addition comes in. By default, Superpowers expects you to be present for the whole process. The agent pauses at key transitions to get your approval: signing off on the spec, reviewing the plan before execution starts, watching the tasks get implemented one by one. And that's the right default. When requirements are fuzzy or the design space is open, you absolutely want to be in the loop making judgment calls.
But once the plan was finalized and I'd already made all the decisions? Every file path, every test, every commit message was already written out in the plan document. And I'd find myself just sitting there, approving step after step, watching the agent do exactly what the document said it was going to do. It felt a lot like being asked to hold a stopwatch for an athlete who's running a route they've already memorized. You're technically present but you're not actually contributing anything.
I kept thinking, why am I sitting here? The plan has everything the agent needs. The tests will catch regressions. Each task gets its own commit so I can roll back if something goes wrong. All the safety mechanisms are already in place. The only thing missing is permission to keep going without stopping to ask me if it's okay after every step.
What I added
So I wrote a skill that wraps Superpowers' existing executing-plans and subagent-driven-development skills and strips out the human checkpoints between tasks. The agent picks up a finalized plan and just runs through it: read the task, implement it, run the tests, commit, check off the box, move to the next one. No pausing, no "does this look right?", no waiting for me to type "yes" for the fourteenth time.
I want to be clear that this isn't a replacement for the normal Superpowers workflow. It's an optional mode you reach for when the planning is done and you trust what's in the document. The default with human checkpoints is still better for most situations.
The thing that made this surprisingly easy to build is that Superpowers already had all the infrastructure I needed. The plan format is detailed enough that each task is totally self-contained with unambiguous success criteria. The TDD enforcement means there's a real verification gate at every step even when nobody's watching. And the one-commit-per-task convention means rolling back is trivial. I didn't have to build any of that machinery. I just took the pause button out.
What changed
The biggest surprise, and I really didn't see this coming, is that it made me a noticeably better planner. When you know the plan is going to be executed literally and the agent is not going to stop and ask for clarification, you start catching ambiguities that you'd normally wave away. You find yourself writing things like "create a new file at this exact path with this exact function signature" instead of "add a handler for this," because you know the agent will interpret vagueness in whatever way is most convenient rather than most correct. The autonomous constraint pushed my planning quality up, which in turn made the autonomous execution more reliable, which is a nice little flywheel.
The mechanical stuff got faster too, which I guess is the obvious benefit, but honestly the speed isn't really the interesting part. What surprised me more is how much less context-switching I do now. Before this, I'd sit there half-watching the agent work, not really paying full attention but also not really able to focus on anything else because I knew an approval prompt was coming in thirty seconds. Now I kick off a plan and go do something else entirely. Come back to clean commits and green tests. That's a qualitatively different experience from sitting in the loop, even if the wall-clock time is similar.
Debugging is less painful too, because every task has its own commit. When something breaks, you don't have to figure out which of seventeen changes in a giant diff caused the problem. git log just points you right at it.
When to stay in the loop
I should say that I don't use this for everything, and I don't think you should either. Exploratory work, fuzzy requirements, anything where you might want to change your mind halfway through and take the whole thing in a different direction. For all of that, the default Superpowers workflow with human checkpoints is clearly better.
The heuristic I've landed on is pretty simple: if I'm writing the plan and I keep hedging with "maybe" or "it depends" or "we'll figure this out during implementation," the work isn't ready for autonomous execution yet. I need to go think more. But when the plan is tight and specific and I can read through every task and say "yeah, that's exactly what I want," then I hand it off and go do something else.