One Claude Code Tip a Day: Snapshot the Starting Diff

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 patch includes yesterday’s work

A surprisingly common Claude Code failure has nothing to do with model quality. You start in a repository that already has local edits: a half-finished experiment, a generated file from yesterday, or a teammate’s quick config change. You ask Claude to fix a failing test. It reads the tree, edits two files, runs the test, and then shows a confident diff. The problem is that the diff now includes both Claude’s work and everything that was dirty before the session began.

If you approve that combined patch, review gets noisy. Worse, Claude may explain pre-existing lines as if it created them, because from inside the current context they look like part of the task. Today’s habit is to snapshot the starting diff before any edit. The goal is not bureaucratic cleanliness; it is evidence. You want to know exactly what Claude changed, what was already there, and which files are safe to commit.

Start with a baseline prompt

Before asking for a fix, give Claude Code a read-only baseline task:

`Before editing anything, inspect the current working tree. Run git status --short and git diff --stat. If there are existing changes, summarize them by file and likely purpose. Do not modify files yet. End with a Baseline section that I can compare against after your patch.`

This prompt changes the session from ‘please fix it’ to ‘first establish the scene.’ A good baseline should name the dirty files, distinguish tracked modifications from untracked files, and avoid inventing intent when the evidence is weak. If Claude says, ‘src/auth/session.ts is already modified, but I cannot tell why from the diff alone,’ that is useful. It prevents the model from laundering unknown work into its own solution.

Make the baseline concrete enough to review later

For a real debugging session, I like a small table. Ask for this shape:

`Create a baseline table with columns: file, current state, likely owner, keep/ignore/question, and risk if mixed into this task. Use only git status and diff evidence. Do not edit.`

Imagine a frontend bug where a settings modal no longer closes on mobile. The tree already contains `package-lock.json`, `src/components/BillingBanner.tsx`, and an untracked `debug-screenshot.png`. The baseline table may mark the lockfile as ‘question,’ the billing banner as ‘probably unrelated,’ and the screenshot as ‘ignore for commit.’ Now when Claude later edits `src/components/SettingsModal.tsx` and a focused test, you can review the new patch without being distracted by the old noise.

Only then ask for the fix

Once the baseline exists, grant edit permission with boundaries:

`Use the baseline above as the starting state. Fix the mobile settings modal bug. Avoid touching files that were already dirty unless you first explain why the task requires it. After editing, show: 1) files changed by you, 2) baseline files left untouched, 3) verification command and result, 4) git diff --stat compared with the baseline.`

The important phrase is ‘compared with the baseline.’ Claude Code does not have a magical separate index of its own edits unless you make it maintain one. By giving it the baseline as a contract, you create a simple audit trail inside the conversation. The model can still make mistakes, but now there is a previous checkpoint to catch them.

Verification: ask for the delta, not the whole diff

After the first patch, do not ask, ‘What changed?’ That invites a broad summary of the entire working tree. Ask for the delta from the baseline:

`Compare the current git status and git diff --stat against the baseline you recorded before editing. Which files are new changes from this task? Which dirty files pre-existed? Did any pre-existing file change further? If yes, quote the reason and the exact hunks involved.`

This is especially valuable in deployment and debugging loops. A failed build may generate snapshots, coverage files, or lockfile churn. Claude may also run a formatter that touches files outside the intended fix. The delta review forces the session to separate useful task changes from accidental environment noise.

Failure modes

The first failure mode is treating `git diff` after the fix as the truth. It is only the truth of the current tree, not the truth of the session. Without a baseline, you cannot tell what changed during the conversation.

The second failure mode is asking Claude to clean up unrelated dirty files. That turns a debugging task into a repo housekeeping task. If the baseline exposes unrelated changes, either stop and clean the tree yourself, or explicitly tell Claude to leave them alone.

The third failure mode is ignoring untracked files. Generated screenshots, local scripts, and scratch logs often become accidental context. Make Claude name them so they do not silently influence the patch or the commit.

Second-pass correction

If Claude touched a pre-existing dirty file without a clear reason, slow down instead of accepting the patch:

`You modified a file that was already dirty in the baseline. Stop. Explain whether the new hunks are required for this bug. If they are not required, revert only your additions to that file while preserving the pre-existing baseline changes. Then rerun the focused verification.`

This correction is safer than a blanket revert because it respects the fact that the file was dirty before Claude arrived. You are asking for surgical separation, not pretending the working tree started clean.

Rule of thumb

When the repo is dirty, make Claude Code write down the starting diff before it writes code. A baseline takes less than a minute, but it gives every later prompt a reference point: what was already changed, what Claude changed, what verification belongs to the task, and what should stay out of the commit. Clean sessions are nice. Real sessions are messy. Snapshot the mess before you let the model improve it.