One Claude Code Tip a Day: Apply Changes Deliberately with /apply

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

The real task: do not let a good-looking patch land too early

A common Claude Code failure is not dramatic. Claude reads the right files, proposes a reasonable fix, and produces a patch that looks coherent at a glance. You are tired, the bug is annoying, and the next keystroke feels obvious: accept it and move on. The problem is that “reasonable” is not the same thing as “ready to enter the working tree.” Once edits land, your review becomes fuzzier. You are now debugging code plus context plus whatever unexamined assumptions the patch carried in.

Today’s habit is to treat `/apply` as a checkpoint, not a convenience command. When Claude Code has pending changes, pause before applying them. Ask what the patch is supposed to prove, inspect the risky lines, split the work if needed, and only then apply the slice you can verify. This is especially useful when Claude is working on frontend behavior, test fixes, migrations, config, or anything that can look correct while failing in the real environment.

The workflow

Start the session normally, but make the review gate explicit before Claude edits:

`Fix the checkout summary rounding bug. Read the relevant files first. When you have pending changes, stop before /apply and summarize exactly what changed, which assumptions you made, and which command should prove the fix.`

After Claude proposes changes, do not immediately type `/apply`. Ask for a pre-apply field report:

`Before I run /apply, review the pending patch as if you were the maintainer. Separate mechanical edits from behavior changes. Name the highest-risk line and the test or manual check that would catch a regression.`

A good answer is concrete. It should say something like: “The behavior change is in `OrderSummary.tsx`, where totals are rounded after discounts instead of before. The mechanical edit is the renamed helper. The risk is that tax-inclusive prices may double-round. Run `pnpm test -- checkout-total` and manually verify the discount case in Playwright.” A weak answer says the patch is straightforward and should work.

A realistic failure loop

Imagine a React app where the success banner sometimes disappears after payment. Claude finds a stale `isSubmitting` flag and prepares a small patch. The pending diff looks clean: one component, one test, no obvious churn. If you apply immediately, you may miss the fact that the backend callback can also return `pending`, which means the banner logic is only half the story.

Use `/apply` as the moment to challenge scope:

`Do not apply yet. Does this pending patch prove the production failure, or only the local UI symptom? Inspect the event flow and tell me whether a backend status case is outside this repo. If so, keep the current patch pending and propose the smallest verification step.`

Now the session becomes a debugging loop rather than a patch conveyor belt. Claude may realize the frontend test only covers `success`, not `pending`. You can then ask it to add a failing test first, narrow the frontend patch, or stop and move to the API repo. The value of `/apply` is that nothing has landed while you are still deciding whether the theory is complete.

Inspect before applying

My preferred pre-apply checklist has five questions. First, what user-visible behavior changes? Second, what files changed only because of formatting, naming, or generated output? Third, what assumption would make this patch wrong? Fourth, what focused command proves the change? Fifth, what should I inspect in `git diff` after applying?

You can make Claude do this work with a compact prompt:

`Prepare a pre-/apply checklist: behavior change, mechanical changes, risky assumption, proof command, and post-apply diff inspection points. If any item is vague, do not recommend applying yet.`

Then read the actual pending patch view. Look for broad rewrites, opportunistic cleanup, test snapshots that changed too much, config edits, or helper functions that changed semantics under a harmless name. If the patch mixes a bug fix with refactoring, ask Claude to split it before you apply: `Keep the bug fix pending, remove the opportunistic cleanup, and show me the smaller patch.`

Second-pass correction after /apply

Applying is not the finish line. It is the transition from proposed changes to verifiable changes. Immediately run the proof command Claude named. If it fails, paste the failing output back with a narrow instruction:

`The proof command failed after /apply. Do not broaden the solution. Explain why this exact failure contradicts your assumption, then patch only the minimal line needed. After that, tell me what to inspect in git diff.`

This prevents the common spiral where a failed test triggers three more speculative edits. The rule is simple: after `/apply`, evidence outranks momentum. Tests, logs, browser screenshots, and `git diff` decide the next move.

Failure modes

The first failure mode is applying a patch because it is small. Small patches can still encode the wrong theory. The second is applying a mixed patch because part of it is clearly useful. Ask Claude to split behavior from cleanup. The third is applying before naming a proof command. If nobody can say how the change will be verified, you are not ready to apply; you are ready to inspect more.

Also be careful with generated files, lockfiles, migrations, and snapshots. These are not automatically bad, but they deserve a separate explanation. Ask Claude why each generated change exists and what command would reproduce it. If the answer is hand-wavy, do not apply that slice yet.

Rule of thumb

Use `/apply` when the pending patch has a clear theory, a small scope, and a named proof command. Before applying, make Claude critique its own diff. After applying, verify immediately and review `git diff` like a maintainer. The best Claude Code sessions do not reward the first plausible patch; they reward the patch that survives a checkpoint.