Publish Sign in

Strengthen tests — kill the highest-leverage survivors

Take a Stryker summary.json (from n8n:mutant-score), triage the surviving mutants by user-reachable-behaviour risk, write minimal…

You say
Install this skill Read the source first Free Written by n8n-io · unverified publisher
Context cost
2.3k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 9.0 kBtext throughout, nothing executable
Licence
Source-availablefree to use
Last change
—no release on file
Servers it uses
Noneruns standalone

What it does

Take a Stryker summary.json (from n8n:mutant-score), triage the surviving mutants by user-reachable-behaviour risk, write minimal assertion changes to kill the top 3-5 highest-leverage survivors, then verify by re-running n8n:mutant-score. Use when the user has just run mutation testing and wants to strengthen the test suite, or says "kill the survivors / strengthen tests / fix the red." Pairs with n8n:mutant-score as the inner write side of a single iteration.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

securitytesting
Filed under

Security & Testing

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md9.0 kB · 152 lines
--- description: Take a Stryker summary.json (from n8n:mutant-score), triage the surviving mutants by user-reachable-behaviour risk, write minimal assertion changes to kill the top 3-5 highest-leverage survivors, then verify by re-running n8n:mutant-score. Use when the user has just run mutation testing and wants to strengthen the test suite, or says "kill the survivors / strengthen tests / fix the red." Pairs with n8n:mutant-score as the inner write side of a single iteration. ---
5# Strengthen tests — kill the highest-leverage survivors
6
7The other half of the local mutation-testing loop. n8n:mutant-score reports which mutations escaped the tests; this skill picks the ones that matter and writes minimal assertion changes to kill them.
8
9## When to use
10
11- User has just run /n8n:mutant-score <file> and the verdict was red
12- User says: "strengthen tests", "kill the survivors", "fix the red", "iterate on the tests for X"
13- Mid-loop: this skill's verify step calls n8n:mutant-score again, so the loop closes here
14
15**Don't** use this skill:
16- For a green verdict — there's nothing to strengthen; if user insists, push back and ask which file actually needs work
17- To bulk-kill every survivor — explicitly capped at 5 per invocation. Re-invoke for more.
18
19## Inputs
20
21Accepts **either** a source file or an existing summary — whichever you have:
22
23- **A source file** (a repo-relative path, e.g. packages/workflow/src/workflow-checksum.ts — package inferred): self-bootstrapping — there's no summary yet, so step 1 runs n8n:mutant-score to produce one, then proceeds. This is the entry point for unattended callers (e.g. cat-bot acting on a ledger gap).
24- **An existing summary**: --summary <path>. A prior n8n:mutant-score run wrote it to that package's reports/mutation/summary.json (e.g. packages/workflow/reports/mutation/summary.json). Skips the bootstrap.
25
26## Steps
27
28### 1. Get a summary (bootstrap if needed)
29
30- **Given a source file** (or no usable summary on disk): run n8n:mutant-score on the file first to generate <package-dir>/reports/mutation/summary.json. Then read it.
31- **Given/defaulting to a summary path**: read it directly.
32
33Read the summary (already compact, ~50 KB) and pull:
34- files[0].file — the source file under test
35- files[0].score — current mutation score
36- files[0].survivors[] — every surviving (and no-coverage) mutant with location, replacement, covering test names
37
38If the verdict is already green, stop — nothing to strengthen.
39
40### 2. Read the source under test, sparingly
41
42Read the source file referenced in summary.json. Read **once**, the whole file (typical source files are 50-500 lines; the cost is bounded). This is the only file read; don't load test files yet.
43
44### 3. Triage the survivors
45
46Categorise each survivor into one of three buckets. Use the rubric below — don't apply it mechanically, but lean on it.
47
48**HIGH leverage — "real regression vector":** mutant guards behaviour that real users actually hit through the public API surface.
49
50- Type checks against shapes user data routinely takes: null, undefined, Date, Buffer, Uint8Array, Array, plain objects with arbitrary keys
51- Conditional branches that gate critical fall-through (e.g. "if this returns early, the wrong code path runs")
52- Code paths that handle user-controlled flow: expressions, Code-node behaviour, binary item handling, deep-clone semantics
53- Mutants on guard clauses that prevent crashes (if (value == null) return ...)
54
55**MODERATE leverage — "user-observable invariant":** real but lower-frequency user impact.
56
57- Proxy traps that change Object.keys / in / hasOwnProperty semantics after mutation
58- Set-then-delete / re-set-after-delete sequences (Code-node assignment patterns)
59- Treating undefined assignment as deletion (obj.foo = undefined → key removed)
60- Edge cases that only fire under specific iteration patterns
61
62**LOW leverage — "refactor insurance" or noise:** skip these. Document the skip in the output but don't write tests for them.
63
64- Constructor property checks (arr.constructor === Array) unless production code is known to rely on them
65- Idempotency invariants only triggered by other library code (Lodash, native spread)
66- Equivalent mutants — mutations that produce semantically identical code (e.g. swapping an unused conditional)
67- Mutants on internal helpers users can't reach through any public API
68
69If the summary lists noCoverage survivors, treat them as their own bucket: "the test suite doesn't even execute these lines." Triage them by the same rubric, but flag separately since they need a new test case rather than an assertion extension.
70
71### 4. Pick the work set: up to 5 mutants
72
73Order: all HIGH first, then MODERATE if budget remains, never LOW. Hard cap at 5 total. If HIGH alone exceeds 5, pick the 5 most distinct (don't pick 5 mutants on the same line — they probably share a fix; pick representatives across the file).
74
75If fewer than 3 HIGH+MODERATE candidates exist, just do what's there. Don't pad with LOW just to hit a number.
76
77Write up the work set to the user **before editing**:
78
79```
80Picked N survivors to address (M skipped as refactor-insurance / low-leverage):
81 1. [HIGH] location — original → replacement
82 plan: assert <X> in <covering test name>
83 2. [HIGH] ...
84 3. [MODERATE] ...
85 ...
86```
87
88This is the user's chance to redirect. Don't write code yet.
89
90### 5. Read covering tests for the picked survivors
91
92For each picked survivor, the summary lists the test names that covered the line. Find those tests in the test file (usually packages/<pkg>/test/<source-basename>.test.ts, but check) and read **just the relevant test('...') blocks** — not the whole file. Use Grep + Read with line offsets to keep token cost down.
93
94Goal: understand what the existing test asserts so the new assertion is additive, not contradictory.
95
96### 6. Write the changes
97
98Constraints:
99- **Prefer extending an existing covering test** over adding a new one. Lower file churn, easier review.
100- **Match the existing style** — same assertion library, same matcher idioms (.toBe vs .toEqual vs .toStrictEqual).
101- **Minimal additions** — one or two assertions per mutant, not a new it-block per mutant.
102- **No fabrication** — only assert what the source code actually does. If you can't tell from the source, stop and ask the user.
103- **For noCoverage survivors**, add a new test case named after the behaviour being pinned. Place it next to related tests.
104
105Use Edit with exact-string matches. Never rewrite entire test files.
106
107### 7. Verify
108
109Re-invoke n8n:mutant-score on the same source file. Report:
110
111```
112Before: red 76.74% (28 survivors)
113After: green 82.34% (22 survivors)
114Killed: 6 of 5 targeted (1 bonus — fix for #77 also killed #78)
115Still surviving: 22 — re-invoke /n8n:mutant-fix for another batch.
116```
117
118If the score went UP but threshold still not met: the iteration is working, recommend another pass.
119If the score went DOWN or stayed the same: at least one new test isn't asserting what we think it asserts. Surface the diff to the user and stop — do not auto-revert.
120If a test now fails (not survives — actually fails): we asserted something the code doesn't do. Revert that specific assertion, leave the rest, report which one was wrong.
121
122## Output shape
123
124Each invocation produces:
125
1261. **Work plan** (before edits) — the picked survivors and the plan for each
1272. **Diffs** (during edits) — Edit tool calls, visible in transcript
1283. **Verify** (after) — re-run + before/after comparison
129
130Keep prose minimal between sections. The plan and verify steps are the structured outputs; everything else is mechanical.
131
132## Constraints
133
134- **5 mutants max per invocation.** Re-invoke for more. Prevents runaway sessions on 30-survivor files.
135- **Never fabricate assertions.** If the source doesn't clearly do X, don't claim it does.
136- **No new test files unless absolutely necessary.** Extend the existing covering test file.
137- **No reverting other people's tests.** Only edit tests in the package being mutated.
138- **No re-running mutant-score more than once per invocation.** That's the verify step. Don't loop within a single invocation; let the user re-invoke.
139- **No commits.** Edits land in the working tree; user reviews and commits.
140
141## Common follow-ups
142
143- User says "go again" → re-invoke this skill. The summary.json now reflects the post-edit state.
144- User says "why was #N classified as LOW?" → explain the rubric application for that specific mutant, no re-triage of others.
145- User says "kill #N specifically" → override the triage for that mutant, treat it as picked.
146- User says "skip the verify step" → don't; the verify step is the contract that the edits actually moved the score.
147
148## Related
149
150- n8n:mutant-score — the read side of this loop
151- scripts/mutation-health/README.md — the BQ-backed observability story this slots into
152
In the file
SKILL.md1,382 words
Files1
LicenceSource-available
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈120
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
2,130
on trigger
The instruction body, read only when the skill fires.
1.1%
of a 200k window
Ten skills this size would take about 11% of the window before you open a file.
050k100k150k200k context window

2.3k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 9.0 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md9.0 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The Source-available licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# Strengthen tests — kill the highest-leverage survivors · 2.3k tokens when loaded npx mcprush@latest skill add n8n-io/strengthen-tests-kill-the-highest-leverage-surviv

Writes to .claude/skills/strengthen-tests-kill-the-highest-leverage-surviv/ in the current project. Add --global to put it in your home directory instead, for every project.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencen8n-io/strengthen-tests-kill-the-highest-leverage-surviv

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

NN
n8n-io

Publishes on mcprush.

0 servers listed18 skills listednot claimed
Profile
Publisher
Servers0
Claim this skill