tl;dr: the discipline skill from obra/superpowers. The whole SKILL.md collapses to one rule: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. Not “write tests eventually”, not “add coverage”, not “I tested it manually” — write the test, run it, watch it fail for the right reason, then write the smallest code that passes. The skill ships with rationalization tables and a red-flag list because the failure mode is the agent talking itself out of step one.

What it actually does

SKILL.md (obra/superpowers, fetched 2026-09-10) walks the red-green-refactor cycle as a state machine with two mandatory verification gates:

RED ──▶ Verify RED fails correctly ──▶ GREEN ──▶ Verify GREEN passes ──▶ REFACTOR ──▶ next
                │                              │
                │ wrong failure                │ no
                └──────────▶ RED               └──────▶ GREEN

Phase	What you do	Verification
RED	Write one minimal test showing the behavior you want. Real code, not mocks unless unavoidable. Clear name; “and” in the name → split it.	Mandatory: run `npm test path/to/test.test.ts` (or your runner). Confirm: test fails, failure message is expected, fails because the feature is missing — not a typo. Pass-on-first-run means you’re testing existing behavior; fix the test.
GREEN	Smallest code that passes. No extra features, no YAGNI options, no refactoring of unrelated code.	Mandatory: run the test again. Confirm: it passes, other tests still pass, output pristine.
REFACTOR	Remove duplication, improve names, extract helpers. Keep tests green. Don’t add behavior.	Loop back to Verify GREEN.
Repeat	Next failing test for the next behavior.

The skill does not stop at the cycle. It ships a Good Tests quality table (minimal, clear, shows intent) that points at a sibling writing-good-tests.md for the deeper rules — name the production change that would make the test fail before you write it; assert on real behavior, never on mock behavior.

The Iron Law

The middle of the file is a single rule, repeated three times:

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.

Write code before the test? Delete it. Start over.

No exceptions: don’t keep it as “reference”, don’t “adapt” it while writing tests, don’t look at it. Delete means delete. Implement fresh from tests. Period.

This is the part the rationalization tables exist to defend. The skill knows what you are about to say.

Common rationalizations (verbatim, condensed)

Excuse	Reality
”Too simple to test”	Simple code breaks. Test takes 30 seconds.
”I’ll test after”	Tests written after pass immediately — which proves nothing. You never watched it fail.
”Tests after achieve the same goals (spirit not ritual)“	Tests-after answer “what does this do?”; tests-first answer “what should this do?” Biased by code you already wrote.
”Already manually tested”	Ad-hoc. No record of what you covered. Worked when I tried it ≠ comprehensive.
”Deleting X hours is wasteful”	Sunk cost. Keep the code and bolt tests on later = low confidence, likely bugs.
”Keep as reference, write tests first”	You’ll adapt it. That’s testing after. Delete means delete.
”Need to explore first”	Fine. Throw away the exploration, start with TDD.
”Test hard = design unclear”	Listen to the test. Hard to test = hard to use.
”TDD will slow me down”	TDD catches bugs before commit, prevents regressions, lets you refactor without fear. “Pragmatic” shortcuts = debugging in production.
”Existing code has no tests”	You’re improving it. Add tests for existing code.

Red flags — STOP and start over

Code before test
Test after implementation
Test passes immediately
Can’t explain why test failed
Tests added “later”
Rationalizing “just this once”
“I already manually tested it”
“Tests after achieve the same purpose”
“It’s about spirit not ritual”
“Keep as reference” or “adapt existing code”
“Already spent X hours, deleting is wasteful”
“TDD is dogmatic, I’m being pragmatic”
“This is different because…”

All of these mean: delete code, start over with TDD.

Exceptions

The skill is explicit: there are three, and they all require human-partner permission.

Throwaway prototypes
Generated code
Configuration files

Anything else, even the “trivial” stuff, goes through the cycle.

When it fires

Frontmatter description: “Use when implementing any feature or bugfix, before writing implementation code.” Hosts that load skills metadata (Claude Code, Cursor via plugins) pick this up automatically. On Claude Code, the same using-superpowers bootstrap that injects brainstorming and dispatching triggers this on the next implementation step.

The skill is positioned as the universal entry point: brainstorming → spec → plan → TDD on every task. executing-plans calls it out by name at the top of each task.

Install

The upstream README does not document npx skills add obra/superpowers. Install is per-harness and the README enumerates thirteen of them. The most common paths:

# Claude Code — official Anthropic marketplace
/plugin install superpowers@claude-plugins-official

# Claude Code — Superpowers marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# Codex CLI — official Codex marketplace
/plugins
# search: superpowers → Install Plugin

# Cursor
/add-plugin superpowers

# Gemini CLI
gemini extensions install https://github.com/obra/superpowers

# OpenCode — host fetches install doc itself
# Say: "Fetch and follow instructions from
#       https://raw.githubusercontent.com/obra/superpowers/main/.opencode/INSTALL.md"

# Antigravity
agy plugin install https://github.com/obra/superpowers

If your host only watches a local SKILL.md, clone the repo and drop the skill folder:

git clone https://github.com/obra/superpowers
# place at any path your host's skill loader watches:
#   ~/.claude/skills/test-driven-development/SKILL.md
#   .claude/skills/test-driven-development/writing-good-tests.md

The published SKILL.md references writing-good-tests.md as a sibling. Install the whole skills/test-driven-development/ directory, not just SKILL.md.

Gotchas

Watch-it-fail is the load-bearing step. “Test passes on first run” is a failure mode the skill calls out by name. If your test passes before you write the code, the test isn’t testing the new behavior — fix the test, not the code.
Mocks are a smell. The skill allows them only when unavoidable and insists tests assert on real behavior. The “Bad” example in SKILL.md is a jest.fn().mockRejectedValueOnce chain — it tests the mock, not the code. Don’t ship that pattern.
GREEN means minimal, not “while I’m here”. The “Bad” GREEN example adds maxRetries, backoff, onRetry options — three things the test didn’t ask for. YAGNI is enforced; the cycle does not get to wander into a refactor until RED → GREEN is locked.
Don’t lower the bar on bugs. Bug fix example in the file is explicit: write a failing test that reproduces the bug, then make it pass. Never fix bugs without a test — the test proves the fix and prevents regression.
sandbox_test.verdict: untested — we read the file and the README; we did not run a TDD eval in the sandbox. Per config/skill-safety.md, this stays untested until a human runs the eval-vs-prompt harness (same task, prompt-only vs SKILL.md-in-context).
The “spirit not ritual” escape hatch is closed. The skill names it explicitly: tests-after answer a different question than tests-first. If the agent (or the human) reaches for it, the response is “delete code, start over”.

Related: Brainstorming (obra/superpowers) — the upstream HARD-GATE that produces the spec TDD implements; Requesting Code Review (obra/superpowers) — the dispatch-side reviewer that verifies each task’s tests actually mean something; Executing Plans (obra/superpowers) — the workflow that calls TDD at the top of every task.

Test-Driven Development (obra/superpowers)

## what it does