Conciseness

The body is dense and efficient with no explanation of concepts Claude already knows, and nearly every line states a non-obvious rule. A few sentences carry motivational rationale ("a brittle, duplicated, or implementation-shaped test therefore becomes a false requirement: it gets worked around") or pack multiple clauses into one bullet (the proof-boundary bullet), which could be trimmed or split, keeping it below the lean-every-token-earns-its-place level.

Actionability

Most rules are concrete, directive, and executable as written — "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", "Add a regression test for every reproducible behavior bug fix". A few abstract principles ("proof ownership", "keeps at most one representative case of a rule owned elsewhere") require interpretation without a worked example, which is the minor gap that keeps it from fully actionable coverage.

Workflow Clarity

The content is clearly organized by concern in a logical order (selection, design, mocks, data layer, verification, organization, regression), and the Test Selection section embeds a usable decision order (outcome → required proof boundary → harness choice). As a principles skill with no destructive or batch operations it needs no validation checkpoints, but some procedural guidance is embedded in long dense prose rather than an unambiguous sequence, so it sits just below the top anchor.

Progressive Disclosure

The 59-line body is a concise overview appropriately split into two real, one-level-deep bundle files, and the References section signals each with an explicit when-to-read condition: "references/frontend.md: read when writing, changing, or reviewing component, hook, or UI integration tests" and "references/e2e.md: read when writing, changing, or reviewing browser E2E tests". Both files exist, contain no nested references, and navigation is easy — a clear match for the top anchor.

Specificity

The description enumerates several specific capabilities — "choosing which tests a change needs, test quality, and proof ownership, including frontend and browser E2E tests" — which goes beyond naming the domain. It falls short of 5 because the capabilities are principle areas phrased somewhat abstractly rather than a comprehensive list of concrete actions.

Completeness

It explicitly answers both parts: what it provides ("Language-agnostic testing principles for choosing which tests a change needs, test quality, and proof ownership") and when to use it, via a concrete "Use when writing tests, deciding test scope, or reviewing test quality" trigger clause. Both are explicit with concrete trigger phrases, matching the top anchor.

Trigger Term Quality

"Use when writing tests, deciding test scope, or reviewing test quality" plus "frontend and browser E2E tests" provides good natural-keyword coverage users would actually say. It misses common variations like "unit tests" or "test coverage", keeping it below the comprehensive-synonym level of 5.

Distinctiveness Conflict Risk

The niche — test selection, scope decisions, and proof ownership doctrine — is mostly distinct with a clear position, and triggers like "deciding test scope" are specific. The broad trigger "writing tests" carries minor overlap risk with framework-specific testing skills, so it does not reach the minimal-conflict level of 5.