Reviewing Superpowers: A TDD Framework That Literally Deletes Code Written Before Tests Exist

How does the "delete non-compliant code" rule actually work — is there a risk of accidentally deleting code that's already written well but just hasn't gotten its test yet?

The rule triggers on "implementation code exists before its corresponding test" — meaning it targets the development sequence itself, not a judgment of code quality after the fact. In practice, this means the workflow Superpowers expects is that every piece of implementation starts with a failing test already in place, and only then is code written to make it pass. If your habit is writing a large chunk of functionality first and coming back to add tests afterward, this rule directly conflicts with that habit, because "the functionality written first" already violates the sequence the rule defines, before the test ever gets added.

This is indeed a relatively aggressive design choice. The upside is that it thoroughly prevents the common TDD failure mode of "tests bolted on afterward, more form than substance"; the cost is that it requires the user (or team) to genuinely commit to working in the red-green-refactor sequence, not just treating TDD as a slogan. If your team doesn't already have the habit of writing code strictly in this order, adopting this rule directly will involve a noticeable adjustment cost upfront.

How is Subagent-driven development substantively different from ordinary multi-person collaborative development, and why does keeping context clean need special emphasis?

Ordinary multi-person collaboration splits different tasks among different people, each maintaining their own mental model of the project. Subagent-driven development looks similar on the surface, but the difference lies in the fact that context itself is a limited resource that gets progressively consumed — the more information, and the more varied that information, Claude has to handle in a single conversation, the more the space available for making correct judgments gets squeezed. If database migrations, frontend styling, and API routing — entirely unrelated work — all get crammed into the same Context Window, even if each task individually isn't hard, mixing them together means leftover detail from the prior task still occupies space and interferes with focus on the current one.

Subagent-driven development solves exactly this: each engineering task gets handed to a separate, clean, independent subagent that carries only the information necessary to complete that specific task, reporting only the result back to the main thread once done, rather than leaving every intermediate detail generated along the way sitting in the main conversation. This differs from simply dividing labor — division of labor only solves "who does what"; subagent-driven development also solves "how to make sure that whoever (or whichever subagent) is doing the work isn't having their judgment interfered with by irrelevant noise."

Cross-tool portability sounds appealing, but if some team members use Claude Code and others use different tools, will there be a real gap in how they collaborate?

Yes, there will be, and the official documentation itself acknowledges this — while the core workflow (brainstorming, TDD enforcement, the basic Skill set) runs on every supported platform, Claude Code has platform-specific features like sandboxed tool-use scope, automatic Plugin updates, and native Subagent support, meaning some advanced features (particularly subagent-driven development) won't necessarily perform equally well on other platforms. Other tools get the core workflow, but not the most advanced orchestration mechanism.

For a team with a mixed toolset, a more realistic expectation is that everyone benefits from the methodology-level consistency — enforced TDD discipline, brainstorming to clarify requirements upfront — but if some members' work heavily relies on advanced features like subagents processing complex tasks in parallel, people on a non-Claude-Code platform will have a real gap in that particular experience compared to people using Claude Code. If your team decides to adopt Superpowers, it's worth first confirming whether the core collaboration scenario mainly sits at the "consistent methodology" level, rather than depending on everyone getting an identical advanced-feature experience.

If I'm an individual developer rather than working on a team, does this framework's enforcement help me or burden me?

It depends on how large the gap is between your current coding habits and the discipline Superpowers expects. If you already have a habit of writing tests, just without this strict a process, adopting Superpowers is more about formalizing an existing habit, and the friction will be relatively low. But if you tend to write out functionality quickly with tests bolted on afterward or often skipped entirely, directly applying this framework will feel like being blocked by rules at every turn early on — tasks you could previously finish quickly now have to go through brainstorming, writing a plan, and the red-green cycle before you can actually start.

A more practical way to judge this is thinking through the nature of the project you're currently working on. For a project that needs long-term maintenance, might be handed off to someone else later, or has inherently complex, error-prone logic, the extra discipline cost upfront usually pays for itself in reduced debugging and rework time down the line — the official documentation itself notes that while brainstorming and planning add roughly 10 to 20 minutes of overhead upfront, fewer errors and less rework during implementation across the whole project can actually make development 2 to 3 times faster than a traditional approach. But if you just want to quickly validate an idea with a short project lifespan, this framework's enforcement might well be unnecessary friction, and plain Claude Code with no extra rules is a better fit.