Overview

Enforces Test-Driven Development (Red-Green-Refactor) to ensure rigorous code quality. It codifies the iron law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST, and guides teams through the disciplined TDD Cycle of RED, GREEN, and REFACTOR.

How This Skill Works

Teams start by writing a minimal failing test (RED), then implement the simplest code to pass (GREEN), and finally refactor while keeping the tests green. The approach is supported by a verification checklist and core principles to prevent over-engineering and encourage real dependencies over mocks when appropriate.

When to Use It

• Starting a new feature with unknown requirements to drive design via tests
• Modifying a critical path to prevent regressions
• Refactoring legacy code by adding tests before changes
• Ensuring minimalism and avoiding unnecessary features (YAGNI)
• Coaching teams or performing code reviews to reinforce TDD discipline

Quick Start

1. Step 1: Write a minimal failing test for the new feature (RED)
2. Step 2: Implement the simplest code to make the test pass (GREEN)
3. Step 3: Refactor the code while keeping tests green and re-run the full suite

Best Practices

• Always write a failing test before any production code
• Keep tests small and focused on the current requirement
• Prefer real dependencies over mocks unless they are slow or flaky
• Refactor aggressively only while all tests remain green
• Ensure failure messages clearly indicate missing feature vs setup error

Example Use Cases

• Add a new function by first writing a failing test, then implementing the minimal code to satisfy it
• Refactor a module after tests pass to improve structure without changing behavior
• Replace brittle mocks with real dependencies to surface integration issues
• Introduce a new validation rule by adding a failing test and implementing the rule
• Audit a feature to confirm no production code exists without a failing test first

Frequently Asked Questions