New skill: /prove-regression — prove a regression test fails on the base commit before trusting it

Problem

A regression test that has never been run against the broken code proves nothing — and the failure is silent, because a test that passes on the base commit looks identical to a test that passes on the fix.

This is not hypothetical. While fixing AudioClassifier #196, the first draft of the e2e regression test passed on main. It would have shipped as green certification of a live, user-facing bug. The only thing that caught it was manually running it against the base commit. (The root cause was fixture infidelity — see the companion standards issue — but the detection mechanism was red-on-base.)

Proving red-on-base is currently manual, repetitive, and genuinely risky. What it took in that session:

1. Back up the uncommitted fix to a scratchpad (source changes weren't committed yet)
2. git checkout main -- pwa/sw.js pwa/manifest.webmanifest
3. Run the test, confirm it fails
4. Confirm it fails for the reported reason, not an incidental one
5. Restore the fix from the scratchpad
6. Re-run, confirm green

Step 2 is a footgun: run it against uncommitted work without step 1 and the changes are gone. I hit exactly that pressure — the working tree held unbacked-up edits, so a manual backup was the only thing standing between a verification step and data loss. Steps 3–4 are easy to conflate: a test that fails because of a typo'd selector looks the same as one that fails because of the bug.

Why a skill, not documentation

The companion standards issue adds the rule ("prove it fails on base"). A rule doesn't help with the part that's dangerous and fiddly: doing it safely against a dirty tree. This is a fixed, mechanical sequence with a data-loss hazard and a subtle correctness check in the middle — exactly the shape that benefits from being bundled. Documentation would tell you to do the risky thing correctly; a skill just does it.

Goal

A /prove-regression skill that answers: does this test actually discriminate?

Proposed behavior

/prove-regression <test-command> [--base main] [--expect "net::ERR_FAILED"]

1. Resolve the base ref (default main, or the branch's merge-base).
2. Materialize the base version of the changed source files without touching the working tree — git show <base>:<path> into a temp dir, or a throwaway git worktree. Never git checkout base -- <file>.
3. Run the test command against base source + current test file. Expect failure.
4. If --expect is given, assert the failure output contains it — guarding against "fails for the wrong reason."
5. Run against HEAD. Expect pass.
6. Report the verdict:
   • DISCRIMINATES — red on base (for the right reason), green on HEAD
   • DOES NOT DISCRIMINATE — passed on base; the test certifies nothing, and say so loudly
   • INCONCLUSIVE — failed on both, or failed on base for an unexpected reason
7. Guarantee working-tree restoration on every exit path, including interrupt.

Acceptance criteria

• Works with an uncommitted working tree and cannot destroy uncommitted work — verified by a test that runs it against a dirty tree.
• Never uses bare git stash (shared stack across worktrees, per team standards).
• Detects and loudly reports the passes-on-base case; this is the primary purpose.
• --expect distinguishes "failed for the reported reason" from "failed incidentally."
• Language/framework agnostic — takes an arbitrary test command.
• Restores the working tree on failure, early exit, and interrupt.
• Complements /verify (does the change work?) rather than overlapping it; /prove-regression asks whether the test works. Cross-reference both ways.

Open questions

• Auto-detect changed files via git diff --name-only <base>, or require them as arguments? Auto-detect is friendlier but will sweep in the test file itself, which must stay at HEAD — that carve-out is the crux of the implementation.
• Worth invoking automatically from /deep-review when a diff adds a test alongside a fix?

Start by reading the existing /verify skill and the team standards referenced in the issue, then trace how skills accept arbitrary test commands and manage temporary Git state. Exercise the proposed command on a dirty tree, including base-pass, expected and unexpected failures, interrupts, and restoration; done means it reports the stated verdicts without losing uncommitted work and cross-references /verify.