Conciseness

The body is dense and earns most of its tokens: before/after code, an anti-pattern catalog with WHY/BAD/GOOD, and copy-paste ripgrep commands, with no explaining of basics Claude already knows. It is not 5 because of repetition: "If code is hard to test, it's a design problem, not a testing problem" appears in both Philosophy and the 'Tests Are Architecture' section, and Step 5's checklist ('Entities are unit tested (pure logic, no dependencies)') restates the Layer Isolation section; it is well above 3 because the padding is limited to these few duplicated statements.

Actionability

Concrete, near-executable guidance throughout: TypeScript before/after DI examples, a Humble Object pair, stub/mock/fake implementations, and runnable commands like `rg -n "new [A-Z].*Repository\(|..." src`. It is not 5 because several examples have placeholder bodies ('// Logic using this.repo', '// Business logic here') and the StubOrderRepository implements only findById against an interface that also requires save, so they are not fully copy-paste ready; it clearly exceeds 3 since the code is real (not pseudocode) with only minor gaps.

Workflow Clarity

The five-step workflow (identify blockers → apply DI → isolate side effects → design test doubles → verify boundary tests) is clearly sequenced, each step declares an explicit **Output**, and Step 5 is a verification checklist. It is not 5 because there is no feedback loop for error recovery (no guidance on what to do when a Step 5 check fails or a blocker can't be refactored); this is not a destructive/batch skill, so the validation cap does not apply, and the explicit per-step outputs place it above the 3 anchor.

Progressive Disclosure

SKILL.md serves as the overview (philosophy, principles, workflow, anti-patterns) and pushes deeper material into four real, one-level-deep files, all verified to exist with substantive content, clearly signaled in a References table that includes a 'When to Use' navigation column. This matches the 5 anchor's clear overview with well-signaled one-level-deep references and easy navigation; nothing inlined clearly belongs in a separate file.

Specificity

The description names the domain and several concrete techniques: "boundary isolation, dependency injection, and testable architecture patterns". It falls below the 5 anchor because there is a single primary action ("Design code for testability") with the techniques as modifiers, rather than the multiple distinct concrete actions the 5 anchor requires (e.g., extract/fill/merge/convert); it is above the 3 anchor because more than 1-2 specific approaches are explicitly named.

Completeness

Both halves are explicit: what it does ("Design code for testability using boundary isolation, dependency injection, and testable architecture patterns") and when to use it ("Use when designing test strategies, writing unit tests, ... or applying TDD practices") with concrete trigger phrases. This mirrors the 5 anchor's structure exactly; the 'when' clause is present and enumerates six concrete triggers, so it is not the 4 anchor's case of a 'when' that could be more specific.

Trigger Term Quality

Natural phrases a user would say are comprehensively covered, including synonyms: "writing unit tests", "improving test coverage", "refactoring untestable or hard-to-test code", "mocking", "test doubles", and "TDD practices". It matches the 5 anchor's bar of natural terms plus synonyms ("untestable or hard-to-test code", "mocking or test doubles"); file extensions are not applicable to this design skill.

Distinctiveness Conflict Risk

The core niche (designing code for testability via DI and boundary isolation) is clearly distinct, and most triggers ("test coverage", "hard-to-test code", "mocking", "test doubles") point at this niche. It is not 5 because triggers like "writing unit tests" and "applying TDD practices" are broad phrases that closely related skills (e.g., a test-driven-development skill) would also claim; it is not 3 because the description is far more specific than a generic domain statement and the overlap is confined to closely related skills.