Build software with test-driven development and design discipline

A test-driven-development discipline, sourced from mattpocock/skills (MIT), built on the core principle that tests should verify behavior through public interfaces, not implementation details - code can change entirely, tests shouldn't. Good tests are integration-style, exercising real code paths through public APIs and reading like a specification such as "user can checkout with valid cart"; bad tests are coupled to implementation, mocking internal collaborators or querying a database directly instead of the interface, and break on refactors even when behavior hasn't changed. It names and forbids a specific anti-pattern, "horizontal slicing": writing all tests first (RED) then all implementation (GREEN), because bulk-written tests test imagined rather than actual behavior, become insensitive to real regressions, and commit to test structure before the implementation is understood. The correct approach is vertical slices via tracer bullets - one test, then one implementation, repeating, so each test responds to what was just learned:

WRONG (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3

Its four-phase workflow is planning - read CONTEXT.md and relevant ADRs, confirm interface changes and which behaviors to test with the user, identify deep-module opportunities via a separate /codebase-design skill, list behaviors rather than implementation steps, and get explicit user approval since "you can't test everything" - a tracer-bullet first test proving the path works end-to-end, an incremental RED-GREEN loop writing one test at a time with only enough code to pass it and no anticipation of future tests, and a refactor phase after all tests pass that extracts duplication, deepens modules, and applies SOLID principles where natural, with an explicit rule to never refactor while RED, only after reaching GREEN. It closes each cycle against a five-item checklist confirming the test describes behavior not implementation, uses only the public interface, would survive an internal refactor, and that the code written is minimal with no speculative features.

Use when writing new functionality test-first, or when a workflow calls for a disciplined red-green-refactor cycle rather than bulk test writing followed by bulk implementation. It defers deeper examples to companion references tests.md, mocking.md, and refactoring.md, and to a separate /codebase-design skill for deep-module vocabulary and testability checks.

Input is a feature or behavior to implement test-first, plus the project's CONTEXT.md and relevant ADRs for domain vocabulary. Output is a sequence of RED-then-GREEN test/implementation pairs, followed by a refactor pass, each cycle checked against the five-item behavior-focused checklist.

References companion docs tests.md, mocking.md, and refactoring.md for detailed examples and mocking guidelines, and hands off to a separate /codebase-design skill for identifying deep-module opportunities before testing begins.

Engineers and coding agents implementing new behavior who need a disciplined one-test-at-a-time TDD loop instead of writing all tests up front against imagined behavior.