From 80e9dcc6857f16cc08b8e5b190393ee7591517e0 Mon Sep 17 00:00:00 2001 From: Matt Pocock Date: Tue, 30 Jun 2026 09:48:57 +0100 Subject: [PATCH] =?UTF-8?q?tdd:=20drop=20the=20refactor=20stage=20?= =?UTF-8?q?=E2=80=94=20red=20=E2=86=92=20green,=20not=20red=20=E2=86=92=20?= =?UTF-8?q?green=20=E2=86=92=20refactor?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Refactoring belongs to the review stage, not the implementation loop. Remove the refactor rule and the now-orphaned refactoring.md (its home is the review skill), and point the loop's rule at the review skill so it isn't re-added. Co-Authored-By: Claude Opus 4.8 (1M context) --- .changeset/tdd-reference-only-seams.md | 2 ++ skills/engineering/tdd/SKILL.md | 4 ++-- skills/engineering/tdd/refactoring.md | 10 ---------- 3 files changed, 4 insertions(+), 12 deletions(-) delete mode 100644 skills/engineering/tdd/refactoring.md diff --git a/.changeset/tdd-reference-only-seams.md b/.changeset/tdd-reference-only-seams.md index f29550d..6696d46 100644 --- a/.changeset/tdd-reference-only-seams.md +++ b/.changeset/tdd-reference-only-seams.md @@ -3,3 +3,5 @@ --- Reshape the `tdd` skill into reference-only. The red → green → refactor loop is anchored by leading words the model already holds, so the step-by-step Workflow was largely restating the loop and duplicating the horizontal-slicing anti-pattern. Dropped the Workflow and per-cycle checklist; folded their one durable idea — vertical slices / tracer bullets — into the Anti-patterns section and a short Rules-of-the-loop list. Introduced **seam** as the leading word for where tests go, collapsing the old Philosophy "public interfaces" prose and the Planning "confirm interface / behaviors" handshake into one rule: test only at pre-agreed seams, confirmed with the user before any test is written. + +Also dropped the refactor stage — TDD is now red → green, not red → green → refactor. Refactoring belongs to the review stage, not the implementation loop, so the refactor rule and `refactoring.md` were removed (its home is the `review` skill). diff --git a/skills/engineering/tdd/SKILL.md b/skills/engineering/tdd/SKILL.md index 6bd9fb6..4e243fb 100644 --- a/skills/engineering/tdd/SKILL.md +++ b/skills/engineering/tdd/SKILL.md @@ -5,7 +5,7 @@ description: Test-driven development. Use when the user wants to build features # Test-Driven Development -TDD is the red → green → refactor loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after. +TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after. When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching. @@ -33,4 +33,4 @@ Ask: "What's the public interface, and which seams should we test?" - **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features. - **One slice at a time.** One seam, one test, one minimal implementation per cycle. -- **Never refactor while red.** Get to green first, then look for [refactor candidates](refactoring.md) — including deepening modules (small interface, deep implementation; see `/codebase-design`). Run the tests after each refactor step. +- **Refactoring is not part of the loop.** It belongs to the review stage (see the `review` skill), not the red → green implementation cycle. diff --git a/skills/engineering/tdd/refactoring.md b/skills/engineering/tdd/refactoring.md deleted file mode 100644 index 8a44439..0000000 --- a/skills/engineering/tdd/refactoring.md +++ /dev/null @@ -1,10 +0,0 @@ -# Refactor Candidates - -After TDD cycle, look for: - -- **Duplication** → Extract function/class -- **Long methods** → Break into private helpers (keep tests on public interface) -- **Shallow modules** → Combine or deepen -- **Feature envy** → Move logic to where data lives -- **Primitive obsession** → Introduce value objects -- **Existing code** the new code reveals as problematic