Prove the Checklist

The Rule

When you start any task that has a skill or SOP attached, the first thing on screen is the entire checklist. Every box, in order. Not summarized. Not “I’m familiar with the rules.” The list itself, ready to fill in.

Every box gets two things by the time the work is done:

1. A check mark
2. A receipt next to the check mark — a verifiable artifact a future reader can click, copy, or re-run

If the receipt cannot be produced, the box does not get checked. “I did it” is not a receipt. “I read the rule” is not a receipt. The receipt is the proof.

Before the commit (or the publish, or the send), the entire checklist gets reprinted with every box checked and every receipt attached. The artifact ships after the visible proof, not before.

What Counts as a Receipt

The check	Receipt that proves it
Linter passed	The exact output line: CLEAN: No AI-tell patterns detected.
No fabricated specifics	For each named year, count, frequency, or quoted line, the source transcript line number or memory file path that grounds it
Wiki-link targets exist	For each [[slug]], the file path of the target page
Affiliate URL correct	The matching line from affiliates.ts
Title length 50–60 chars	Output of awk -F'"' '/^title:/ {print length($2)}'
No PII	grep -iE "(@gmail|[0-9]{3}-[0-9]{4})" <file> returns 0
Build deployed	Production URL returning HTTP 200 plus the new build number
File lives in the right folder	ls -la <path> showing the file, with size and date

The pattern is the same shape every time: a verifiable artifact, not a verbal claim.

Examples From This Week

Example 1 — The article that shipped with five fabricated specifics

The agency-internal-wiki-claude-code article shipped to production at Build 212 with five made-up details: a Notion workspace from 2023, a wiki page on a project management tool not touched in six months, “every answer was a different version of the same chaos” (no one said that), “It has caught me twice” about a Zero Trust quirk (no evidence), and a case-mismatch behavior extrapolated from a memory file that covers a different scenario.

The create-blog-post skill had a “First-Hand Knowledge Only” check at the bottom. The check was read at the start of the work and forgotten by the end. The article shipped without anyone confirming each specific claim against a source.

What a receipt-bearing checklist would have caught:

• No fabricated specifics
  • Receipt: for each specific claim, paste the source transcript line number or memory file path

Filling that one box honestly would have stopped four of the five fabrications cold. The fifth (the case-mismatch invention) would have surfaced when the receipt for the Zero Trust warning forced a reread of ~/apps/cc/memory/reference_cf_access_otp_filtering.md, which says nothing about case sensitivity.

Example 2 — Filing a GitHub issue with /gh-issue

Earlier the same day, the same session ran /gh-issue to file a bug report on the Claude Code repo. The flow has eight explicit steps:

1. Gather local environment (Claude Code version, OS, recent context)
2. Search the target repo for duplicates
3. Read the target repo’s CONTRIBUTING.md and active issue templates
4. Scrub PII from the draft
5. Render a GitHub-style markdown preview
6. Wait for explicit approval
7. File via gh issue create
8. Monitor for bot auto-replies for 60 seconds after filing

Each step has a natural receipt:

Step	Receipt
1. Environment	The block of OS/version output that gets pasted into the issue body
2. Duplicate search	Output of gh issue list --search "<keywords>" --state all, listed in the preview
3. Templates	The exact filename of the issue template applied (e.g., bug_report.md)
4. PII scrub	A diff hunk showing what was redacted before render
5. Preview	The rendered preview text shown back in chat
6. Approval	The explicit user message saying “file it”
7. Filed	The returned GitHub issue URL
8. Monitored	The list of any bot comments that appeared in the 60-second window

The skill works because every step produces something visible. There is no quiet step. If a step is skipped, its receipt slot is empty, and the gap is obvious.

Example 3 — The detect-quotes-from-transcript skill

The skill was created the same evening after a separate failure: the first attempt at extracting social quotes from a transcript treated “memorable lines from the conversation” as equivalent to “standalone pull-quotes.” They are different.

The skill’s checklist now has eight boxes, each with a receipt:

• Every verbatim entry was read out loud with no setup and still landed → Receipt: for each entry, the entry text alone (no surrounding context) and a one-line confirmation
• No verbatim entry has a hedge word in the first three words → Receipt: grep -iE "^(\"|>|- )(almost like|kind of|i think)" <file> returns 0
• Every reshape is honest → Receipt: for each reshape, both the reshape and the source transcript line it was derived from
• …and five more

The skill also self-evolves: every run, if a new failure pattern surfaces, the “What We Learned” section in the skill file gets a new entry. The receipt for that box is the diff hunk added.

The Anti-Pattern

Read the checklist once at the top of the work. Plan the work. Do the work. Commit. Realize at the end that the checklist was not run. Promise to run it next time. Forget.

This pattern is what makes checklists feel decorative even when they are not. The fix is not “remember harder.” The fix is putting every box on screen and not letting the work move forward until the receipt is in.

The standup --flow mode already works this way. The atomic-commit hook already works this way. The voice-match hook already works this way. Each forces a class of failure into the open instead of trusting a memory rule. The Prove the Checklist pattern applies the same shape to every skill and SOP.

Why “I Read the Rule” Is Not a Receipt

A rule that gets quoted in chat but not applied to the artifact is the worst possible state, because the rule appears handled when it is not. The 2026-04-25 article had the description-ordering rule (summary, then links, then chapters at the end) quoted verbatim in the conversation, and then the article was drafted with chapters before links. The quote satisfied the appearance of compliance without any of the substance.

A receipt prevents that gap. The receipt is the artifact a future reader can re-run to verify. Quoting the rule produces no artifact. Applying the rule and pasting the result does.

How This Pattern Spreads

When adding any new skill or SOP that has multiple steps:

1. Write the steps as a numbered list, not prose
2. For each step, write the receipt slot underneath as a sub-bullet
3. Mark the section header Quality Checklist (Prove It Block) and add the standard preamble note pointing back to this page
4. Test the skill once and confirm every receipt slot can actually be produced (if a step does not have a clear artifact, either find one or rewrite the step to produce one)

When restructuring an existing skill from a flat list to a Prove It Block:

1. Read the existing checklist
2. For each item, ask “what artifact would prove this?” The answer is the receipt slot
3. Convert the item into a - [ ] <check> followed by a - **Receipt:** <description> sub-bullet
4. Add the standard Prove It Block preamble at the top of the section
5. Bump the build, commit, ship

Precedent / History

The principle was added to the global ~/.claude/CLAUDE.md on 2026-04-25 as a direct response to the article fabrication incident the same evening. The discussion that produced it lives in ~/apps/claude-memory-discussions/discussions/2026-04-25-prove-the-checklist.md, which captures the exact words used to describe the pattern: “you are basically proving, you are going to prove to me every single time that you did it correctly.”

Earlier the same day, the GitHub issue flow demonstrated what a working version looks like — every step produces something visible, gates are explicit, no quiet moves. The article fabrication demonstrated what the broken version produces — a published artifact that violates a documented rule because the rule was decorative.

The pattern that prevents both is the same: every checklist becomes a Prove It Block, every box gets a receipt, the artifact ships after the proof, not before.

Related

• The principle in source: ~/.claude/CLAUDE.md → “Prove the Checklist” section
• The discussion: ~/apps/claude-memory-discussions/discussions/2026-04-25-prove-the-checklist.md
• Skills already converted to Prove It Blocks: ~/.claude/commands/create-blog-post.md, ~/.claude/commands/doodle.md (step 8 only), ~/.claude/commands/detect-quotes-from-transcript.md, ~/apps/tms-ops/docs/video-to-article-sop.md
• Adjacent SOPs: Adding a Page to tms-internal, How We Build Anything