Scope management is the discipline of keeping Claude focused on what you asked for. Without it, sessions drift — Claude notices related issues and fixes them, or adds features that seemed useful, or restructures code "while it's in there."
This produces bigger diffs, harder reviews, and sometimes broken things you didn't know were being touched.
The root cause
Claude is trained to be helpful and thorough. Finding adjacent problems and fixing them is helpful. The problem is you asked for something specific, and you're going to review this diff against that specific thing. Everything else is noise.
Rules that work
These go in CLAUDE.md:
Minimal footprint. Only modify files directly required for the task.
Do not refactor code you weren't asked to refactor.
Do not add comments to code you didn't change.
Do not fix issues you notice unless they're causing the current bug.
Note additional issues in a comment but don't implement the fix.
These rules are specific enough that Claude follows them consistently.
The "note don't fix" pattern
This is the most useful one: "If you notice other issues while working, note them as TODO comments in the code but do not fix them."
You get the benefit of Claude's observation (it noticed a bug) without the cost of an unreviewed fix appearing in your diff.
Mid-session scope check
If a session is going long, run git diff --name-only periodically. If you see files in the diff that aren't in scope, stop and ask Claude to explain why it touched them. Often it's correct but worth understanding. Sometimes it's scope creep.
After the session
Compare the final diff against the original task description. Did Claude touch what was asked? Anything extra? The diff review is easier when scope was maintained than when Claude did its best work on everything it noticed.
Top comments (0)