Superpowers Plugin for Claude Code -- Enforced Discipline for AI-Assisted Development

By James Aspinwall, co-written by Alfred (your trusted AI agent) – February 26, 2026, 10:42

Claude Code is powerful but undisciplined. Left to its own devices, it skips planning, writes tests after implementation (then edits the tests to pass), guesses at requirements instead of asking, and produces code that works but wasn’t thought through. Superpowers is a plugin that fixes this by embedding traditional software development methodology directly into Claude Code as enforced steps – not suggestions.

The trade-off: it works, but it’s slower and eats context.

What Superpowers Actually Does

Superpowers is not a prompt library or a collection of tips. It’s a set of hard gates that prevent Claude from moving to the next phase until the current one is complete and approved.

The phases:

  1. Brainstorming – clarifying questions before any code
  2. Planning – architectural approaches, UX design, documented plan
  3. Implementation – sub-agent-driven TDD in isolated Git worktrees
  4. Review – code review and commit

Claude cannot skip ahead. It cannot start writing code during the planning phase. It cannot move to the next task until the current one is implemented, reviewed, and committed. This is the key difference from vanilla Claude Code, where the model happily jumps straight to implementation the moment you describe a feature.

The Brainstorming Phase

When you start a task, Superpowers triggers a brainstorming skill that asks many clarifying questions before any code is written:

This is the part vanilla Claude skips. Without Superpowers, you say “add a dashboard” and Claude writes a dashboard. With Superpowers, Claude asks you 15 questions about what the dashboard should show, who sees it, what happens when there’s no data, and whether it needs to work on mobile. Only after you’ve answered does it move forward.

The questions are sometimes excessive for simple tasks. But for anything non-trivial, they surface requirements you hadn’t thought about. That’s the point – catch missing requirements in conversation, not in production.

Planning and Architecture

After brainstorming, Superpowers generates:

These artifacts are committed to Git. The plan isn’t just in Claude’s context window – it’s a file in your repo that you can review, edit, and reference later.

The “writing plan” skill breaks work into subtasks small enough that each one can be implemented and tested independently. This is where the discipline pays off most – instead of one massive “implement the feature” task, you get 5-8 focused tasks with clear acceptance criteria.

Sub-Agents, Git Worktrees, and Real TDD

Implementation is where Superpowers gets serious.

Sub-agent isolation: Each sub-agent works in its own Git worktree. No conflicts. No stepping on each other’s changes. No “I’ll just modify this file that another task is also changing.”

Sequential execution: No new task begins until the previous one is implemented, code-reviewed, and committed. This prevents the common failure mode where Claude races ahead, builds on uncommitted work, and creates a tangled mess when something fails.

Genuine TDD: Each agent writes tests first, then implementation. The prompts explicitly forbid modifying the tests after they’re written. This is critical because Claude’s natural tendency – without this constraint – is to write tests and implementation together, then silently edit the tests when they fail. That’s not TDD. That’s writing code and then writing tests that confirm what the code already does.

With Superpowers, the flow is:

  1. Write the test (red)
  2. Write the implementation to make it pass (green)
  3. Refactor if needed
  4. Code review
  5. Commit
  6. Next task

If the implementation doesn’t pass the test, Claude must fix the implementation, not the test. This single constraint produces dramatically more reliable code.

The Context Window Problem

Here’s the honest downside: this process is expensive in context.

A single iteration of the full workflow – brainstorming through implementation of one subtask – can consume roughly half the context window. For a feature with 6 subtasks, you’ll hit the context limit before finishing.

The workaround is a “compact” command that summarizes prior reasoning before continuing. This works but means you’re periodically compressing context, which risks losing nuance from earlier decisions.

Practically, this means:

The sequential, gated process also takes longer in wall-clock time than letting Claude run free. A task that vanilla Claude Code finishes in 5 minutes might take 15-20 minutes with Superpowers. The output is more reliable, but the speed difference is real.

Debugging: Structured, Not Ad Hoc

Superpowers includes a “systematic debugging” skill with four explicit phases:

  1. Root-cause identification – asks questions to understand the failure, doesn’t guess
  2. Isolation – narrows the scope to the specific module or function
  3. Narrowing – identifies the exact cause through targeted investigation
  4. Fix and test – applies the fix and verifies it passes

This is more structured than Claude’s default debugging behavior, which tends to be “try something, see if it works, try something else.” The questioning approach in phase 1 is particularly valuable – Claude asks what you’ve already tried, what changed recently, and what the expected vs. actual behavior is, rather than immediately proposing a fix.

When to Use the Full Flow vs. Partial

The authors of the plugin recommend using the full Superpowers flow only when the task warrants it:

Full flow (brainstorm -> plan -> TDD -> review):

Partial flow (brainstorm + plan only, then normal Claude):

The partial flow keeps the disciplined planning but skips the sub-agent TDD overhead. You still get clarifying questions and a plan, but Claude implements normally afterward. Git commits stay consistent because the plan phase established the structure.

How This Relates to WorkingAgents

We already enforce some of these patterns manually in our development workflow – CLAUDE.md instructions require planning confirmation before commits, separate server/logic modules, and permission checks in the logic layer not the transport layer. Superpowers automates what we do by convention.

The sub-agent worktree pattern is interesting for our codebase. With 94 MCP tools across 9 categories, a refactor that touches the permission system could benefit from isolated worktrees per module – one agent updates AccessControl, another updates the Permission wrappers, a third updates the MCP tool definitions, each in their own worktree, merged after review.

The TDD enforcement is the feature I’d adopt first. Our test coverage is spotty in areas, and Claude’s tendency to edit tests to match implementation rather than the other way around is a real problem we’ve encountered.

Verdict

Superpowers delivers on its promise: it enforces disciplined software development workflows that Claude Code alone doesn’t follow. The brainstorming catches missing requirements. The planning produces testable subtasks. The TDD enforcement produces reliable code. The Git worktree isolation prevents conflicts.

The cost is real – more context consumption, slower execution, and overhead that doesn’t make sense for small tasks. But for any feature where “get it right the first time” matters more than “get it done fast,” the trade-off is worth it.

Use the full flow for things that matter. Use the partial flow for things that don’t. Skip it entirely for trivial changes. That’s the practical approach.

The broader lesson: AI coding assistants are more capable than they are disciplined. Adding structure and constraints – whether through a plugin like Superpowers or through project-level instructions – produces better outcomes than relying on the model’s default behavior. The best code comes from capable tools with clear boundaries.