home / skills / georgekhananaev / claude-skills-vault / plan-to-tdd

plan-to-tdd skill

/.claude/skills/plan-to-tdd

This skill helps you convert plan docs into test-driven code with structured tests and contracts across unit, integration, and E2E.

npx playbooks add skill georgekhananaev/claude-skills-vault --skill plan-to-tdd

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
7.5 KB
---
name: plan-to-tdd
description: Transform feature plans into test-driven implementation using Outside-In methodology. This skill should be used when converting documented plans from docs/plan/ into testable code w/ proper test structure (Unit, Integration, E2E).
---

# Plan-to-TDD

Transform feature plans → test-driven implementation using Outside-In methodology.

## When to Use

Invoke when:
- Converting plan docs from `docs/plan/YYYY/MM/` to code
- Designing test structure for new features
- Applying TDD w/ architectural awareness
- Bridging system design to implementation

## Prerequisites

- Reference: `.claude/skills/test-levels` for Unit/Integration/E2E guidance
- Plan files in `docs/plan/YYYY/MM/YYYY_MM_DD_HHmm__FEATURE_NAME.md`

## Related Skills

| Skill | Location | Phase |
|-------|----------|-------|
| `doc-navigator` | `.claude/skills/doc-navigator` | Load/Design - find existing patterns |
| `uiux-toolkit` | `.claude/skills/uiux-toolkit` | Verify - 9-domain UX evaluation |
| `test-levels` | `.claude/skills/test-levels` | Plan/Execute - test distribution |

---

## Outside-In Workflow

```
SYSTEM DESIGN → INTEGRATION TESTS (Red) → TDD UNITS → E2E VALIDATION
```

### Phase Flow

```
┌─────────────────────────────────────────────────┐
│ 1. SYSTEM DESIGN                                │
│    Components → Contracts → Dependencies        │
└────────────────────┬────────────────────────────┘
                     ▼
┌─────────────────────────────────────────────────┐
│ 2. INTEGRATION TESTS (Red)                      │
│    Validate component contracts - tests FAIL    │
└────────────────────┬────────────────────────────┘
                     ▼
┌─────────────────────────────────────────────────┐
│ 3. TDD UNIT PHASE                               │
│    Red → Green → Refactor per unit              │
└────────────────────┬────────────────────────────┘
                     ▼
┌─────────────────────────────────────────────────┐
│ 4. E2E VALIDATION                               │
│    Complete user journey verification           │
└─────────────────────────────────────────────────┘
```

---

## Execution Steps

### Step 1: Load Plan

**Input:** `docs/plan/YYYY/MM/YYYY_MM_DD_HHmm__FEATURE_NAME.md`

**Extract:**
1. User story & acceptance criteria
2. Components & dependencies
3. Data flows
4. Technical constraints

**Expected structure:**
```markdown
# Feature: [Name]

## User Story
As a [user], I want to [action] so that [benefit].

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

## Components
- Component A: Description
- Component B: Description

## Data Flow
1. Step 1
2. Step 2
```

### Step 2: Define Contracts

For each component boundary:

```typescript
interface [Component]Contract {
  input: {
    type: string;
    validation: string[];
    source: string; // sender component
  };
  output: {
    type: string;
    successCase: string;
    errorCases: string[];
  };
  dependencies: string[];
}
```

### Step 3: Generate Tests

#### E2E Tests (Complete Car)
```typescript
// tests/e2e/[feature].spec.ts
describe('[Feature] - User Journey', () => {
  test('User can [action] successfully', async () => {
    // Arrange → Act → Assert
  });
  test('User sees error when [condition]', async () => {
    // Error path from user perspective
  });
});
```

#### Integration Tests (Engine + Transmission)
```typescript
// tests/integration/[component].test.ts
describe('[ComponentA] → [ComponentB]', () => {
  test('Contract: [description]', async () => {
    // Validates the "arrow" in system design
  });
  test('Handles timeout gracefully', async () => {
    // Test architectural assumptions
  });
});
```

#### Unit Tests (Individual Parts)
```typescript
// tests/unit/[module].test.ts
describe('[Module]', () => {
  test('returns [expected] when [condition]', () => {
    // Red → Green → Refactor
  });
  test('throws [error] when [invalid input]', () => {
    // Edge cases
  });
});
```

### Step 4: Implementation Order

```
1. Scaffold        Create files & empty interfaces
       ↓
2. E2E (Red)       Failing E2E for user journey
       ↓
3. Integration     For each boundary:
   (Red)           - Failing integration test
                   - Validates contract
       ↓
4. TDD Cycle       For each unit:
   (Red→Green→     - Failing unit test
    Refactor)      - Min code to pass
                   - Refactor for clarity
       ↓
5. Integration     Run integration (should pass)
   (Green)
       ↓
6. E2E (Green)     Run E2E (should pass)
       ↓
7. Refactor        Clean up, optimize
```

