Conciseness

The body is lean overall — a Quick Reference of four dense bullets and four short section stubs — but the opening paragraph over-explains motivation Claude already knows ('A codebase can have 90% line coverage and still ship critical bugs... the standard that actually matters in production'). This fits 'Efficient; minor instances of over-explanation that could be trimmed'. Not 5 because that intro is pure motivational padding; not 3 because the padding is confined to one short paragraph.

Actionability

Some concrete guidance exists — 'Stryker' is named, 'Aim for 80%+ mutation score' and 'Run Stryker on a focused scope (one module)' are specific heuristics — but there are no commands, configuration, or code anywhere in the body ('Set up Stryker for this module, run an initial mutation report' gives no executable steps). This matches 'Some concrete guidance but incomplete; missing key details'. Not 4 because nothing in the body is executable without opening references/rule.md.

Workflow Clarity

The Check → Fix structure supplies a rough sequence ('Set up Stryker... run an initial mutation report... improve tests to kill surviving mutants') and the 80% threshold acts as an implicit checkpoint, but steps are unnumbered, vague ('improve tests' — how?), and there are no validation or feedback-loop steps. This fits 'Steps listed but validation gaps; sequence present but checkpoints missing or implicit'. Not 4 because no explicit validation checkpoint exists.

Progressive Disclosure

The bundle structure is sound: the body is a short overview and implementation detail is correctly split into the real, one-level-deep 'references/rule.md', clearly signaled ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'). Not 5 because the pointer sits in a generic footer rather than being tied to the relevant sections (e.g., linking Fix and Code Review to the Stryker setup details), and the external rule URL is duplicated in both frontmatter and body.

Specificity

The description names the domain ('evaluating test quality') and one concrete action ('determine whether the tests provide genuine defect detection'), but names no method or tool — 'mutation testing', 'mutation score', or 'Stryker' never appear. It matches the anchor 'Names domain and 1-2 concrete actions, but not comprehensive'. Score 4 would require several specific actions; the single embedded action falls short of that.

Completeness

Both parts are present: an explicit trigger clause ('Use when evaluating test quality on modules containing business logic, calculation utilities, or state machines') and a 'what' ('determine whether the tests provide genuine defect detection'). Not 5 because the 'what' omits the actual technique (mutation testing) and reads more like a purpose than a capability list; not 3 because 'when' is explicit and specific.

Trigger Term Quality

Relevant natural terms are present ('test quality', 'business logic', 'tests', 'defect detection', 'state machines'), but the most common user phrasings — 'mutation testing', 'mutation score', 'Stryker', 'test coverage' — are absent, so a user asking to 'run mutation testing' would not naturally match. This fits 'Some relevant keywords but missing common variations or synonyms'.

Distinctiveness Conflict Risk

The trigger scope (modules with 'business logic, calculation utilities, or state machines') and focus on genuine defect detection make it fairly distinct, with only minor overlap risk against closely related testing skills (e.g., a generic unit-testing or coverage-review skill). It does not meet anchor 5's 'clear niche with distinct triggers' because the absence of the term 'mutation testing' weakens its distinct trigger identity.