tdd: drop the refactor stage — red → green, not red → green → refactor

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) <noreply@anthropic.com>

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.