Superpowers: Giving Claude Code a Process

I’ve watched a coding agent read half a config file, decide it understood the schema, and start writing code against a field that didn’t exist. It wasn’t a dumb model. It was a capable one moving fast, with no habit of checking its assumption before acting on it. Same story a week later with a bug fix. The agent patched the symptom, the test went green, and it moved on without ever asking why the bug happened in the first place. The gap in both cases wasn’t capability. It was process. The model had never been given one.

Superpowers, a plugin for Claude Code written by Jesse Vincent (“obra”), is an attempt to close that gap. It installs a library of “skills,” which are process playbooks the agent can invoke mid-task, plus a meta-skill called using-superpowers that’s supposed to make the agent stop and reach for a relevant skill before it acts, instead of improvising. Brainstorming before code. Tests before implementation. A root cause before a fix. A written plan before a multi-step job. None of this is a new idea in software engineering. The interesting question is whether wrapping it in a skill library changes what an LLM agent does, or just gives it more text to skim past.

What matters here

For a process-skill plugin, four things decide whether it’s worth installing:

1. Does it change behavior, or get ignored? A skill that lives in a folder and never gets invoked is dead weight.
2. Does output quality go up? Less rework, fewer round trips where you catch the agent’s mistake after the fact.
3. Friction versus payoff. Every gate costs time. It has to buy back more than it costs.
4. Everyday-task fit versus big-feature fit. A process built for a multi-day feature can be miserable for a one-line fix.

I ran Superpowers against three kinds of work over several weeks, quick fixes, a debugging session that looked simple and wasn’t, and a multi-step job that needed to run unattended. Here’s where it held up and where it didn’t.

Three places it earns its keep

The brainstorming gate. Before the agent writes any code, the brainstorming skill forces a design conversation, one question at a time, no jumping ahead, no code until you’ve approved a direction. This post is a case in point. Before I wrote a word of it, Claude Code walked me through the structure, the three spotlights, the caveats, one decision at a time, and didn’t touch a file until the shape was settled. That’s the opposite of the failure mode I opened with, where the agent decided it understood the requirement and started typing. The gate makes “I think I understand” into a checkpoint instead of an assumption.

TDD plus systematic debugging. The test-driven-development skill insists on a failing test before any implementation. The systematic-debugging skill goes further. No fix ships without an identified root cause. I watched this pair catch a real band-aid. The agent had a failing integration test, found a quick patch that made the test pass, and the debugging skill’s process stopped it there, asking what caused the failure before touching the fix. The root cause turned out to be a race condition three layers away from where the test failed. The quick patch would have masked it, not fixed it. The agent had every tool it needed to take the shortcut, and the skill made it justify not taking it.

Plans, worktrees, and subagents. For a multi-step job, writing-plans produces a written plan up front, using-git-worktrees isolates the work in its own worktree so it can’t collide with what’s on your main branch, and subagent-driven-development and dispatching-parallel-agents fan the independent steps out to parallel subagents instead of running everything serially in one context. I ran a job structured exactly that way, a plan file, a dedicated worktree, and three subtasks farmed out to run concurrently. It behaved like a small engineering team working from a spec, not one agent context accumulating scroll-back until it lost track of its own state, which is what usually caps how far a single long-running session can get.

Where it gets in the way

None of this is free. The brainstorming gate on a one-line typo fix is pure ceremony, a design conversation for a change that has no design decision in it. The gating only works if the model honors the meta-skill and reaches for the relevant playbook, and I saw sessions where it didn’t, where the agent skipped straight to code and the skill sat unused in its own directory. And the plugin has a real onboarding cost. The first few tasks feel slower, not faster, because you’re paying for the gate before you’ve built up the muscle memory of skipping it on the tasks that don’t need it.

Verdict

Recommend, with caveats. Reach for Superpowers when the task has real design surface, a bug that resists a quick fix, or enough steps that a written plan will save you from your own agent’s amnesia. Skip the ceremony on anything you could describe correctly in one sentence and verify in ten seconds. That split is the whole review. The plugin doesn’t make Claude Code smarter. It makes it stop and check its assumptions before it acts on them, which is a different and, for most real work, more valuable thing.