prove

# Prove ## When to Use The change is supposed to be done, or the user asked for a report of what to run. Load this after `shape`, or after bundled `systematic-debugging`. ## What to do Done means a check you ran. Show it failing for the right reason, then passing. Name the surface you exercised: the CLI, the API, the job, the webhook, or the page. A unit test that never calls that surface is not this check. Run the check with `terminal`. Report-only mode lists the check, the command, and the expected failure. Do not edit product code in that mode. A performance claim names the limiter, how many times you repeated it, and the error. Otherwise it is not a result. An unvetted number is not a result. Do not restate bundled skills. Load them with `skill_view`: - A bug with a cheap unit test: `test-driven-development`. - Browser exploration of a page: `dogfood`. Use `browser_exec` only as that skill directs. When the passing check is real, stop. Opening a pull request is `ship`, and only when the user asks.