Green

---
name: green
description: TDD Green Phase - Implement minimal code to make the failing test pass
---

# TDD Green Phase

You are now in the **Green Phase** of TDD. Follow these instructions to implement the minimal code that makes the failing test pass.

## Your Mission

Guide developers through the Green phase of TDD by helping them:
1. Implement the **minimal code** necessary to make the failing test pass
2. Use the **simplest possible solution** (hardcoded values are acceptable)
3. Avoid adding features for future tests
4. Verify all tests pass
5. Maintain strict TDD discipline - no optimization, no refactoring yet

## Context: $ARGUMENTS

## Green Phase Rules
- **Minimal code only**: Just enough to pass the current test
- **Baby steps**: Make the smallest possible change
- **No future features**: Don't implement what future tests might need
- **Simple is better**: Hardcoded returns are perfectly fine
- **Tests must pass**: Verify all tests are green
- **No refactoring yet**: Save improvements for Refactor phase

## Green Phase Process

### Step 1: Analyze the Failing Test
- Understand what the test expects
- Identify the minimal change needed
- Consider the simplest possible solution

### Step 2: Write Minimal Implementation
- Implement **only what's needed** to make the current test pass
- Use the **simplest possible solution**:
  - Hardcoded return values (`return 0`, `return true`, `return []`)
  - Single line implementations
  - No complex logic unless absolutely necessary
- Don't add features for future tests
- Don't optimize or refactor yet

### Step 3: Run Tests
- Execute the test suite
- Verify the current test now passes
- Ensure all previously passing tests still pass

### Step 4: Verify No Over-Implementation
Check for these violations:
- Did you implement features for future tests?
- Did you add logic not demanded by current test?
- Did you optimize prematurely?
- Did you refactor existing code?

If any answer is "yes", remove the extra code.

### Step 5: Report Completion
```
Green Phase Complete:
**Implementation**: [describe what was implemented]
**Result**: All tests now pass
**Approach**: [explain why this is minimal]

Proceeding to Refactor phase.
```

## Minimal Implementation Strategies

### Common Patterns

#### Hardcoded Returns (Preferred for Initial Tests)
```typescript
// Test: "should return 0 for empty input"
function calculate(numbers: number[]): number {
  return 0; // Minimal - just make the test pass
}
```

#### Simple Conditionals (When Multiple Tests Pass)
```typescript
// Test: "should return number for single input"
function calculate(numbers: number[]): number {
  if (numbers.length === 0) return 0;
  return numbers[0]; // Minimal - return first element
}
```

#### Avoid Complex Logic Initially
```typescript
// Bad: Over-implementation
function calculate(numbers: number[]): number {
  return numbers.reduce((sum, num) => sum + num, 0);
}

// Good: Minimal for early tests
function calculate(numbers: number[]): number {
  if (numbers.length === 0) return 0;
  if (numbers.length === 1) return numbers[0];
  return numbers[0] + numbers[1]; // Just enough for "two numbers" test
}
```

## Important Guidelines

### What to DO
- Write minimal code to make test pass
- Use hardcoded values when appropriate
- Take baby steps
- Verify all tests pass
- Keep implementation as simple as possible

### What NOT to do
- Never implement beyond what tests demand
- Never add features for future tests
- Never optimize prematurely
- Never refactor during Green phase
- Never make multiple changes at once

## Psychological Resistance

Developers will experience strong resistance:
- **Feels "too simple"** - This is correct! Minimal steps are the way
- **Hardcoded values feel wrong** - They're exactly right for early tests
- **Urge to implement ahead** - Resist this strongly
- **Feels inefficient** - Actually accelerates development
- **Want to optimize** - Save it for Refactor phase
- **Trust the process** - Simple steps compound into elegant solutions

## Baby Steps Principle

### Core Concept
Make the **smallest possible change** to get to green:

1. **First test**: Return hardcoded value
2. **Second test**: Add simple conditional
3. **Third test**: Generalize only when forced by test
4. **Never** implement ahead of tests

### Example Progression
```typescript
// Test 1: "should return 0 for empty input"
function calculate(numbers: number[]): number {
  return 0; // Hardcoded - minimal
}

// Test 2: "should return number for single input"
function calculate(numbers: number[]): number {
  if (numbers.length === 0) return 0;
  return numbers[0]; // Still simple
}

// Test 3: "should add two numbers"
function calculate(numbers: number[]): number {
  if (numbers.length === 0) return 0;
  if (numbers.length === 1) return numbers[0];
  return numbers[0] + numbers[1]; // Only now add logic
}

// Test 4: "should add multiple numbers"
function calculate(numbers: number[]): number {
  // NOW generalize to handle all cases
  return numbers.reduce((sum, num) => sum + num, 0);
}
```

## Red Flags

Watch for these violations:
- Implementing logic for future tests
- Adding features not demanded by current test
- Optimizing or refactoring during Green phase
- Complex solutions when simple ones work
- Multiple changes at once

## Remember

- **Minimal code only** - Just enough to pass the test
- **Baby steps** - Smallest possible change
- **Simple is better** - Hardcoded values are fine
- **No future features** - Only implement what tests demand
- **Trust the process** - Simplicity leads to better solutions

Your goal is to maintain strict minimalism, prevent over-implementation, and pass the current test with the simplest possible code.