Build software with test-driven development and design discipline

Guides a strict red-green-refactor test-driven development workflow built on one core principle: tests should verify behavior through public interfaces, not implementation details, so code can change entirely while tests stay intact. Good tests are integration-style, exercising real code paths through public APIs and describing what the system does rather than how, reading like a specification ("user can checkout with valid cart") and surviving refactors because they don't depend on internal structure. Bad tests are coupled to implementation, mocking internal collaborators, testing private methods, or verifying through external means like querying a database directly instead of using the interface; the warning sign is a test that breaks on a refactor even though behavior hasn't changed, which means it was testing implementation rather than behavior.

It explicitly forbids the horizontal-slicing anti-pattern of writing all tests first and then all implementation, treating RED as "write all tests" and GREEN as "write all code." That approach produces tests that check imagined rather than actual behavior, ends up testing the shape of data structures and function signatures instead of user-facing behavior, becomes insensitive to real changes (passing when behavior breaks, failing when behavior is fine), and commits to test structure before the implementation is understood. The correct approach is vertical slices via tracer bullets, one test then one implementation, repeated, where each test responds to what was just learned from the previous cycle.

The workflow runs in four stages. Planning reads the project's CONTEXT.md if it exists so test names and interface vocabulary match the project's domain language, respects any ADRs in the touched area, and before writing code confirms with the user what interface changes are needed and which behaviors to test and prioritize, identifies opportunities for deep modules (a small interface over a deep implementation, using the /codebase-design skill for vocabulary and testability checks), lists the behaviors to test rather than implementation steps, and gets user approval on the plan, since not every behavior can be tested and effort should focus on critical paths and complex logic rather than every edge case. The tracer bullet stage writes one test confirming one thing about the system, RED (test fails) then GREEN (minimal code passes), proving the end-to-end path works. The incremental loop repeats that RED-then-GREEN cycle for each remaining behavior, one test at a time, writing only enough code to pass the current test, never anticipating future tests, and keeping tests focused on observable behavior. The refactor stage runs only after all tests pass, never while RED, looking for refactor candidates: extracting duplication, deepening modules by moving complexity behind simple interfaces, applying SOLID principles where they fit naturally, considering what the new code reveals about existing code, and running the tests again after each refactor step.

A fixed per-cycle checklist gates every test: it describes behavior rather than implementation, uses the public interface only, would survive an internal refactor, is paired with code that is minimal for that test, and adds no speculative features. Supporting reference material lives in tests.md for testing examples, mocking.md for mocking guidelines, and refactoring.md for refactor candidates.

Stated limitations: it requires whatever upstream tool, account, API key, or local setup the workflow names; it does not authorize destructive, production, paid, or external-message actions without explicit user approval; and generated artifacts or recommendations should be validated against the user's real sources before being treated as final.

Use it when building features or fixing bugs test-first, when the user mentions red-green-refactor, or wants integration-style tests. Skip destructive, production, paid, or external-message actions without the user's explicit approval, and skip refactoring while a test is still RED.

Input is a feature or bug-fix request plus the project's CONTEXT.md and any relevant ADRs. Output is a sequence of one-test-then-one-implementation cycles ending in passing tests and a refactored, deep-module implementation, gated by the per-cycle checklist.

Reads the project's own CONTEXT.md for domain vocabulary, can invoke the /codebase-design skill for deep-module and testability guidance, and references its own bundled tests.md, mocking.md, and refactoring.md files.

Developers and coding agents who want to build or fix code test-first through small, verifiable, behavior-focused cycles rather than writing all tests or all implementation in bulk.