Conciseness

Mostly efficient with concrete tables and commands, but there is avoidable redundancy: the overview blockquote ("Stryker started as a pure JavaScript mutation testing framework... supports most JavaScript projects") is repeated nearly verbatim by "supported runners include Jest, Mocha, Karma, Vitest, Jasmine, Cucumber, Tap", and the survived-mutant explanation is stated twice (Overview and Step 3). There is also a garbled sentence — "A green suite with high mutation-survival rate** is the bug coverage hides" — that adds tokens without meaning.

Actionability

Largely copy-paste ready: exact `npm install` packages, complete `stryker.conf.json`, `npx stryker init/run/--incremental`, and a CI snippet. Not score 5 because of minor executable gaps: the full-run CI job's condition `github.event.schedule == '0 2 * * 0'` only evaluates on schedule events (so a push-to-main trigger would never fire it), and the artifact path `reports/mutation/` doesn't match the HTML reporter's default output location (`reports/mutation/html`).

Workflow Clarity

Steps 1–6 are clearly sequenced (Install → Initialize → Run → Report → Incremental → CI), but there are no explicit validation checkpoints for what is a heavy batch operation: no guidance to verify the config, dry-run a small mutate glob on one file before a 30-minute run, or confirm the break threshold before gating PRs. The rubric caps workflow clarity at 3 for batch operations lacking validation steps, which applies here despite the clear sequence.

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/ directories), and the single-file body is well-sectioned with appropriate inline placement for its ~176 lines. Score 4 rather than 5 because the References section has minor organization defects: a dangling broken entry ("`stryker-net-mutation` - " with an empty dash), and sibling-skill references (pitest, mutmut, mull) are listed without links or paths, so they don't function as signaled references.

Specificity

The description lists multiple concrete actions — "picks the test-runner plugin", "authors `stryker.conf.json` with mutate globs + thresholds", "runs incremental mode for PRs (only mutate changed files)", "reports the mutation score" — with named packages. This matches the anchor for multiple specific concrete actions; not score 4 because coverage of the skill's actions is comprehensive rather than having minor gaps.

Completeness

Both what and when are explicitly stated: the what is the enumerated concrete actions, and the when is "Use when a JS/TS test suite has ≥80% line coverage and the team wants to verify the tests actually catch bugs (not just touch lines)" — a concrete trigger condition. Clear match to the top anchor.

Trigger Term Quality

Strong natural terms: "mutation testing", "StrykerJS", framework names (React/Vue/Svelte), runner names (jest/vitest/mocha/karma), "PR", "line coverage", "mutation score". Not score 5 because a few natural user phrasings (e.g. "weak tests", "test quality", "assertions don't catch anything") are absent, though "verify the tests actually catch bugs" partially covers this.

Distinctiveness Conflict Risk

The StrykerJS name, specific plugin package names, and the ≥80% coverage precondition give it a clear niche distinct from generic coverage or testing skills. Minor theoretical overlap with general JS testing skills, but the explicit mutation-testing framing makes conflict risk minimal.