Why Superpowers Treats TDD, Debugging, and Verification as Strict Rules

Superpowers is defined not by whether you can code, but by whether you can follow strict rules; its core philosophy is to replace "feeling it works" with concrete evidence.

Three Hard Constraints

The framework emphasizes three skills that together form an evidence chain:

test-driven-development

systematic-debugging

verification-before-completion

Each skill looks simple in isolation, but together they enforce the principle: do not trust intuition, trust evidence left by the process.

Why TDD Becomes a Rigid Rule

Superpowers does not view TDD as a gentle recommendation; it mandates that no production code may be written without a failing test. If code is written first, the rule forces you to delete the implementation and start over. This eliminates common shortcuts such as "write first, test later" or "just add a test after the fact". The rule is designed to prevent agents from retro‑fitting tests that merely appear to validate the change.

No failing test, no production code.

When an implementation already exists, the prescribed action is delete and redo , ensuring the test truly drives the design.

Systematic Debugging: Fighting Guesswork

Where TDD blocks premature implementation, systematic debugging blocks premature fixes. The core principle is: do not propose a fix before completing a root‑cause investigation. The process is split into four stages:

Root‑cause investigation

Pattern analysis

Hypothesis & verification

Implement the fix

Key practices include reading error messages carefully, ensuring the problem can be reliably reproduced, reviewing recent changes, adding diagnostic information in layered systems, performing backward tracing for deep issues, and validating only one hypothesis at a time. This prevents the common "try‑a‑change‑see‑if‑it‑works" loop that AI agents often default to.

Before any fix, a root‑cause investigation must be completed.

Verification‑Before‑Completion: Closing the Loop

The final skill guarantees that a task is not declared finished without fresh verification evidence. The rule states: without new verification results, you cannot claim completion, pass, or successful fix. The steps are:

Decide which command will prove the task is done.

Run that command.

Inspect the full output.

Only then decide whether the work can be marked as complete.

This prevents agents from treating a successful build or a passing test that existed before the change as proof of correctness.

Combined Effect: An Evidence‑Driven Rhythm

When the three skills are applied together, they create a stable engineering cadence:

Start with a failing test to prove the requirement.

Perform root‑cause investigation to prove understanding.

Finish with fresh verification to prove the result.

The result is a workflow that forces agents to stop relying on subjective feelings and to let external evidence drive every decision.

Common Misconceptions

These rules are not separate, isolated guidelines; they form a single evidence chain. They are not only for large projects—Superpowers applies them to tiny bugs, single‑function changes, and simple tasks because shortcuts are often most dangerous in seemingly trivial work. While the process may feel slower in the short term, it reduces costly rework, hidden bugs, and false claims of completion.

What Comes Next

The next article will extend the discipline to the final mile of delivery, covering review, isolated worktrees, and branch finalisation, showing why Superpowers insists on formalising those steps as well.