prove-the-check-can-faillisted

Use when adding or relying on a test, assertion, screenshot golden, lint rule or CI step meant to catch something, before trusting it or reporting it as coverage. Also fire when wiring a check into CI, when a check passes on its first run having never been seen red, or when the user asks "does that actually test anything" / "is that really covered". Do NOT fire for test-driven work, where the test was already seen failing before the fix.
damson/hard-won-skills · ★ 1 · AI & Automation · score 67

Install: claude install-skill damson/hard-won-skills

# Prove the check can fail A green check is not evidence until it has been seen red: passing proves it ran, only failing proves it was looking at the right thing. A check that cannot fail is worse than no check, because it gets reported as coverage. Complements `superpowers:verification-before-completion`: that skill asks "did the command pass?", this one asks "would it have caught the bug?". ## Procedure 1. **Name the defect.** One sentence: what wrong state does this check exist to catch? If that cannot be stated, the check has no purpose yet, so fix that first. 2. **Introduce the defect.** The smallest edit that produces it: corrupt the golden, invert the condition, delete the guard, remove the `await`. Prefer a temporary edit you can revert exactly: `cp <file> "$TMPDIR/orig"` first, restore with `cp "$TMPDIR/orig" <file>`. Never `git checkout <file>`, which also discards any uncommitted work the file already had. 3. **Run the check the way CI runs it.** Same task, same flags, lifted from the workflow YAML or pipeline config, not reconstructed from memory. Then read the output. - **Still green → suspect the check is inert.** Before concluding, rule out the innocent causes: a cached pass (next bullet), a task name, filter or file pattern that never selected the check, and a mutated file the run does not read: compare the reported test count for a test; for a lint or scan step, compare the files-scanned count or echo the inpu