Conciseness

The Philosophy section spends three paragraphs explaining concepts Claude already knows (good vs. bad tests, mocking internal collaborators, tests breaking on refactor), and the Anti-Pattern section is similarly discursive ('You outrun your headlights'). This is 'mostly efficient but includes some unnecessary explanation' rather than anchor 4 — the Philosophy section alone could be trimmed to a few directive bullets without losing guidance value.

Actionability

As an instruction-only skill the guidance is concrete and directive: 'Write ONE test that confirms ONE thing', 'Only enough code to pass current test', 'Never refactor while RED', a specific question to ask the user ('What should the public interface look like?'), and a worked behavior-naming example ('user can checkout with valid cart'). Not score 5 because no example test or RED/GREEN cycle in a real framework is shown and the referenced example files (tests.md) do not exist, leaving minor gaps.

Workflow Clarity

The four-step workflow (Planning → Tracer Bullet → Incremental Loop → Refactor) is clearly sequenced with three checklists and explicit cycle validation ('test fails' → 'test passes', 'Run tests after each refactor step'). Not score 5 because there are no error-recovery branches — e.g. what to do when a new test unexpectedly passes, when implementation reveals the plan was wrong, or when to abandon a cycle — so feedback loops exist but only on the happy path.

Progressive Disclosure

The body is well-sectioned and its inline references (tests.md, mocking.md, deep-modules.md, interface-design.md, refactoring.md) are clearly signaled and one level deep, which is better organized than anchor 2. However, none of the five referenced files exist in the bundle (no references/, scripts/, or assets/ directories), so navigation leads nowhere and the promised detail content is simply missing — a real organizational defect that keeps it below anchor 4.

Specificity

The 'what' is stated at a process level ('Test-driven development with red-green-refactor loop') with implied actions ('build features or fix bugs'), which is comparable to 'names domain and 1-2 concrete actions, but not comprehensive'. Not score 4 because it never enumerates the concrete operations the way 'extracts text, fills forms, converts pages' does; not score 2 because 'red-green-refactor loop' is more concrete than a bare domain name like 'Processes PDF files'.

Completeness

Explicitly answers both: 'what' — 'Test-driven development with red-green-refactor loop', and 'when' — a full 'Use when...' clause with multiple concrete trigger phrases (build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, asks for test-first development). Matches the anchor-5 example structure; anchor 4's 'when could be more explicit' does not apply since the when-clause lists four specific triggers.

Trigger Term Quality

Strong natural keyword coverage: 'TDD', 'red-green-refactor', 'integration tests', 'test-first development', 'build features', 'fix bugs' — phrases a user would plausibly say. Not score 5 because common variations like 'unit tests', 'write the tests first', or 'test coverage' are absent, so coverage is good but not comprehensive.

Distinctiveness Conflict Risk

TDD/red-green-refactor is a clear niche with distinct triggers, so conflict risk with unrelated skills is low. Not score 5 because 'wants integration tests' and the broad 'build features or fix bugs' phrasing create minor overlap with general testing and coding skills despite the 'using TDD' qualifier.