test-health-check
Skill12 starsChanged 2 months agoMITView on GitHub
Prove that a unit, integration, or end-to-end test genuinely guards its stated behavior by running a few targeted fault probes (reachability, sensitivity, oracle validity, reliability) around the code under test — instead of trusting coverage. Use during active test development or test review — after writing or changing a test, when verifying a test actually catches real bugs, when a test "passes but might not test anything", when a suite feels untrustworthy, or to health-check the tests affected by the current branch. Supports an isolated git-worktree mode scoped to affected cases so production code is never touched.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ivklgn/bag-of-skillsword for word, first seen Sep 4, 2026
Other versions1 project uses a version of this.
Word for word · 1
- ivklgn/bag-of-skills★ 12100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
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 repository22 other files it gives its agents.
- AGENTS.mdAGENTS.md
- new-skillSkill
- review-and-releaseSkill
- 12-factor-appsSkill
- ask-meSkill
- audit-websiteSkill
- can-i-useSkill
- code-reviewerSkill
- compatibility-auditSkill
- explain-branch-changesSkill
- humanizer-ruSkill
- humanizerSkill
- jsdocSkill
- load-branch-changesSkill
- nextjs-developerSkill
- recapSkill
- reset-permissionsSkill
- review-golangSkill
- seo-auditSkill
- simplify-code-commentsSkill
- update-golang-depsSkill
- update-node-depsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. About 0 are common, 15 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈15
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 43
MUST identify the claimed test contract before probing.
- Distinctive: line 44
MUST establish a passing baseline first.
- Distinctive: line 45
MUST change only ONE behavior per probe.
- Distinctive: line 46
MUST keep an exact diff of every probe.
- Distinctive: line 47
MUST restore the repository after every probe.
- Distinctive: line 48
MUST verify the restored test passes.
- Distinctive: line 49
MUST distinguish a test failure from a build / infrastructure failure.
- Very specific: line 50
MUST NOT declare a test healthy when its oracle is unclear (emit ORACLE_UNCLEAR).
- Distinctive: line 51
MUST NOT report a mutation score from an agent-selected sample.
- Distinctive: line 52
MUST NOT retain production mutations.
- Distinctive: line 53
MUST verify any proposed test passes on original code and fails on the relevant broken variant.
- Distinctive: line 64
Establish the baseline: Run the test (and, if cheap, its file/class).
- Very specific: line 66
MUST be green. If it is red or flaky, stop dynamic probing and report FLAKY_OR_ORDER_DEPENDENT or surface the broken baseline — do not …
- Distinctive: line 74
Restore and re-verify: After every probe, restore the exact bytes and re-run the original test to confirm it is green again.
- Distinctive: line 81
Before mutating a file, snapshot its exact bytes.
- Very specific: line 92
Use the bundled helper scripts/worktree.sh (base branch defaults to main):
- Distinctive: line 113
If nothing is affected, say so and stop — do NOT silently probe the whole repo.
- Very specific: line 114
Always cleanup the worktree (wrap the run so cleanup happens even if a probe throws).
- Very specific: line 120
Default is diagnose-only. With --fix, propose a MINIMAL test patch that closes the proven gap, then verify all three: (a) the new/changed …
- Distinctive: line 154
Read these as needed (one level deep):
≈ “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
Test Health Check
Produce compact PROOF that a specific test guards its stated contract — by running a few targeted fault probes around the code under test. This is not mutation testing and emits no mutation score. It answers a sharper question for active development: does this test pass on healthy behavior and reliably fail on a plausible, contract-related break?
Why coverage is not enough
A test can execute a line, or even cover an entire method, yet still fail to assert anything meaningful (a "pseudo-tested" method survives having its whole body deleted). And a test that kills mutants can still pin the wrong requirement if its oracle was copied from the implementation. So this skill verifies four independent properties:
- Reachability — the test actually exercises the target behavior.
- Sensitivity — the test fails under a plausible, contract-related break.
- Oracle validity — assertions match the contract/spec/invariant, not the implementation.
- Reliability — the result is reproducible and isolated (not flaky / order / environment dependent).
Invocation
$ARGUMENTS may contain a target and flags. The target is a test name, a test/source file, a
diff/branch scope, or a described behavior. If no target is given, default to the affected cases
of the current branch (see Worktree mode).
| Flag | Effect |
--worktree | Run the whole cycle in an isolated git worktree scoped to affected cases. Production tree is never mutated. Strongly preferred. |
quick (default) | Current test or changed file: baseline → reachability probe → 2 sensitivity probes → restore. |
focused | Function/class/endpoint/flow: baseline → contract extraction → 3–7 targeted probes → boundary/failure analysis → suggestions. |
deep | Critical behavior: broader probe set, repeated runs, test-order variation, mock/fixture review, metamorphic checks, boundary verification. |
exhaustive | Hand off to a real mutation runner for a true score. NOT the primary mode — only for a full module / CI gate / historical comparison. |
--fix | After diagnosis, propose and verify a minimal test patch (off by default). |
MUST rules (hard constraints)
- MUST identify the claimed test contract before probing.
- MUST establish a passing baseline first.
- MUST change only ONE behavior per probe.
- MUST keep an exact diff of every probe.
- MUST restore the repository after every probe.
- MUST verify the restored test passes.
- MUST distinguish a test failure from a build / infrastructure failure.
- MUST NOT declare a test healthy when its oracle is unclear (emit
ORACLE_UNCLEAR). - MUST NOT report a mutation score from an agent-selected sample.
- MUST NOT retain production mutations.
- MUST verify any proposed test passes on original code and fails on the relevant broken variant.
Core workflow (the fast loop)
- Locate the test and the target code. Determine the level (unit / integration / e2e) — it
changes what to probe. See
references/levels.md. - Extract the contract. State explicitly what the test promises to verify. Source priority:
(a) user-stated behavior, (b) issue / acceptance criteria / PR description, (c) public API +
docs, (d) domain invariants, (e) neighboring tests, (f) production code — LAST, since an
oracle copied from the implementation can lock in an existing bug. If no reliable contract can
be derived → stop and report
ORACLE_UNCLEAR. - Establish the baseline. Run the test (and, if cheap, its file/class). Record the exact
command, exit code, duration, seed (if any), test count, and working-tree state. The baseline
MUST be green. If it is red or flaky, stop dynamic probing and report
FLAKY_OR_ORDER_DEPENDENTor surface the broken baseline — do not probe on top of a broken baseline. - Reachability probe. Insert a controlled sentinel (throw / fail / panic) at the target point
in production code and run the test. Expect failure caused by the sentinel. If the test still
passes →
NOT_EXERCISING_TARGET. Restore. - Sensitivity probes. Introduce a few plausible, contract-specific defects — ONE behavior
change per probe — and confirm the test fails for the right reason. Default set: 1 reachability
- 2 contract-specific + 1 boundary/error probe. Pick probes from
references/probes.md.
- 2 contract-specific + 1 boundary/error probe. Pick probes from
- Restore and re-verify. After every probe, restore the exact bytes and re-run the original test to confirm it is green again. Keep the diff of each probe for the report.
- Diagnose. Map results to one diagnosis token and list concrete gaps. See
references/diagnoses.mdfor the full enum, when each applies, and the proof matrix.
Restore mechanism (when NOT using --worktree)
Before mutating a file, snapshot its exact bytes. After the probe, rewrite the snapshot and
re-run the test to confirm green. If the file already had uncommitted changes, restore from the
snapshot (not git checkout, which would discard the user's edits). Prefer --worktree to make
this bulletproof.
Worktree mode + affected cases
--worktree (and the default no-target invocation) scopes probing to the tests touched by, or
covering, the current branch's changes, and runs the whole cycle in a disposable git worktree —
so temporary production mutations never reach the real tree, even on interruption.
Use the bundled helper scripts/worktree.sh (base branch defaults to main):
# 1. Discover affected files (branch diff vs main + staged + unstaged + untracked)
bash scripts/worktree.sh affected
bash scripts/worktree.sh tests # same, filtered to likely test files
# 2. Create the isolated worktree (HEAD + uncommitted + untracked replayed); capture its path
WT=$(bash scripts/worktree.sh setup)
# 3. Run baseline + all probes inside "$WT" (cd into it for test + edits)
# 4. ALWAYS tear it down — even on failure
bash scripts/worktree.sh cleanup "$WT"Rules for this mode:
- Map affected SOURCE files to their tests (by naming convention and import/reference), and
include changed TEST files directly.
scripts/worktree.sh testssurfaces obvious test files; do the semantic source→test mapping yourself. - If nothing is affected, say so and stop — do NOT silently probe the whole repo.
- Always
cleanupthe worktree (wrap the run so cleanup happens even if a probe throws). Never leave orphaned worktrees;git worktree listshould be clean afterward. --worktreecomposes withquick/focused/deep.
--fix (opt-in)
Default is diagnose-only. With --fix, propose a MINIMAL test patch that closes the proven gap,
then verify all three: (a) the new/changed test passes on original code, (b) it fails on the
relevant broken variant, (c) the existing suite stays green. This prevents writing a test
tailored to one syntactic mutant. Never auto-apply without these three checks passing.
Output
Report the contract, the baseline, each probe with its one-line change and result
(detected | survived), the diagnosis token with findings, and (if requested) the suggested
test change. Use a compact structured block:
test: cancels_unpaid_order
scope: integration
contract:
description: "Cancelling an unpaid order persists CANCELLED and issues no payment"
confidence: high
sources: [test name, public service contract, domain state machine]
baseline: { status: passed, command: "<cmd>", runs: 2 }
probes:
- { id: reachability, change: "throw at OrderService.cancel", result: detected }
- { id: remove-persistence, change: "skip repository.save", result: survived }
- { id: invert-payment-condition, change: "initiate payment for unpaid order", result: detected }
diagnosis:
status: WEAK_ORACLE
findings: ["verifies returned status but not persisted state"]
suggested_test_change: ["reload the order from persistence and assert CANCELLED"]
confidence: highState the diagnosis honestly: prefer INCONCLUSIVE or ORACLE_UNCLEAR over a false HEALTHY.
References
Read these as needed (one level deep):
references/probes.md— the probe catalog (effect removal, decision inversion, boundary, result error, failure-path, metamorphic) with language-agnostic examples. Read when choosing probes.references/levels.md— unit / integration / e2e specifics, dual observation for e2e, and which diagnoses apply per level. Read when determining what to probe at a given level.references/diagnoses.md— the full diagnosis enum, when each applies, and the proof matrix (healthy-code vs broken-code expectations). Read when classifying the result.
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.

