Conciseness

The body is dense, rule-based prose with no padding and no explanations of concepts Claude already knows — it never explains what a test is or how frameworks work. Every clause carries a distinct directive, matching the "lean and efficient; every token earns its place" anchor rather than level 4, which would require trimmable over-explanation.

Actionability

Concrete decision rules with explicit conditions dominate: "Structure each test as Arrange, one Act, and Assert", "Mock direct external I/O boundaries; keep internal business logic and the boundary under test real", and "Verify against the project's real database engine... when the subject is a query, repository implementation, schema constraint, or migration compatibility". It falls short of level 5 only because no examples illustrate the rules; it is well above level 3 since the guidance is directly applicable rather than pseudocode-level.

Workflow Clarity

The sections follow a coherent select → design → mock → data-layer → verify → organize → regression flow, and several rules carry explicit sequencing and validation ("establish passing characterization evidence and rerun it after the change"; "Determine the required proof boundary... before minimizing tests"). It does not reach level 5 because there is no explicit stepwise workflow or error-recovery checklist, but the sequencing and validation rules present keep it above level 3.

Progressive Disclosure

The SKILL.md body keeps the language-agnostic core principles inline and splits specialized detail into two real, one-level-deep references (references/frontend.md and references/e2e.md, both verified to exist), each clearly signaled with a read condition ("read when writing, changing, or reviewing component, hook, or UI integration tests"). This matches the level 5 anchor: clear overview, well-signaled references, easy navigation.

Specificity

The description names the testing domain and a couple of concrete capabilities ("choosing which tests a change needs", "reviewing test quality") but stays at the "principles" abstraction level rather than listing several specific actions. It is above level 2 (more than bare domain naming) but below level 4 because the action coverage is not comprehensive and "proof ownership" is abstract jargon.

Completeness

Both parts are explicit: the "what" ("Language-agnostic testing principles for choosing which tests a change needs, test quality, and proof ownership, including frontend and browser E2E tests") and a concrete "Use when writing tests, deciding test scope, or reviewing test quality" trigger clause. The "when" is explicit and specific with concrete trigger phrases, matching the level 5 anchor rather than level 4 where the "when" would be weaker.

Trigger Term Quality

"writing tests", "deciding test scope", "reviewing test quality", and "frontend and browser E2E tests" are natural phrases users would say. It falls short of level 5 because common synonyms like "unit tests", "integration tests", or "test coverage" are missing, but is well above level 3 since multiple natural trigger phrases are present.

Distinctiveness Conflict Risk

The testing-principles niche (test selection, quality, proof ownership) with explicit triggers is mostly distinct from other skills. Minor overlap risk remains with general code-review skills via "reviewing test quality", keeping it below level 5 but clearly above level 3's broader overlap risk.