Implement TDD Cycle for Robust Code

This skill provides a structured Test-Driven Development workflow: the RED-GREEN-REFACTOR cycle (write a failing test, write minimal code to pass it, improve code quality, repeat), governed by the "Three Laws of TDD" (write production code only to make a failing test pass, write only enough test to demonstrate failure, write only enough code to make the test pass) and the Arrange-Act-Assert pattern for structuring each test.

TDD value is rated per scenario: high for new features, bug fixes (write the reproducing test first), and complex logic; low for exploratory work (spike first, then apply TDD) and UI layout. Test prioritization follows happy path, then error cases, then edge cases, then performance.

RED phase: write tests describing behavior ("should add two numbers"), edge cases ("should handle empty input"), and error states ("should throw for invalid data"); the test must fail first, its name should describe the expected behavior, and ideally it has one assertion. GREEN phase: apply YAGNI (You Aren't Gonna Need It) and write the simplest code that passes, with no optimization and nothing beyond what's needed. REFACTOR phase: extract duplication, clarify naming, improve structure, simplify complexity - while keeping all tests green, making small incremental changes, and committing after each refactor. Every test follows Arrange (set up test data), Act (execute the code under test), and Assert (verify the expected outcome).

Named anti-patterns to avoid: skipping the RED phase (watch the test fail first instead), writing tests after the code (write them before), over-engineering the initial implementation (keep it simple), using multiple asserts per test (one behavior per test), and testing implementation details instead of behavior. An AI-augmented, multi-agent variant assigns distinct roles: one agent writes the failing tests (RED), a second implements code to pass them (GREEN), and a third optimizes the result (REFACTOR) - splitting the same discipline across separate agents instead of one agent doing all three phases.

Developers and teams practicing test-driven development - solo or with AI agents split across the RED/GREEN/REFACTOR roles - who want a concrete cycle, prioritization order, and anti-pattern checklist rather than an informal "write tests eventually" habit. The skill's own closing principle: the test is the specification - if you can't write a test for something, you don't yet understand the requirement well enough to implement it.