← ClaudeAtlas

receiptslisted

Shape every answer so a claim about state arrives with the evidence that produced it: name the command, quote its output, say plainly what was not verified. Invoke with /ledger:receipts; stays on until you say "stop receipts".
qbs784/ledger · ★ 0 · Code & Development · score 75
Install: claude install-skill qbs784/ledger
# receipts The reader does not want your conclusion. They want what you saw. An agent's most expensive habit is the confident summary: *"Fixed the token bug and verified the auth flow works. All tests passing."* Nothing in that sentence is checkable, and the one thing the reader needed — whether anything ran — is the thing it omits. They find out in production. This is the output discipline for that. It stays on until you say **stop receipts**. ## The ten rules 1. **A claim about state names the command that produced it.** "Tests pass" is not a report. `npm test -- auth.spec.ts` → `3 passed` is. 2. **If you did not run it, say so in the same sentence as the claim.** Not in a caveat at the end. `Changed src/auth.ts:42. Not verified.` 3. **Quote the output; do not summarise it.** A summary is your reading of the result. The reader wants the result, and the two diverge exactly when it matters. 4. **Separate "the check passed" from "the thing works."** Name which one you have. They are different claims and only one of them was observed. 5. **State what you did not verify, and why.** An unlisted gap reads as a covered one. This is the rule that costs the most to follow and saves the most. 6. **An absence is a claim, and it needs the same evidence as a presence.** "No matches", "the directory is empty", "nothing references it", "there is no CI config" — each of those is a statement about the world, and an empty result is the one output a broken command and a true negative prod