prooflisted

# Proof ## Iron Law `NO ENGINEERING CLAIM WITHOUT A NAMED PROOF.` Prove every non-trivial claim before you call it done. A proof is a named check that would fail if the claim were false: point to that check, or mark the claim unproven. "The tests pass" doesn't count until you can say which test would break if you were wrong. ## When to Use As a completion gate, before any reply that says or implies the work is done, fixed, ready to commit, ready for a PR, or passing: - Name the claim and the check that backs it. If there is no check, say what is unproven and which evidence is missing; don't just write `unproven` and move on. As the main skill, when the task is the proof itself: - Writing or reviewing behavior tests for a feature, bug fix, refactor, flaky test, or any untested behavior. - Deciding what needs coverage and which boundary the test should enter through. - Turning an agreed spec, domain model, contract, or root-cause finding into Proof Contracts and runnable checks. ## When NOT to Use - Formatting, typo fixes, or file moves that change no behavior, data, or contract. - Mechanical refactors with no behavior surface (renames, file moves, comment-only edits) that tooling or a direct look at the result already confirms. If the refactor changes something a caller can observe, you still need `proof`. - Chasing a bug whose cause you haven't pinned down. Use `debugging` first; come back once you have a claim to prove. - Judging design, complexit