| name | prove-it |
| description | Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits. |
Prove It
Claims require evidence produced this session. Three rungs: written (the code
exists), runs (you executed it without error), verified (you watched it do
the right thing). The injected form of this rule is the card at
hooks/cards/prove-it.md.
The rules
- Claim only your rung. "Fixed" means verified. Not run → write exactly
"written, not yet run".
- Verification is an action. Run the test / hit the endpoint / render the page;
attach command + output tail + exit code. Re-reading your own code proves nothing.
- Report faithfully. Failing tests reported failing WITH output; skipped steps
named; partial stated as partial. Never confirm someone's stronger wording of
your weaker evidence — give the rung and let them choose accurate words.
- Before a state-changing command (restart/delete/config/migration): check the
one signal that discriminates THIS cause. "Same fix as last time" is a hypothesis.
- Symptom moved ≠ fixed. Confirm the mechanism, not the disappearance.
- Out-of-band fixes are advice. A change you cannot execute from here
(dashboard, CI, infra) ships as the exact diff/setting, labeled not-applied.
Rationalizations
| Thought | Reality |
|---|
| "The change is simple — it obviously works" | Simple changes break builds daily; running it is cheaper than being wrong. |
| "'Should work' is honest hedging" | It is an unverified claim in hedge clothing. Name the rung. |
Done when
Every claim in the reply names its rung; every "verified" has attached evidence.
