Narrow the scope of a change
When Claude Code changed more than you asked for, keep the part you want and have it undo the rest, file by file, then show the remaining diff.
Task: Narrow the scope of a change · Other tasks
Fill in the details
Name a directory, file, function or behavior. Everything Claude changed outside it will be undone.
Optional. Helps Claude judge edge cases, such as a shared helper both parts use.
Optional. Tests or a build that should still pass after the cleanup.
Copy your prompt
This site doesn't run Claude or show model output. Results depend on your input and the model you use.
You've edited the prompt, so changes to the fields aren't applied.
Replace what you've entered for this task with the example? This can't be undone.
What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.
When to use this template
- Claude Code went in the right direction but changed more than you asked for, such as refactoring nearby code or reformatting files during a small fix.
- You want to keep part of the work and lose the rest, which a full rewind to an earlier checkpoint cannot do.
- You are preparing a focused pull request and need the diff limited to one area before you review it.
When not to use it
- You want to throw away all of Claude's work since a certain point. Press
Esctwice or run/rewindand restore the code from that checkpoint instead. Checkpoints cover only edits made through Claude's file-editing tools, not changes made through Bash or outside Claude, so check those separately, for example withgit status. - The direction itself is wrong, not just the size. Use the course-correct template to name the constraint Claude missed.
- Your own uncommitted work is mixed into the same files and you have no copy of it. Commit or back up your changes first, so you can recover them if a revert goes wrong.
Why this structure
- The required scope field is the boundary for everything else in the prompt: what is inside it stays, what is outside it is undone.
- The rule to revert only Claude's own edits, file by file, and to avoid commands that wipe the whole working tree is there to protect your uncommitted work in the same files.
- The undo choice lets you see the list before anything is reverted. The default waits for confirmation, which matters when the edits are spread over many files.
- The dependency rule covers the awkward case where a kept change relies on a removed one, such as a helper both parts use. Claude stops and asks instead of breaking the kept work.
- The report lists reverted and kept files, shows the remaining diff and runs a check, so you can confirm the result matches the scope and still works.
Example input (fictional)
- The changes to keep
the validation logic in src/forms/
- Why the rest should go
the styling changes belong in a separate pull request
- How to undo
list the edits you would undo and wait for my confirmation
- Command to check the result
npm test -- src/forms
Follow-ups to send Claude
- Save the edits you just removed as a patch file in /tmp so I can apply them later in a separate branch.
- From now on in this session, change only files under src/forms/ unless I say otherwise.
- Review the remaining diff for anything that still reaches outside the validation logic.
Common mistakes
- Naming the scope loosely, such as "the important parts". Use a path, a function or a behavior Claude can check each edit against.
- Letting Claude run a repository-wide reset to save time. That can discard your own uncommitted changes along with Claude's.
- Skipping the check after the cleanup. Removing part of a change can break the part you kept, so run the tests before you move on.
Related templates
- Course-correct a wrong approach: When Claude Code heads the wrong way, name the constraint it missed and ask for a different approach, with a check that shows the retry meets it.
- Plan a code change before editing: Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.
- Review your changes before you commit: Have Claude Code review uncommitted changes against their intent and flag risks by severity, asking before any check that could change files.
Sources
- Claude Code docs: Prompt library (Anthropic documentation)
- Claude Code best practices: Course-correct early and often (Anthropic documentation)
- Claude Code best practices: Rewind with checkpoints (Anthropic documentation)