Conciseness

The body is dense, imperative rule-setting with almost no tutorial padding ("Write exactly ONE failing test. Run it. Confirm it fails with the expected error. Do NOT write implementation code."). Not 5 because the `Skill('code-quality')` routing rationale is explained three times (Step 2 REFACTOR, GREEN phase, Code Quality section) and could be consolidated; not 3 because nothing explains concepts Claude doesn't need explained.

Actionability

Guidance is copy-paste executable: exact glob patterns ("**/*.test.*", "**/*.spec.*"), runner discovery sources (package.json, Makefile, pyproject.toml...), a concrete naming example ("describe('createOrder')" → "it('should reject order when inventory is zero')"), factory pattern (`buildUser(overrides?)`), and a 3-mock design rule. Per the rubric's instruction-skill note, absence of code isn't penalized when guidance is this actionable — and it covers the common cases.

Workflow Clarity

Steps 0–4 are clearly sequenced with explicit validation checkpoints at every phase: RED ("Confirm it fails with the expected error"), GREEN ("Run the full relevant test suite to check for regressions"), completion ("stop and fix it before proceeding. Never accumulate broken tests"), plus a "When Things Go Wrong" section that gives error-recovery feedback loops and a 2-failed-attempts restart rule. This matches the strongest anchor's validate→fix→retry pattern.

Progressive Disclosure

The overview is well structured and phase details are split into clearly signaled one-level references ("See `rules/red.md`", "See `rules/green.md`", "See `rules/refactor.md`", "See `rules/test-after.md`"). Not 5 because no bundle directories (references/, scripts/, assets/, or rules/) are present, so the referenced rule files are dangling and navigation cannot be confirmed against the actual bundle; not 3 because the references that exist in the text are clearly signaled and content placement is appropriate.

Specificity

Quotes like "Writes one failing test at a time, implements minimal code to pass, then refactors", "Delegates to the `test-provenance-guard` skill during REFACTOR to detect tests-by-construction (static + mutation checks)", and "cites refactor recipes (R1–R20) by ID" list multiple specific concrete actions with comprehensive coverage of the TDD workflow. Not 4 because coverage is thorough — the delegation and pairing behaviors are stated as concrete actions, not left as minor gaps.

Completeness

Both questions are answered explicitly: what — "Enforces strict Test-Driven Development with RED-GREEN-REFACTOR cycles... implements minimal code to pass, then refactors"; when — "Triggers on: 'tdd', 'write tests', 'test this', 'add test coverage', 'test driven', 'red green refactor', '/tdd'". The explicit trigger list meets the strongest anchor; no cap applies since trigger guidance is present.

Trigger Term Quality

"tdd", "write tests", "test this", "add test coverage", "test driven", "red green refactor", "/tdd" give good natural-phrase coverage. Not 5 because common synonyms like "unit tests", "test suite", or "testing" are missing; not 3 because the listed phrases are exactly what users naturally say and include slash-command form.

Distinctiveness Conflict Risk

"tdd", "test driven", "red green refactor" carve a clear niche distinct from generic testing skills, but "write tests" and "test this" could plausibly trigger for a general test-writing or coverage skill — minor overlap risk. Not 5 because of that broad-phrase overlap; not 3 because the core triggers are unmistakably TDD-specific.