One Claude Code Tip a Day: Run Release Checks Like a Flight Recorder

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: the release looked green until it mattered

The most dangerous release check is the one that only confirms your optimism. A team fixes a checkout bug, the focused test passes, the branch looks small, and everyone wants to deploy before lunch. Then production fails because the migration was never dry-run against the real schema, the feature flag default changed in a sibling package, or the build script silently skipped the package that actually ships the page.

Today's Claude Code habit is to treat the pre-release pass like a flight recorder. Do not ask Claude to ‘check if this is ready’ in a vague way. Ask it to build an evidence log: what changed, which risks follow from those changes, which commands prove the release path, what failed, what was corrected, and what remains unproven.

Start with a release-readiness prompt

After the feature patch is complete, open a fresh release-check turn inside Claude Code and make it read before it reassures you:

`We are doing a release check, not new feature work. Do not edit yet. Inspect git status, git diff --stat, the changed files, package scripts, migrations, env/config changes, and relevant tests. Produce a release risk list with the exact command or inspection that would prove each risk.`

This prompt changes the role of Claude Code. It is no longer the implementer trying to finish the ticket. It becomes the skeptical release engineer. The useful output is not a generic checklist; it is a checklist derived from the actual diff. A CSS-only change should not invent a database migration review. A checkout-flow change should ask about payment mocks, browser behavior, and the backend contract.

Make the checks executable

A release checklist that cannot be run is decoration. Push Claude to turn each risk into a concrete command or inspection:

`Convert the risk list into a minimal command plan. For each command, say what success looks like, what failure would mean, and whether it is required before release or only nice to have.`

For a realistic web app patch, the plan might include `pnpm test -- checkout`, `pnpm typecheck --filter web`, `pnpm build --filter web`, a migration dry run, a quick log query from the staging deploy, and a manual browser check of the mobile payment route. The point is not to run every command in the repository. The point is to make Claude justify the smallest set of checks that covers the changed behavior.

Use failures as routing, not as noise

The TonBisa-style loop matters here: prompt, run, inspect, correct, verify again. Suppose the build fails with an unrelated lint warning in an old admin file. A shallow session may either ignore the failure or start repairing the entire admin app. A better release-check session routes the evidence:

`The build failed. Classify this failure: release-blocking for our changed path, pre-existing unrelated issue, or unknown. Use the log lines and changed files as evidence. Do not edit until you state the classification and the narrowest next check.`

Sometimes Claude will discover that the ‘unrelated’ failure is actually related because your shared UI package changed. Sometimes it will prove the failure existed on main and should be documented separately. Either outcome is more useful than a confident ‘all good’ that never looked at the log.

Second-pass correction before deploy

Release checks often expose small but important misses: a missing export, a stale README command, a snapshot that no longer matches the UI, or a feature flag default that makes staging differ from production. When that happens, keep the correction narrow:

`Make the smallest release-blocking correction only. After editing, rerun the exact failing check, then show git diff --stat and summarize why the release risk is now closed. Do not refactor adjacent code.`

This is where Claude Code is strongest when steered well. It can patch the seam, rerun the check, and explain the verification trail. But you must prevent the release pass from becoming a second feature sprint. The output you want is a cleaner flight recorder, not a larger patch.

Inspect the final diff like a release artifact

Before you tag, merge, or deploy, ask for the final evidence bundle:

`Prepare a release note for the reviewer. Include changed files, user-visible behavior, commands run with pass/fail results, known non-blockers, rollback notes, and any checks we did not run. Then review git diff for accidental files, debug logs, secrets, generated artifacts, or broad formatting churn.`

This final step catches the embarrassing problems: a `.env.local` accidentally staged, a debug `console.log`, a generated lockfile change from the wrong package manager, or a test fixture updated without explanation. Claude should not merely summarize the patch; it should compare the patch to the release intent.

Failure modes

The first failure mode is asking Claude for a universal release checklist. Universal lists sound professional and miss the one risk created by your diff. Always derive the checklist from changed files and deployment path.

The second failure mode is treating green tests as complete evidence. A focused test can pass while the build, migration, browser route, or staging config fails. Ask which release risks remain unproven.

The third failure mode is letting Claude fix everything it sees. During release checks, correction is allowed only when it closes a release-blocking failure. Everything else becomes a note or a follow-up issue.

Rule of thumb

Use Claude Code release checks to create an evidence trail, not a mood. The question is not ‘does Claude think this is ready?’ The question is ‘which changed behaviors were inspected, which commands passed, which failures were classified, and what remains unproven?’ If the answer fits in a precise release note, you are much closer to a deployable patch.