Audit Prove It

A verification skill that says PROVED on a broken app is worse than none: it gives false confidence. The only way to know it works is to break the app on purpose and see if it notices. This skill does that, safely, and reports every bug that slipped past.

Safety first

You are about to edit product code on purpose. These rules keep that from hurting anyone:

• Only in a git repo, only on local files. Never against a shared, staging or production instance.
• Back up before you plant. The files a change touched usually have uncommitted work in them, and git checkout would throw it away. Before planting, copy the file byte for byte to .prove-it/audits/<UTC timestamp>/originals/<path>. Revert by copying it back. This is what makes the revert exact.
• One planted bug at a time. Plant, check, revert, confirm the revert, then the next.
• Confirm every revert with cmp <backup> <file> (exit 0) before moving on. If it doesn't match, stop everything and restore from the backup. Never use git checkout on a file that had uncommitted changes.
• Never commit, push or stash a planted bug. At the end, git status must look exactly as it did at the start, plus any receipts in .prove-it/ and the report.

1. Find the skill and baseline it

Find the prove-* skill (under .claude/skills/ or .agents/skills/, with the prove-it: marker comment). If there are none, stop and suggest /create-prove-it. The marker says which kind it is.

For a temporary migration skill, plant bugs in the new system only. The old system is the answer key. A bug planted there tests nothing, and it can leak into the snapshots the end step records. Its target is the migration's covered areas that have moved or are in progress.