mutation-test-runner
Skill0 starsChanged 39 days agoMITView on GitHub
Runs mutation testing on already-covered code and turns each surviving mutant into a specific missing assertion, exposing tests that execute code but verify nothing. Use when line coverage is high yet a bug slipped through, when reviewing a critical module (pricing, permissions, auth, state machines) before release, or when you are asked to run Stryker, PIT, mutmut, or cosmic-ray. Do NOT use when the goal is to find which code paths are untested at all - use coverage-gap-finder instead.
In this repository8 other files it gives its agents.
- contract-test-writerSkill
- coverage-gap-finderSkill
- e2e-scenario-authorSkill
- flaky-test-detanglerSkill
- mock-stub-designerSkill
- playwright-testingSkill
- tdd-expertSkill
- test-data-builderSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Run scoped, not global. In CI, mutate only changed files (Stryker incremental / diff mode).
- Distinctive: line 16
Read each surviving mutant as a named missing assertion, not a vague gap:
- Distinctive: line 26
Every reported survivor maps to one concrete, named assertion a developer can write - no "add more tests."
- Distinctive: line 33
Do NOT block every PR on a full-repo mutation run - it reruns the suite per mutant and will stall the pipeline.
- Distinctive: line 34
Do NOT chase a 100% mutation score.
- Distinctive: line 35
Do NOT run mutation testing on generated code, DTOs, or glue - spend the compute where a silent failure hurts.
- Distinctive: line 36
Do NOT use a single global threshold.
- Distinctive: line 37
Do NOT treat mutation testing as a substitute for deciding what to test.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Mutation Test Runner
Prove whether covered code is actually verified: deliberately break a line, and check that a test notices. A surviving mutant is proof that the line is executed but unasserted.
Workflow
- Pick the target. Scope to high-risk logic where a silent bug is expensive - pricing, permissions, auth, state machines, financial math. Skip generated code, trivial DTOs, and glue; they have nothing worth mutating.
- Pick the runner: Stryker (JS/TS/C#), PIT (JVM), mutmut or cosmic-ray (Python). Configure it to run against the target's existing test suite.
- Run scoped, not global. In CI, mutate only changed files (Stryker incremental / diff mode); reserve a full sweep for a nightly job. Enable coverage analysis so only tests touching a mutated line rerun, and parallelize across cores.
- Read each surviving mutant as a named missing assertion, not a vague gap:
<mutated to<=survives -> the boundary case is unasserted; add an assertion at the exact edge value.- A removed function call survives -> no test checks that side effect; assert the side effect.
- A negated condition survives -> the two branches are indistinguishable to the suite; assert the differing outcome of each branch.
- A return value replaced with a constant survives -> the return is unchecked; assert it.
- Triage equivalent mutants. Some mutants cannot change observable behavior (a change in dead code,
i++vs++iin isolation). Distinguishing them is undecidable in general - mark them ignored in the tool's config rather than chasing 100%. - Set a meaningful floor on the targeted modules only (e.g. 70-80% mutation score), where score = killed / (total non-equivalent mutants). Never set one global threshold.
Quality bar
- Every reported survivor maps to one concrete, named assertion a developer can write - no "add more tests."
- Mutation runs are scoped (diff/incremental in CI, full sweep nightly); no PR blocks on a full-repo run.
- Equivalent mutants are explicitly ignored, not silently inflating or deflating the score.
- The score is presented as a quality signal for already-covered code, never as a coverage substitute.
Do NOT
- Do NOT block every PR on a full-repo mutation run - it reruns the suite per mutant and will stall the pipeline.
- Do NOT chase a 100% mutation score; equivalent mutants make it unreachable and the marginal mutants are noise.
- Do NOT run mutation testing on generated code, DTOs, or glue - spend the compute where a silent failure hurts.
- Do NOT use a single global threshold; floors belong on critical modules.
- Do NOT treat mutation testing as a substitute for deciding what to test. It measures assertion strength on existing code; a missing feature has no code to mutate. To find untested paths and inputs, use coverage-gap-finder.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

