mutation-testing
Skill1 starsChanged 4 days agoMITView on GitHub
Check whether the tests actually catch bugs by mutating the code and seeing if the tests fail. Use after a slice passes its tests, before calling it done, and whenever a test suite looks green but unproven. JavaScript/TypeScript only. Only invoke via the orcinus router.
30 other projects use a version of this.
Adopted by
Most recently taken up by
- camunda/camundatheir own version, first seen Nov 8, 2026
- Integralist/agent-skillstheir own version, first seen Nov 1, 2026
- shangyiy/life-kittheir own version, first seen Nov 1, 2026
- Hakkadaikon/hymmetheir own version, first seen Oct 26, 2026
- proffesor-for-testing/agentic-qetheir own version, first seen Oct 25, 2026
- conjurer-rich/skillstheir own version, first seen Oct 25, 2026
Used with
Projects with it also use domain-modeling, code-review and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
GoogleSkilldomain-modeling
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
Also in 3 projects that use this
GoogleSkillcode-review
Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.
Also in 5 projects that use this
MicrosoftSkillgrill-with-docs
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Also in 3 projects that use this
Other versions30 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 30
- metabase/metabase★ 50ksame name
- recharts/recharts★ 28ksame name
- camunda/camunda★ 4.4ksame name
- ThibautBaissac/rails_ai_agents★ 665same name
- proffesor-for-testing/agentic-qe★ 524same name
- s3s-project/s3s★ 315same name
- jvm-skills/jvm-skills★ 140same name
- Amplicode/spring-skills★ 126same name
- GGGODLIN/gggodlin-cc-harness★ 73same name
- Integralist/agent-skills★ 23same name
20 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository35 other files it gives its agents.
- accessibilitySkill
- api-and-interface-designSkill
- architectureSkill
- ask-questions-if-underspecifiedSkill
- breaking-changeSkill
- buildSkill
- codebase-knowledge-builderSkill
- database-designerSkill
- diagnosing-bugsSkill
- finalizeSkill
- frontend-architectureSkill
- frontend-data-contractsSkill
- frontend-optimistic-mutationsSkill
- handoffSkill
- i18nSkill
- idea-calibrateSkill
- idea-captureSkill
- incomplete-refactorSkill
- independent-reviewSkill
- issue-triageSkill
- mcp-builderSkill
- monitoring-observabilitySkill
- monitoringSkill
- mutation-testing-pythonSkill
- orcinusSkill
- orcinus-verifySkill
- performance-optimizationSkill
- refactorSkill
- registry-publishSkill
- scaffoldSkill
- security-reviewSkill
- skill-creatorSkill
- visual-regressionSkill
- wazaSkill
- webapp-testingSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 27 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Never weaken a test to raise the score.
- Distinctive: line 17
Never report a score without running.
- Distinctive: line 25
Run the four commands. Record their outputs.
- Distinctive: line 29
Use Stryker (stryker-mutator/stryker-js, Apache-2.0) as-is.
- Very specific: line 33
Add a mutation script to package.json (for example "mutation": "stryker run").
- Distinctive: line 34
Run it. Record the full output.
“Common” is measured: kept by at least 6 in 10 of the 27 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
MUTATION-TESTING — do the tests catch anything?
A green test suite proves nothing on its own. A test that passes no matter what the code does is not a test. Mutation testing proves the tests: change the code in small ways (mutants) and check whether the tests fail. A mutant the tests kill is proof the tests work. A mutant that survives is a gap in the tests — record it, do not hide it.
Rules
- Baseline first. Run the four commands (build, lint, typecheck, test) before mutating. If they are not green, stop — mutation testing on a broken suite measures nothing.
- Never weaken a test to raise the score. A surviving mutant is fixed by adding or strengthening a test, never by deleting the mutant or the test.
- Never report a score without running. A score from memory, from another project, or from a failed run is not a score.
- A surviving mutant is a finding, not a failure to hide. List every one, with file and line.
- A check that did not run is never reported as passed.
Steps, in order
1. Baseline
Run the four commands. Record their outputs. All must exit 0 and all tests must pass. If not, stop.
2. Run Stryker as-is
Use Stryker (stryker-mutator/stryker-js, Apache-2.0) as-is. Do not rewrite it, and do not hand-roll mutants when Stryker can generate them.
- Install:
@stryker-mutator/coreand@stryker-mutator/typescript-checkeras dev dependencies. - Configure (
stryker.config.mjs): mutatesrc/**/*.ts; use thecommandtest runner with the project's own test command (for examplenpm test) when the project usesnode:test, which Stryker has no dedicated runner for; use thetypescriptchecker so mutants that do not compile are reported as compile errors, not as killed. - Add a
mutationscript topackage.json(for example"mutation": "stryker run"). - Run it. Record the full output.
3. Read the score
Record the exact numbers: total mutants, killed, survived, timed out, no coverage, compile errors, and the mutation score. The score is killed divided by (total minus no coverage minus compile errors) — record Stryker's own score, do not recompute it by hand.
Rounding is outside the mutator set: Stryker generates no mutant for Math.round at all — in the demo, the line-16 mutants are only ArithmeticOperator swaps — so even a break threshold of 80 would not have caught a Math.round → Math.floor swap, and a 100.00 score does not cover that class. The boundary test (a non-divisible case) is the only closure for it; record it alongside the score.
4. Prove the check can fail
The report must name at least one mutant the tests killed, with file, line, and what changed. If no mutant was killed, the check proved nothing — say so, and do not call the suite tested.
5. List every surviving mutant
For each surviving mutant, record file, line, the change, and what test is missing. Each one is a test gap. Fix the gaps by adding tests (one slice at a time, test first), then re-run Stryker and record the new score. Do not delete code to make a mutant disappear, and do not mark a mutant as ignored without writing down why.
Report
Return the report in this form:
- Baseline (four commands, with outputs).
- Stryker version and config (mutate pattern, test runner, checker).
- Mutation score with the exact numbers.
- Killed mutants (at least one, with file and line).
- Surviving mutants (every one, with file, line, and the missing test).
- Verdict: PASS (score recorded and at or above the configured break threshold, at least one mutant killed, all survivors listed; a passing score does not cover rounding — see Step 3) or FAIL (Stryker did not run, no mutant killed, survivors hidden, or score below the break threshold).
Scope
Python is covered by the companion skill mutation-testing-python (mutmut as-is, BSD-3-Clause). Other languages are still a gap — each needs its own verified CLI. The Trail of Bits mutation-testing skill (CC-BY-SA-4.0) is a separate licensed module, not copied here; it is referenced, not used, for non-JS/TS work.
Sources
Method, in our own words, using Stryker (stryker-mutator/stryker-js, Apache-2.0, licence verified from the primary LICENSE file) as-is. No text was copied from Stryker. Trail of Bits mutation-testing is referenced, not copied (CC-BY-SA-4.0).
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.