---

## The Bridge: Design → Mocks

System design arrow becomes mock:

```
┌─────────────┐    ┌─────────────┐
│ OrderService│───▶│InventorySvc│
└─────────────┘    └─────────────┘
```

```typescript
const mockInventoryService = {
  checkStock: jest.fn(),
};

describe('OrderService', () => {
  test('throws OutOfStockException when inventory = 0', () => {
    mockInventoryService.checkStock.mockReturnValue(0);
    expect(() => orderService.placeOrder(item))
      .toThrow(OutOfStockException);
  });
});
```

**Key insight:** TDD validates architectural contracts:
- Timeouts in design → Test timeout handling
- Error responses → Test error handling
- Data transforms → Test transformations

---

## Test Pain → Design Fix

| Pain Signal | Design Issue | Fix |
|-------------|--------------|-----|
| 50+ lines mock setup | Too coupled | Split into smaller services |
| Needs real DB | Missing abstraction | Add repository interface |
| Can't test isolated | Circular deps | Restructure dependency graph |
| Brittle tests | Leaky abstractions | Strengthen contracts |

**When pain detected:**
1. Stop coding
2. Document the pain
3. Return to design
4. Refactor architecture
5. Resume TDD

---

## Output Artifacts

Generate in `/docs/features/[feature]/`:
- `DESIGN.md` - System design doc
- `CONTRACTS.md` - Interface contracts
- `TEST-PLAN.md` - Test structure & order
- `IMPLEMENTATION.md` - Build plan w/ tasks

---

## Quick Reference

```bash
# Load & parse plan
/load-plan [plan-path]

# Extract components
/extract-components [plan-path]

# Generate contracts
/define-contracts [plan-path]

# Generate test scaffolds
/generate-tests [plan-path]

# Start TDD w/ first red test
/tdd-start [plan-path]

# List plans
/list-plans
/list-plans --month 2024-03
```

---

## Test Distribution (from test-levels)

| Level | Question | Location |
|-------|----------|----------|
| Unit | "Does this fn work?" | `tests/unit/` |
| Integration | "Do parts connect?" | `tests/integration/` |
| E2E | "Does flow work?" | `tests/e2e/` |

**Pyramid:** Many unit → Some integration → Few E2E

Overview

This skill transforms documented feature plans into a test-driven implementation using an Outside-In methodology. It guides you from plan parsing to E2E validation, producing contracts, test scaffolds, and a clear TDD execution order. The goal is predictable, architecture-aware implementation with minimal design drift.

How this skill works

Load a plan file from docs/plan/YYYY/MM/ and extract user story, acceptance criteria, components, data flows, and constraints. Define component contracts at each boundary, scaffold E2E/integration/unit tests (red first), then drive implementation through an Outside-In TDD loop: failing E2E → failing integration → unit TDD cycles → green integration → green E2E → refactor. Produce DESIGN.md, CONTRACTS.md, TEST-PLAN.md, and IMPLEMENTATION.md artifacts.

When to use it

  • Converting plan docs in docs/plan/YYYY/MM/ into testable code and tasks
  • Designing test structure for a new feature with clear test distribution (Unit/Integration/E2E)
  • Applying TDD while preserving architectural contracts
  • Bridging high-level system design into implementation-ready mocks and interfaces
  • Refactoring when tests expose architectural pain points

Best practices

  • Start Outside-In: scaffold E2E that describes the user journey and keep it failing initially
  • For each component boundary, define a concise contract (inputs, outputs, error cases, dependencies)
  • Keep unit tests focused: Red → Green → Refactor for a single responsibility at a time
  • Use lightweight mocks to represent upstream/downstream components until integration tests validate real interactions
  • When tests become brittle or verbose, stop and fix the design (document the pain, refactor contracts, resume TDD)

Example use cases

  • Implementing a checkout flow: generate E2E journey, define OrderService ↔ Inventory contract, TDD order placement units
  • Adding a new API endpoint: extract acceptance criteria, scaffold integration tests against service boundaries, develop units per contract
  • Migrating a tightly coupled module: detect long mock setups in tests, split into smaller services and add repository interfaces
  • Validating timeout and error handling: write integration tests that assert architectural assumptions before unit work

FAQ

What input file formats does the skill expect?

It expects plan markdown files in docs/plan/YYYY/MM/YYYY_MM_DD_HHmm__FEATURE_NAME.md following the Feature → User Story → Acceptance Criteria → Components → Data Flow structure.

Which test levels are generated and in what order?

It scaffolds E2E, Integration, and Unit tests. Execution order follows Outside-In: E2E (red) → Integration (red) → Unit TDD cycles → Integration (green) → E2E (green) → Refactor.

What artifacts are produced by the workflow?

Design and implementation artifacts: DESIGN.md, CONTRACTS.md, TEST-PLAN.md, and IMPLEMENTATION.md placed under docs/features/[feature]/.