One Claude Code Tip a Day: Turn Failed Checks Into the Next Prompt

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

The failure: the second prompt is too vague

The first Claude Code patch often fails in a useful way. A focused test still red-lines. The browser flow now reaches a different broken state. The deployment log moves past the missing environment variable and lands on a database timeout. That is progress, but many developers waste it with the weakest possible follow-up: `fix it`.

Today's habit is to turn the failed check into the next prompt. Do not summarize from memory, do not soften the error, and do not invite a broad rewrite. Treat the failing output as the source of truth for the next Claude Code move. The workflow is simple: run the check, paste the exact signal, ask for one hypothesis, allow the smallest correction, then rerun the same check before expanding scope.

Start with the check you actually trust

Imagine you asked Claude Code to fix a timezone bug in a billing dashboard. The UI used to show renewals one day early for customers west of UTC. Claude read the component, patched date formatting, and reported success. Instead of trusting the summary, you run the focused check:

`npm test -- billing-renewal-timezone`

The test fails with `Expected Jul 18, received Jul 17` in the Pacific case. That failure is not an annoyance; it is the next prompt. A good Claude Code session keeps that signal intact because it tells the model exactly which behavior still matters.

Paste evidence, then freeze the scope

A strong second-pass prompt is almost boring:

`The focused test still fails. Do not edit yet. Here is the exact output: [paste failure]. Explain the most likely cause in one paragraph, name the file and hunk you would inspect first, and say which existing behavior must not change.`

The `Do not edit yet` line is doing real work. It prevents Claude from turning every failure into a new patch before it has explained its theory. The requested file and hunk make the model anchor the hypothesis in code, not vibes. The final constraint reminds it that one failing check is not permission to redesign date handling across the app.

Ask for one patch, not a rescue mission

After Claude explains the likely cause, give it a narrow edit budget:

`Apply the smallest change that should make this exact test pass. Do not change test expectations. Do not touch unrelated date helpers. After editing, show the diff and rerun npm test -- billing-renewal-timezone.`

This is where the habit pays off. Claude may discover that the first patch normalized the display date but left the renewal cutoff calculation on local midnight. The correction might be a two-line change near the cutoff function, plus no test edits. That is the shape you want: one hypothesis, one patch, one repeated check. If Claude instead modifies three utilities and updates snapshots, stop the session and ask it to justify why the failure required that much surface area.

Use different checks, but keep the same discipline

The pattern works beyond unit tests. For frontend work, paste the browser evidence: the selector, viewport, console error, and what you saw after a hard refresh. For example: `At 390px width, the menu opens but the overlay is behind the hero. Console is clean. Computed z-index for .mobile-menu is 5; hero has transform and creates a stacking context. Do not edit yet. Identify the smallest CSS change to verify.`

For deployment debugging, paste the first new failing log line, not the whole emotional story: `Railway deploy now passes build, but the worker exits with DATABASE_URL points to localhost. Explain why this only appears in production and list the environment variable check before editing code.` In both cases, the failed check becomes a precise steering wheel. Claude should react to evidence, not to your frustration.

Inspect the second pass like a regression risk

When Claude returns with a fix, make it narrate the diff against the failed signal:

`Group the diff by intent. For each hunk, say which line of the failure it addresses. Mark any hunk that is preventive rather than required for this failure.`

Then read `git diff` yourself. The most common bad second pass is over-correction: weakening assertions, broadening conditions until the test passes accidentally, hiding an error in a catch block, or changing UI markup when the bug was CSS. If the diff does not map back to the pasted failure, it is not a fix yet; it is motion.

Failure modes

Do not paste a thousand-line log and ask Claude to guess. Trim to the command, the first failing line, the relevant stack frame, and any environment detail that changes the theory. Do not let Claude replace a failing focused check with a passing broad command; `npm test` passing does not prove the timezone case if `billing-renewal-timezone` still fails. And do not accept test edits unless the explicit task is to correct a bad test. In normal debugging, failed checks are witnesses, not obstacles to silence.

Also watch for stale failures. If you changed files manually, restarted a server, or switched branches, rerun the check before using old output as the next prompt. Claude cannot reason from evidence that no longer describes the working tree.

Rule of thumb

Use failed checks as structured input, not as bad news. The next prompt should contain the exact signal, a no-edit reasoning step, a narrow edit budget, and the same verification command. If you cannot point each second-pass hunk back to the failure you pasted, the session has drifted. Claude Code is strongest when the loop is evidence → hypothesis → small patch → same check, repeated until the original signal changes.