One Claude Code Tip a Day: Ask for a Verification Receipt

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The failure: success without evidence

The most dangerous Claude Code answer is not a loud failure. It is the polished final note that says the bug is fixed, tests pass, and the implementation is clean, while the actual session only ran a linter or never exercised the path that broke. In a real app, this usually happens near the end of a long loop: a frontend loading bug, a backend validation edge case, or a deployment script that only fails under production environment variables. Claude made a plausible patch, ran one convenient command, and summarized confidence as if it were proof.

Today’s habit is to ask for a verification receipt before you accept the patch. A receipt is a short, structured audit trail: what changed, which commands ran, what each command proved, what was not checked, and what Claude would do next if one piece of evidence is missing. It turns the end of the session from a sales pitch into a handoff you can inspect.

The prompt: make the receipt explicit

After Claude Code edits files and claims the task is done, do not ask, `Are you sure?` That invites another confident paragraph. Ask for the evidence artifact instead:

Prompt: `Before I review this, produce a verification receipt. Include: 1) exact files changed, 2) exact commands run, 3) exit status or observed result for each command, 4) which user-facing behavior each command proves, 5) checks you did not run and why, 6) any warnings or suspicious output, and 7) the smallest next step if the proof is incomplete. Do not edit while writing the receipt.`

The key phrase is `do not edit while writing the receipt`. You want Claude to stop generating more code and start accounting for the work already done. This is especially useful when the final response says `all tests pass` but the terminal history contains only `pnpm lint` or a test command that matched zero files.

A realistic loop: invisible text in a React component

Imagine the task is a frontend bug: a generated dashboard title exists in the DOM but appears invisible on a dark hero background. Claude inspects the component, notices a gradient text utility, changes a Tailwind class, and says it is fixed. A weak session ends there. A better session asks for the receipt.

A good receipt might say: changed `src/components/HeroTitle.tsx`; ran `!pnpm test -- HeroTitle` with exit 0; ran `!pnpm build` with exit 0; did not run the browser because no local server is active; risk remains that the CSS renders differently in Chromium. That receipt is not perfect, but it is honest. It tells you the exact missing proof. Your second pass becomes targeted: `Start the dev server, open the dashboard route, inspect the computed styles for the title, and verify the text is visible at mobile and desktop widths. If the browser check fails, report the computed color/background-clip before editing.`

Inspect the receipt against the diff

The receipt is not separate from code review. Pair it with `!git diff --stat` and `!git diff`. Ask Claude to compare the evidence to the patch:

Prompt: `Compare the verification receipt to the actual diff. For each changed file, identify the command or observation that proves it. Mark any changed file with no direct proof. If a file is unproved, recommend either a focused check or a revert.`

This catches subtle scope creep. If Claude changed a shared button primitive while fixing one dashboard title, the receipt should contain evidence for every consumer risk or admit that the shared change is unproved. If the only evidence is a component unit test, you may decide to move the fix back into the page-specific class. The receipt gives you a calm way to challenge the patch without turning the review into vibes.

Failure modes and second-pass correction

The first failure mode is a receipt that merely restates intentions: `I updated the component and verified the behavior.` Reject it. A receipt needs commands, outputs, paths, and observed behavior. The second failure mode is hiding skipped checks. Skipped checks are acceptable when named: no database credentials, flaky external API, browser unavailable in CI. They are dangerous when they disappear from the summary.

The third failure mode is letting the receipt trigger a giant cleanup pass. If the receipt exposes missing proof, ask for the smallest correction. For example: `Run the one Playwright spec that covers the hero route; do not refactor the title component.` Or: `Add one regression test for the validation branch; do not rename the schema helpers.` The receipt should narrow the next action, not reopen the entire task.

Rule of thumb

Ask for a verification receipt whenever a Claude Code session crosses from editing into claiming completion. It is mandatory for UI bugs, deployment loops, migrations, auth, billing, and anything where `looks good` is cheaper than real proof. My rule is simple: no receipt, no merge. The receipt does not guarantee correctness, but it forces the session to separate evidence from confidence. That separation is where good human review begins.