Implement Code Using Test-Driven Development

This skill enforces test-driven development as a hard rule rather than a guideline: the "Iron Law" is no production code without a failing test first, and code written before its test must be deleted entirely - not kept "as reference," not adapted, not looked at. It walks the RED (write one minimal test showing real behavior, no vague names, minimal mocking) - Verify RED (mandatory: run the test and confirm it fails for the right reason, not a typo) - GREEN (write the simplest code that passes, no added options or "improvements" beyond the test) - Verify GREEN (mandatory: confirm it passes and nothing else broke) - REFACTOR (clean up while staying green, no new behavior) cycle, each with concrete good/bad TypeScript examples.

Its most distinctive content is a rationalization-busting section: it directly rebuts common excuses for skipping TDD - "I'll test after" (tests passing immediately prove nothing), "I already manually tested it" (ad-hoc isn't systematic and leaves no record), "deleting X hours of work is wasteful" (sunk cost fallacy; unverified code is technical debt), "TDD is dogmatic, I'm being pragmatic" (debugging in production is slower than test-first), and "tests after achieve the same goals" (tests-after answer "what does this do," tests-first answer "what should this do"). It lists explicit red flags that mean "delete the code and start over," a troubleshooting table for when you're stuck (can't figure out how to test something means the design is too complicated), and a pre-completion verification checklist.

Use this skill always for new features, bug fixes, refactoring, and behavior changes - the source treats "skip TDD just this once" as a rationalization to catch and reject, not a legitimate exception. The only sanctioned exceptions - throwaway prototypes, generated code, configuration files - require explicit sign-off from a human partner, not a unilateral call.

It is not a softer "TDD when convenient" framework - it's designed specifically to close the loopholes that let TDD erode in practice, so it's the wrong fit if the team has already decided on a more flexible test-after or hybrid testing strategy.

Input is a feature to build or a bug to fix. Output is, per the Iron Law, always in this order: a failing test proving the desired behavior, verification that it failed for the right reason, minimal code to pass, verification that it passes, and a refactor pass that keeps everything green - illustrated end to end with a worked bug-fix example (rejecting an empty email field).

npm test path/to/test.test.ts

Illustrated with TypeScript and Jest-style test syntax (test(...), expect(...)), and cross-references a companion testing-anti-patterns.md reference for pitfalls when adding mocks or test utilities (testing mock behavior instead of real behavior, adding test-only methods to production classes).

Developers or AI coding agents who want TDD enforced as a strict, non-negotiable discipline - including a built-in defense against the rationalizations that erode it - rather than a flexible best-practices suggestion.