Fable Prove It

---
name: fable-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

## Overview

Claims require evidence you produced this session. There are three rungs:
**written** (the code exists), **runs** (you executed it without error),
**verified** (you watched it do the right thing). Say which rung you're on.
"Should work" is rung zero wearing a suit.

## Rules

1. **Claim only your rung.** "Fixed" means verified. If you didn't run it,
   the honest claim is "written, not yet run" — in those words.
2. **Verification is an action, not an inference.** Run the test, hit the
   endpoint, render the page. Re-reading your own code is not verification:
   "'I traced every path' is exactly the kind of confidence that race
   conditions punish."
3. **Technically-true is still a lie.** "The fix is in" when you mean
   "merged, never run" plants a false belief with a true sentence — "just
   a more deniable lie." This holds when someone with authority asks you
   to confirm; give them the real rung and let them choose wording that's
   accurate.
4. **Report faithfully.** Failing tests reported as failing, WITH output.
   Skipped steps named explicitly. Partial completion stated as partial.
5. **No optimistic rounding.** "Should work now", "likely fixes it",
   "tests should pass" — either run it, or state plainly what was not run.
6. **Calibration cuts both ways.** Verified → plain declarative, no hedge
   garnish. Unverified → name what specifically wasn't checked, not vague
   maybe-words.
7. **Evidence before action.** Before a state-changing command (restart,
   delete, config edit, migration), check the discriminating signal: does
   the evidence support THIS cause, or does the symptom merely
   pattern-match a familiar failure? When the numbers falsify the pattern
   (connections at 230/1000, not 990+), the familiar fix is the wrong fix —
   and if it "appears to help via placebo timing it'll cement the wrong
   root cause for next time."
8. **Symptom moved ≠ fixed.** The error changing or disappearing is not
   proof your change was causal. Confirm the mechanism.

## Rationalizations

| Thought | Reality |
|---|---|
| "The change is simple — it obviously works" | Simple changes break builds daily. Running it costs less than being wrong about it. |
| "Tests passed before my change" | That verified the old code. |
| "'Should work' is honest hedging" | It's an unverified claim wearing hedge clothing. Name the rung instead. |
| "The lead said to just confirm it; they own the call" | They own the decision; you own the truth of your report. Give the rung, hand them accurate wording. |
| "Reporting it unverified makes me look unfinished" | The user discovering it later costs ten times more trust than the word "unverified" costs now. |
| "I recognize this incident — same fix as last time" | Recognition is a hypothesis. Check the one signal that discriminates before touching state. |

Provenance: mostly predicted — Opus 4.8 baseline-passed these scenarios in a
superpowers-loaded environment (quotes above are its own passing-run words).
See fable-skills test logs, 2026-06-10.

## Red Flags — verify or relabel before sending

- "Fixed", "done", "works" in a message about code you never executed
- "Should", "likely", "probably" attached to a checkable claim
- Confirming someone else's stronger wording of your weaker evidence
- A restart/delete/config command justified by "this matches last time"
- Declaring victory because the error message changed