One Claude Code Tip a Day: Make /verify Earn Its Keep

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

The real failure: green confidence, unverified behavior

Claude Code can produce a clean-looking patch faster than you can open the app. That speed is useful, but it creates a specific failure mode: you accept a change because the explanation sounds right, not because the behavior is proven. I have seen this most often on frontend bugs. Claude edits the React component, says the prop now flows correctly, and the diff looks plausible. Then the browser still shows the old state because the route uses a mobile drawer, the dev server was stale, or the fix only covered one branch of test data.

Today’s habit is to treat /verify as the evidence pass after implementation. Not as a ceremonial “run the tests,” and definitely not as a magic stamp. Use it to force Claude Code to build, run, inspect, and report what actually changed.

Start /verify with an acceptance contract

The best /verify prompt begins before the command. First, describe the evidence you expect. Suppose the task was: “the billing page should show the discounted monthly total after a coupon is applied.” After Claude makes the smallest patch, do not ask, “is it fixed?” Ask:

/verify The coupon fix is only done if the billing page renders a discounted monthly total, the original total remains visible as comparison text, and the existing price formatting tests still pass. Run the smallest relevant checks first. If a check fails, stop and explain whether the failure is product behavior, test setup, or an unrelated pre-existing issue.

This does two things. It tells Claude what “working” means in user-visible terms, and it prevents the common spiral where the agent keeps editing every time a command exits nonzero. A failed verification is information, not permission to thrash the codebase.

A realistic session loop

Imagine Claude changed apps/web/src/components/BillingSummary.tsx and added one test in BillingSummary.test.tsx. The first verification pass should be narrow:

/verify Run the BillingSummary unit test, then run the billing page in the dev app or story if available. Show the exact command output and the rendered-state evidence. Do not edit during this pass.

A strong result is specific: “pnpm test BillingSummary passed; the Storybook story renders couponCode=SUMMER26 with $12.00 discounted total; screenshot inspection shows the original $20.00 remains in the comparison row.” A weak result is vibes: “Looks good, tests pass.” Push back on weak results. Ask Claude to name the command, the file, and the user-visible signal.

When /verify finds a failure, make it classify the failure

The useful part of /verify is often the first red result. For example, the test passes but Playwright fails because the discount row is hidden on mobile. Do not immediately say “fix it.” The second prompt should preserve the evidence:

The /verify pass found that desktop renders the discount, but the mobile checkout drawer does not. Re-read the failing Playwright output and the mobile drawer component. Do not edit yet. Explain why the previous patch did not affect the failing viewport, then propose the smallest second patch.

This is the TonBisa-style loop in practice: prompt, inspect, find the gap, correct, verify again. The point is not to punish Claude for missing the mobile path. The point is to make the failed verification become the next map of the codebase.

Use /verify after diff review, not instead of it

/verify should not replace git diff review. Before running a broad verification pass, ask for the changed surface area:

Show git diff --stat and the full diff for the files you changed. Explain why each file was necessary. Then run /verify against the acceptance contract.

If the diff includes a snapshot update, a config change, and a helper refactor when the task was a one-line UI condition, verification may still pass while the patch is too large. Your job is to keep the loop honest. Verification proves behavior; diff review protects maintainability.

Failure modes

First, /verify can be too broad. “Run everything” sounds responsible, but on a large repo it may waste an hour and bury the relevant signal under flaky integration tests. Start with the smallest check tied to the changed files, then expand only if the risk justifies it.

Second, /verify can be too late. If Claude has already made three speculative edits, the verification pass becomes archaeology. Use it immediately after the first narrow patch.

Third, /verify can hide environment problems. A dev server that failed to start is not proof the feature is broken. Make Claude separate product failure, test failure, and environment failure before editing again.

Rule of thumb

Use /verify when the next question is not “what code should we write?” but “what evidence would make us trust this change?” Give it an acceptance contract, require exact command output, inspect the diff, and turn failures into a second-pass correction. A good Claude Code session does not end when Claude says the patch is done. It ends when the repo, the tests, and the visible behavior agree.