tdd-red-green-refactor

---
name: tdd-red-green-refactor
description: >
license: Apache-2.0
---

# Red-Green-Refactor (TDD) Skill: TypeScript Edition

This skill implements a structural framework for AI-assisted programming to ensure every line of code is verifiable, typed, and purposeful.

## The Three-Phase Cycle

### Phase 1: Red (Establish Failure)
You must prove the feature does not exist and that your test is valid.
1. **Write One Test**: Create a single test case (e.g., in Vitest or Jest) for the next small piece of behavior.
2. **Execute & Fail**: Run the test. It must fail. 
3. **Verify**: Ensure the failure is related to the missing logic (e.g., `ReferenceError: add is not defined`) and not a configuration error.

### Phase 2: Green (Minimal Pass)
Make the test pass as quickly and simply as possible.
1. **Minimal Implementation**: Write the simplest code that satisfies the test. Do not build for the future; focus strictly on the current "Red" test.
2. **Run Tests**: Execute the suite. All tests must be Green.
3. **Evidence**: The transition from Red to Green is the "Proof of Work" for the developer.

### Phase 3: Refactor (Clean Up)
Improve the code structure while maintaining the "Green" state.
1. **Clean Up**: Improve naming, remove duplication, and optimize the code written in Phase 2.
2. **Safety Net**: Rerun the tests after every change. If they turn Red, revert the change immediately.

---

## Core Operational Rules

### 1. No "Horizontal Splurging"
You are strictly forbidden from writing a large "splurge" of multiple tests at once. You must follow a strictly incremental loop:
- **Write 1 Test -> See it Fail -> Write 1 Fix -> See it Pass**.
- Repeat this loop for every sub-feature.

### 2. Impose Backpressure
Use automated assertions and strong typing (TypeScript) as backpressure to prevent the AI from "guessing" the solution or "playing in the mud" with low-quality code.

### 3. Verification of Integrity
Never modify an existing test to make a failing implementation pass. If a test must change, it must be because the requirement changed, not because the code is difficult to write.

---

## Example Workflow (TypeScript + Vitest)

**Step 1: Red**
```typescript
// math.test.ts
import { describe, it, expect } from 'vitest';
import { add } from './math';

describe('add', () => {
  it('should sum two numbers', () => {
    expect(add(2, 2)).toBe(4); // Fails: ReferenceError: add is not defined
  });
});
```

**Step 2: Green**
```typescript
// math.ts
export const add = (a: any, b: any) => {
  return 4; // Passes: Minimal code to satisfy the test
};
```

**Step 3: Refactor**
```typescript
// math.ts
/**
 * Sums two numbers with explicit type safety.
 */
export const add = (a: number, b: number): number => {
  return a + b; // Passes: Proper implementation with safety net
};
```