Interface-First TDD for Production Changes
Define interfaces, add one failing behavior test at a time, and refactor with verified red-green evidence.
Before & after
Same prompt, same agent — the only difference is the skill.
Test-driven development is a solid approach for ensuring code quality. You'd write a failing test first, then write the minimal code to make it pass, and finally refactor for clarity. The key is to do one test at a time. You should think about edge cases like empty input, malformed data, and normal cases. I could help you plan which tests to write and in what order. It might be useful to mock some dependencies. What testing framework are you using?
FAILING TEST 1: parseDoc handles valid input
test('parses single paragraph into tokens', () => {
const doc = 'Hello world';
const result = parseDoc(doc);
expect(result.first().type).toBe('token');
});
MINIMAL PASS: Split input by space, return array of objects with type equal to token
REFACTOR CANDIDATE: Extract tokenizer into separate function
FAILING TEST 2: parseDoc handles empty input
test('returns empty array for blank document', () => {
expect(parseDoc('')).toEqual(emptyArray);
});
MINIMAL PASS: Add guard clause
REFACTOR CANDIDATES
• Move whitespace handling to tokenizer
• Add token position tracking
• Extract boundary detection logic
COVERAGE DELTA: 41% to 64%
MOCK INVENTORY: None yet; next loop consider faking file I/OAbout this skill
Your tests pass, but every refactor breaks the mocks and the next edge case still ships as a bug. This workflow starts with the public contract, turns its promises into observable behavior tests, and requires evidence for each red-green step before the agent moves on.
What it does
- Defines signatures, failure behavior, state ownership, and compatibility constraints before implementation.
- Builds a prioritized behavior list around ordinary use, boundaries, failures, and isolation between callers.
- Adds one behavior test at a time and distinguishes an expected failure from a broken test environment.
- Uses deterministic clocks, fakes, and boundary adapters without mocking internal implementation details.
- Evaluates refactors only after the relevant tests pass, favoring simple interfaces that hide complexity.
- Tracks actual test results, remaining behaviors, interface changes, and any unverified checks.
What you get
A scoped contract and behavior list, implementation changes when code access is available, and a compact red-green-refactor record. The handoff identifies compatibility changes, test doubles, verification limits, and any measured coverage change.
Best for
Developers using Claude on production features, regression fixes, legacy modules, or autonomous coding loops where test quality and interface stability matter.
SKILL.md preview
---
name: interface-first-tdd-for-production-changes
description: Define an observable interface contract, select behavior tests, and implement production changes through one-test-at-a-time red-green-refactor cycles with recorded evidence. Use when the user says "build this with TDD", "design the interface first", "one test at a time", "my tests pass but bugs keep shipping", "stop mocking every internal call", "add a regression test before fixing this", or "keep this agent loop honest".
---
# Interface-First TDD for Production Changes
… (sign up to view the full skill)More development skills
View all Development skills →React and Next.js Regression Test Coverage
Generate React and Next.js tests with Jest, Testing Library, MSW, and Playwright, prioritized by regression risk.
Playwright E2E Tests and Flake Repair
Build reliable Playwright tests, repair flakes from evidence, migrate suites, and configure faster, diagnosable CI.
Pre-Ship Verification for Code Changes
Before calling a code change done, Claude grades every claim by evidence, tries to break it, and reports what's verified vs assumed.
TestRail Case and CI Result Sync
Sync automated tests to TestRail cases and scoped runs with stable mappings, retry handling, and verified result counts.