Conciseness

The body avoids re-teaching basics and is mostly distilled, but the dependency-injection guidance is demonstrated twice (processPayment in Mocking, processOrder in Interface Design for Testability), and the 'characteristics of good tests' / 'red flags' bullet lists restate what the GOOD/BAD code comments already convey. Anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened') fits; anchor 4 would require only minor trims rather than this level of duplication.

Actionability

Concrete TypeScript examples, a runnable command ("bun typecheck"), explicit per-cycle checklists, and a complete RED/GREEN bug-fix walkthrough give mostly executable guidance. Not anchor 5 because examples reference undefined helpers (createCart, product, paymentMethod), so they are illustrative rather than copy-paste ready.

Workflow Clarity

Planning → Tracer Bullet → Incremental Loop → Refactor is clearly sequenced, with explicit validation checkpoints ("run test → confirm it FAILS correctly", "confirm it PASSES"), error-recovery guidance ("Test errors (not assertion failure)? Fix the error first"), a per-cycle checklist, and the "Never refactor while RED" guard. This matches anchor 5: explicit validation steps, feedback loops, and checklists.

Progressive Disclosure

The file has clear section headers and no nested-reference problem, but at ~320 lines with zero bundle files, specialized content sits inline — notably the ~60-line Type Testing section (Expect/Equal utilities, @ts-expect-error placement), which is a distinct advanced subtopic that belongs in a separate reference file. Anchor 3 ('content that should be separate is inline') fits; the good sectioning keeps it above anchor 2.

Specificity

Names the domain ("Test-driven development") and one concrete process ("red-green-refactor loop") but does not enumerate several specific actions like write-failing-test, minimal implementation, refactor. Fits anchor 3 ('names domain and 1-2 concrete actions, but not comprehensive') better than anchor 4, which expects a list of several specific actions.

Completeness

Explicitly answers what ("Test-driven development with red-green-refactor loop") and when ("Use when user wants to build features or fix bugs using TDD, mentions 'red-green-refactor', wants integration tests, or asks for test-first development") with concrete trigger phrases. This matches the anchor-5 example structure exactly; it is not anchor 4 because the 'when' clause is explicit and specific rather than merely serviceable.

Trigger Term Quality

Includes natural phrases users actually say — "using TDD", "mentions 'red-green-refactor'", "wants integration tests", "asks for test-first development" — giving good keyword coverage. A few natural variants (e.g. "write the tests first", "unit tests") are missing, so it falls short of anchor 5's comprehensive synonym coverage.

Distinctiveness Conflict Risk

The TDD niche is clear with distinct triggers ("red-green-refactor", "test-first"), but the trigger "wants integration tests" could fire on general testing requests that do not intend TDD, creating minor overlap with generic testing skills. Mostly distinct with minor overlap risk — anchor 4 — rather than the minimal-conflict anchor 5.