review-jit-test-gen
JIT Test Generation
Generate focused tests for the code being changed right now, and prove each one would catch a regression in that change.
The JIT approach: write tests at the moment of change, when context is freshest and the risk of regression is highest. A test that passes on the change and also passes on the broken version catches nothing, so the core of this skill is Step 6: run the new tests against a broken version and show that at least one fails.
Background: references/wisdom.md (from What Is Just-in-Time Catching Test Generation?) explains catching versus hardening tests, mutants, and the "dodgy diff". Read its first two sections if the terms are new.
Keep or Throw Away
wisdom.md describes catching tests as disposable: they are generated to fail on a buggy diff, and they never join the codebase. A user who asks for "tests for my changes" usually wants tests they can keep. This skill produces both kinds and treats them differently:
| Result of Step 6 | What it is | What to do |
|---|---|---|
| Passes on the change, fails on the parent or a mutant | Proven hardening test: it guards this change against future regressions | Keep it in the project's test tree (default) |
| Fails on the change itself | Weak catch: the change may have a bug, or the test misread the intent | Never commit it. Ask the user, in one line, "this used to do X, now it does Y; is that intended?" A "no" means the code has a bug: fix it, and the test becomes a keepable regression test. A "yes" means the test was wrong: delete it |
| Passes on both | Catches nothing for this change | Rewrite it to target a risk from Step 3, or delete it |
Why keep the proven ones: wisdom.md's "disposable" rule exists because large pipelines generate thousands of unreviewed tests per diff, and nobody can maintain them. Here a person asked for a few tests, reviews them, and each one is proven to fail on a real breakage, so it earns its maintenance cost.