tdd_skill

Overview

This skill enforces a strict Test-Driven Development (TDD) workflow for every code change: features, bug fixes, and refactors. TDD is non-negotiable—every production line must originate from a failing test. It also defines commit structure, PR evidence, and mandatory coverage verification.

How this skill works

Follow the RED → GREEN → REFACTOR cycle: write a failing test first, implement the minimum code to pass, then refactor safely with tests green. Commits should reflect the cycle (test:, feat:, refactor:) unless a documented exception applies. Before approving PRs, run coverage locally and verify all metrics meet the 100% requirement or document an approved exception.

When to use it

• All new features
• Bug fixes that change behavior
• Refactoring of existing code
• Preparing pull requests for review
• When coverage claims are made in a PR

Best practices

• Write the failing test before any production code; tests describe behavior, not implementation
• Implement only the minimum to make tests pass and commit immediately after green
• Refactor only when it adds value and ensure all tests remain green afterward
• Use conventional commit messages (feat:, fix:, refactor:, test:, docs:) to show TDD progression
• Always run coverage locally and verify Lines, Statements, Branches, and Functions are 100% or document an exception

Example use cases

• Add a new validation rule: write failing test, implement minimal logic, refactor validation, commit as test/feat/refactor
• Fix a bug: reproduce with a failing test, make the smallest change to pass, include test evidence in PR
• Large refactor across sessions: use per-session TDD, then document RED/GREEN/REFACTOR evidence in PR description
• Reviewing a PR that claims 100% coverage: check out the branch and run the coverage command to verify metrics
• Document a legitimate coverage exception in the package README and get explicit approval