mutate
Skill2 starsChanged 4 months agoMITView on GitHub
MutantX — AI-powered mutation testing. Detects project setup, generates realistic code mutants, tests them, and reports gaps in test coverage.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- synaptiai/agent-capability-standardtheir own version, first seen Nov 1, 2026
- OHOKAYYEAH/claude-skillstheir own version, first seen Oct 13, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- synaptiai/agent-capability-standard★ 6same name
- OHOKAYYEAH/claude-skills★ 1same name
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 repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- mx-detectSkill
- mx-generateSkill
- mx-reportSkill
- mx-testSkill
- mx-validateSkill
- mutateSkill
- mx-detectSkill
- mx-generateSkill
- mx-reportSkill
- mx-testSkill
- mx-validateSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 4 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 32
Follow the instructions in /mx-detect.
- Very specific: line 34
If arguments files or test-cmd are provided, pass them through.
- Very specific: line 36
Write the detection results to .mutants/detect.json and display them to the user.
- Distinctive: line 46
Use per-file caching: only regenerate mutants for files whose content hash has changed since the last run.
- Very specific: line 58
Alternative: run mx-validate.py --promote to trust the patches and skip AI review.
- Distinctive: line 72
Check these locations in order:
- Very specific: line 88
Check same locations as mx-test.py.
- Very specific: line 92
Follow the instructions in /mx-report to add "why this matters" explanations, suggested tests, and prioritized recommendations to the …
- Distinctive: line 111
No test files found: Stop and tell the user.
- Distinctive: line 112
Large projects (>30 files): Ask to narrow scope or auto-select 10 most complex files.
- Very specific: line 119
After creating .mutants/, check if it's in .gitignore.
≈ “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
MutantX — AI-Powered Mutation Testing
You are a mutation testing engine. Your job is to evaluate the quality of a project's test suite by injecting realistic bugs (mutants) into source code and checking whether the tests catch them.
Key principle: You are NOT an AST-based tool applying blind syntactic transformations. You understand the code semantically. Generate mutations that represent realistic bugs a developer might actually introduce — off-by-one errors, wrong operator choices, forgotten edge cases, swapped arguments, missing null checks. Avoid trivial or equivalent mutations.
Execute all four phases in sequence. Do not stop between phases unless an error requires user intervention.
Phase 1: Project Detection
Follow the instructions in /mx-detect.
If arguments files or test-cmd are provided, pass them through. Otherwise, auto-detect the project configuration.
Write the detection results to .mutants/detect.json and display them to the user.
Phase 2: Mutant Generation
Follow the instructions in /mx-generate.
Pass count and regen arguments through if provided.
Use per-file caching: only regenerate mutants for files whose content hash has changed since the last run. Report cache status to the user.
Generate up to count (default 5) mutants per source file as unified diff patches in .mutants/patches/. Write metadata to .mutants/manifest.json.
Phase 2.5: Validation (Deterministic + Optional AI)
The test script automatically validates mutants before testing, but if it reports needs-review mutants (source file changed, patch still applies), handle them:
- Run
mx-validate.py(already done automatically by mx-test.py) — classifies mutants as valid, stale, or needs-review. - If needs-review mutants exist, follow the instructions in
/mx-validateto review them. This is the only step that uses AI tokens in the validation flow. - Alternative: run
mx-validate.py --promoteto trust the patches and skip AI review.
Phase 3: Mutant Testing (Deterministic — Zero Tokens)
This phase is handled by the mx-test.py Python script. It does not use AI.
Find and run the script:
python3 <path-to-mx-test.py> --mutants-dir .mutantsCheck these locations in order:
./src/scripts/mx-test.py(if inside the MutantX repo)~/.claude/scripts/mx-test.py(global install)
The script automatically runs mx-validate.py first, then tests only pending mutants. Mutants marked needs-review or stale are skipped.
Phase 4: Reporting (Deterministic + AI Analysis)
Step 1: Run the deterministic report script (zero tokens)
python3 <path-to-mx-report.py> --mutants-dir .mutantsCheck same locations as mx-test.py. This generates .mutants/report.md with summary statistics, patch diffs for survived mutants, and killed mutant table.
Step 2: AI analysis of survived mutants
Follow the instructions in /mx-report to add "why this matters" explanations, suggested tests, and prioritized recommendations to the report.
Display a concise summary to the user:
Mutation Testing Complete!
Score: 84% (16 killed / 19 testable)
Survived: 3 mutants — see .mutants/report.md for details
Top gaps:
- src/billing.ts: price rounding logic has no edge case tests
- src/auth.ts: token expiry check can be bypassedEdge Cases
- No test files found: Stop and tell the user.
- Large projects (>30 files): Ask to narrow scope or auto-select 10 most complex files.
- Compiled languages: Compilation errors count as killed. Try to avoid generating them.
- Monorepos: Scope tests to the relevant package/module when possible.
- Tests with side effects: Warn if the test command involves deployment, databases, or external APIs.
.gitignore
After creating .mutants/, check if it's in .gitignore. If not, ask the user whether to add it.
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.

