Test-driven development is not a final step where an agent writes tests around code it already produced. This skill uses tests to define observable behavior before implementation, then follows a red, green, and refactor cycle.
Install and start
Run the following plugin command inside a Claude Code session to install Superpowers, including its cooperating skills. In Codex, find Superpowers in the plugin interface and install it there. Install separately for each client you use. Start a fresh session in the project and explicitly ask to use test-driven-development with a bounded task.
/plugin install superpowers@claude-plugins-official
Select one observable rule
Adapt this first request to your project:
Use Superpowers test-driven-development to reject expired discount codes. Inspect the test framework and time handling, write one failing behavior test, confirm why it fails, then make the smallest implementation change. Check the boundary date and existing valid codes without rewriting unrelated modules.
Narrow the request to a rule such as rejecting an expired discount code, including the exact date boundary. The agent should inspect existing test conventions, fixture helpers, and time dependencies before creating a test. Avoid introducing a second testing framework merely to follow an example. Resolve an undecided business rule before encoding it in assertions.
Make the failure meaningful
Run the smallest new test and inspect why it fails. An import error, typo, or missing environment does not establish that the test detects the missing behavior. If it passes immediately, determine whether the behavior already exists or the assertion is too weak. Do not delete valid implementation simply to manufacture a red result.
Next, add only enough implementation to satisfy that behavior. Additional options, caches, and generic abstractions require their own justification and tests. Prefer exercising the actual code path over asserting that a mock was called; use substitutes for external boundaries where they are needed.
Refactor while preserving green
Once the new and relevant existing tests pass, improve names, remove duplication, or separate responsibilities without changing behavior. In the discount example, check the expiry boundary and existing valid cases so the new rule does not reject legitimate codes. Report pre-existing suite failures separately from failures introduced by the change.
The deliverable includes the behavior test, minimal implementation, and commands actually run. A statement that TDD was followed is not a substitute for the observed red and green states. The upstream workflow is strict about implementation written before tests; identify existing user work before starting so that requirement is not mistaken for permission to discard unrelated code.
Prototypes, configuration edits, and visually judged interactions may need a different verification shape. Agree on appropriate exceptions and evidence instead of forcing identical test granularity onto every task. Passing tests establish the behavior they express, so reviewing whether assertions match the real requirement remains essential.
A second example: an authorization boundary
Suppose only members of an order's organization may download its invoice. Define observable behavior: same-organization members succeed, outsiders are denied, and nonexistent orders follow the project's response convention. Begin with one test for an outsider. Run it with the project's real identity and order fixtures, verifying that it fails because organization checks are missing, not because authentication is misconfigured or the test database is down. Add the smallest permission check at the actual download entry point, see the test turn green, then add the allowed-member case.
During refactoring, ensure authorization lives at a shared entry point rather than only hiding a UI button. A separate batch-download API needs its own case; one button test does not secure every route. A substitute can isolate external invoice storage, but asserting only that a permission helper was called is weaker than checking the final status or whether a file can be obtained. Keep commands and red/green outputs so reviewers can verify the behavior and sequence.
When the test suite is the deliverable
First distinguish whether the deliverable is production behavior or a test system. If the task is an acceptance-test catalogue, tests for unbuilt behavior may remain red, but the runner, fixtures, and DSL are code that needs its own checks. In one long-running project, small detector unit tests were all green while a realistic HTTP trace exposed an interaction failure. Add a composite input near the real request path for critical rules and confirm that the test catches the bad behavior. Keep an explicit owner and marker for deferred assertions rather than deleting them merely to make CI green.