Red–Green–Refactor with Superpowers

What it does

Superpowers’ TDD skill makes the observed failure central: a test that passes before the feature exists has not demonstrated that it detects the missing behavior. The workflow separates a meaningful assertion failure from a broken test harness, then asks for only enough production code to make that case pass. A companion guide discusses honest assertions, mock boundaries and dependency side effects. Compared with a general testing checklist, this skill prescribes the order in which implementation happens.

When to use it

• Reproduce a bug before correcting it so the failure remains guarded.
• Implement a new validation rule with explicit accepted and rejected inputs.
• Refactor a behavior behind an existing public interface while preserving its contract.

Step-by-step workflow

1. Choose one observable behavior and a specific expected result from the requirement.
2. Write the smallest meaningful test and run it; confirm failure comes from missing behavior rather than a setup error.
3. Implement the minimum change required to satisfy that test, without speculative options or abstractions.
4. Run the targeted check and the project suite; investigate failures before calling the change complete.
5. Refactor only while the suite stays green, then repeat for the next behavior and retain the regression evidence.

Example request

Use test-driven-development for our retry helper. The policy allows three total attempts, returns the first successful result and rethrows the final error if every attempt fails. Start with one behavior and show the expected failure before implementation. Use deterministic operations without network calls or real delays. Keep the API minimal, then test the exhausted-attempt case and run the existing project suite.

Worked example

An operation that fails twice and returns “saved” on its third call provides a deterministic retry example. Assert the returned value and three attempts. A test that merely makes a mock return “saved” can test the mock configuration instead of the helper. The exhausted case should check that no fourth call occurs and the intended error escapes. Refactoring the loop is safe only if those observable outcomes remain unchanged after a new suite run.

What you get

Behavioral regression tests, minimal production changes and an observed red/green history for the selected cases.

How to evaluate the result

• The test failed for the intended missing behavior before the implementation changed.
• Expected values come from the requirement, not a copy of the production algorithm.
• Both targeted cases and the project suite passed on the final tree.

What you need

A test runner already suited to the project, a clear behavior contract and deterministic test inputs. External systems need an intentional boundary rather than indiscriminate mocking.

Setup and activation

The publisher documents separate installation routes for Claude Code, Codex App and CLI, Cursor and other harnesses. Use the README for your exact client; installing the whole Superpowers framework can activate additional workflows automatically. Preserve this skill’s companion files and relative references. Review and security-scan the exact selected version before installation. This directory only reviews sources; it has not installed, executed or tested this skill on those clients. Keep writing-good-tests.md with the skill; it contains important detail beyond the short red/green loop.

Limits and considerations

The upstream policy is deliberately strict and asks for agreement on exceptions such as throwaway prototypes. It cannot make an incorrect expected value correct. Passing tests cover the asserted behavior, not every integration or production condition. The workflow may require restarting prematurely written code; applying that policy must respect repository ownership and preserve unrelated user work.

Related workflows

• Use systematic-debugging to find a cause before selecting a regression case.
• Use requesting-code-review to assess blind spots the tests may not cover.

License and reuse

MIT, copyright 2025 Jesse Vincent. Preserve the copyright and permission notice when redistributing substantial source portions; inspect separately supplied dependencies and assets under their own terms.

Further reading

• Reviewed skill version (immutable commit)
• Publisher setup, compatibility and telemetry notes
• Reviewed MIT license