Test-Driven Development (TDD)
Iron rule: no production code without a failing test written first — code written out of order gets deleted and restarted, no "tests added after"
The skill clearly targets new features, bug fixes, refactoring, and behavior changes, and provides a reusable RED-GREEN-REFACTOR process, test-quality criteria, and regression-debugging guidance. This has direct value for software-development agents. Boundaries are partly stated through human-approved exceptions for prototypes, generated code, and configuration, but the “always use” rule may not fit every project or testing-cost context.
The workflow is explicit and reproducible: write one failing test, verify the expected failure, implement the minimum code, verify all tests, and refactor only after green. It includes handling for test errors, immediate passes, unrelated failures, and complex mocks. Evidence gaps include dependence on project-specific test frameworks, commands, and environments; examples assume npm and Jest/Vitest-like conventions, with no cross-language adaptation guidance or execution results for this skill.
The skill does not request network access, credentials, sensitive data, or elevated permissions. Its primary effects are on code and testing workflow, and there is no evidence of malware, covert exfiltration, or credential theft. The main risk is the forceful instruction to delete code written before a test, which could lose uncommitted work; backup, version-control confirmation, recovery, and renewed user consent are not specified, weakening reversibility and least-harm guarantees.
SKILL.md includes a workflow diagram, command examples, good and bad test examples, checklists, anti-pattern tables, and failure-handling guidance, supporting the methodology claims. The repository README says skill behavior is tested with a drill eval harness, but the supplied material does not show results, coverage, or independent review for this selected skill. Claims about speed, confidence, and systematic benefits are not quantitatively substantiated, and fact versus inference is not consistently separated.
Trigger conditions, core inputs (a desired behavior or defect), and completion criteria are reasonably clear, and the “when stuck” table supports stepwise agent use. Gaps include no guidance for different languages, test runners, or choosing unit versus integration tests; npm test is not universal. Test duration, resource cost, behavior when tests cannot run, and an explicit blocked/exit reporting procedure are also missing.
The selected skill has a name and description, while repository materials provide an MIT license, version 6.1.1, revision information, and README-level update and issue channels. Publisher identity is unverified and therefore provides no official-governance credit. The skill itself lacks a version, changelog, owner, compatibility matrix, and explicit update responsibility or response commitment, so maintenance traceability is limited.
- Do not apply the “delete code written first” rule without confirming that the work is committed, recoverable, or explicitly approved by the user; preserve a patch, use version control, or create a recovery point first.
- npm test, TypeScript, and particular mocking conventions are not universal interfaces; add adaptation and exit guidance before using the skill with other languages, test frameworks, or environments where tests cannot run.
- The README’s reference to an evaluation harness is not evidence of results for this selected skill; no tests were executed in this review, so the repository’s testing infrastructure is not independent validation.
What it does & when to use it
A strict version of the standard RED-GREEN-REFACTOR cycle, centered on the rule "no production code without a failing test first." If code does get written before its test, the only allowed response is deleting it and starting over — not keeping it as reference, not writing tests while secretly peeking at the existing implementation. The doc spends significant space rebutting common excuses ("tests after achieve the same goal," "I already tested it manually," "deleting hours of work is wasteful") one by one, explaining why writing tests after isn't equivalent to writing them first.
RED: write one test describing the expected behavior — single responsibility, clear name, real code preferred over mocks. Verify RED: run it and confirm it actually fails, and fails for the right reason (missing feature, not an unrelated typo). GREEN: write the minimal code that passes — no bonus features or parameters along the way. Verify GREEN: run it, confirm it passes without breaking anything else, and the output is clean with no warnings. REFACTOR: clean up only after everything is green — remove duplication, improve names, extract helpers — keeping tests green throughout. Ships with a separate testing-anti-patterns reference covering pitfalls like testing mock behavior instead of real behavior, and adding test-only methods to production classes.
- Before implementing any feature or bug fix, write a failing test describing the expected behavior and run it to confirm it actually fails
- Code was already hand-written before its test — per the rule, delete it and restart from the test rather than retrofitting tests onto it
- Fixing a bug: write a failing test that reproduces it first, then fix via RED-GREEN-REFACTOR, guarding against future regressions in the same pass
Pros & cons
- Takes a clear, argued position on the common team disagreement of "does writing tests after count as TDD" (tests-after only prove "what does this do," tests-first prove "what should this do"), cutting down on ambiguity
- All three phases require verification, not assumption — e.g. explicitly requiring the test be run to confirm it fails, and for the right reason, rather than assuming it will fail once written
- The anti-patterns reference is broken out separately and covers real, common testing quality problems — testing mock behavior, stuffing test-only methods into production classes
- Only reliably self-enforcing on harnesses that actually read and follow SKILL.md instructions (Claude Code, Codex CLI, etc.) — in a plain chat interface it's just a document a human has to apply by hand.
- The "delete already-written code and restart" requirement is strict — for cases where substantial code already exists and just lacks tests, the cost of compliance is real, and a team needs to buy into this level of rigor for it to fit
- For exploratory prototypes or one-off scripts, the SKILL.md itself acknowledges exceptions need to be negotiated with a human — it isn't unconditional
How to install
Installed as part of the obra/superpowers plugin — individual skills can't be installed standalone:
- Claude Code: official marketplace
/plugin install superpowers@claude-plugins-official; or register the community marketplace with/plugin marketplace add obra/superpowers-marketplacethen/plugin install superpowers@superpowers-marketplace - Also supports Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi — see the repo README for the exact command per harness
Once installed, this skill activates alongside the other 13 Superpowers skills, auto-triggered by using-superpowers based on context — there's no separate invocation step.
How to use
Triggers automatically before implementing any feature or fixing any bug, before writing production code. systematic-debugging's Phase 4 (implementation) explicitly calls out using this skill to write the reproducing test.
Compared to similar skills
Compared to the common but looser practice of "write the code, then add tests," this skill's stance is closer to a strict, classic Kent Beck-style TDD — trading some flexibility for the certainty that tests actually verified the requirement. Compared to shipping with no tests at all, the value is self-evident; the real trade-off is whether a team accepts the hard requirement to delete and rewrite completed code.