tdd-red-green-refactor

name	tdd-red-green-refactor
description	Enforce strict TDD loops (RED->GREEN->REFACTOR) for behavior-changing work. Use when implementing features, bug fixes, or refactors that alter observable behavior and require non-sloppy verification.

TDD Red-Green-Refactor

Prevent speculative coding and fake confidence by enforcing behavior-first development loops. 1. Select one scenario and one behavior slice. 2. RED: write a failing test first. 3. GREEN: implement the minimal code to pass that test. 4. REFACTOR: improve design while keeping tests green. 5. Repeat until all scenarios are covered. 6. Run full verification suite before handoff. - Keep each cycle small and atomic. - Name tests by behavior, not implementation. - Add invariant checks in tests for domain-critical logic. - Do not write production code before a failing test. - Do not keep passing tests that prove nothing meaningful. - Do not batch many behaviors into one giant test. | Symptom | Cause | Fix | |---|---|---| | "No obvious test to write" | Behavior not well specified | Return to Gherkin scenario design | | Test passes immediately | Existing behavior already present or test too weak | Strengthen assertion or pick missing behavior | | Frequent regressions after refactor | Refactor changed behavior silently | Add characterization tests before refactor |