What it does
Constrains Claude Code to the requested task and nothing more. When the agent notices adjacent issues — outdated comments, inconsistent naming, missing error handling in unrelated code — it flags them instead of fixing them. Scope stays tight, PRs stay reviewable.
When to use it
- In any codebase where PRs are reviewed by humans
- When working on bug fixes that shouldn’t balloon into refactors
- In monorepos where a change in one package can ripple across boundaries
- When your AI agent has a habit of “improving” things you didn’t ask about
How it works
Add to your CLAUDE.md:
## Scope Discipline
Before any change that touches more than 3 files or crosses package boundaries,
stop and list the proposed scope for confirmation. Do not let editorial/copy PRs
cascade into renames, or coverage fixes into unrelated refactors. When scope
grows mid-task, pause and re-confirm rather than pressing on.
The agent will:
- Stay within the boundaries of the original request
- Flag adjacent issues as separate follow-up items instead of fixing them inline
- Stop and ask before expanding beyond 3 files or crossing package boundaries
- Keep PRs focused on a single concern
Example
Without this skill: “Fix the login error message” → agent fixes the error message, then notices the error handler uses var instead of const, refactors the error handler, updates the test file, reformats imports in 4 adjacent files, and adds JSDoc to 3 functions. PR touches 9 files.
With this skill: “Fix the login error message” → agent fixes the error message in 1 file, updates the corresponding test. Notes in the response: “I noticed the error handler could use a refactor — want me to create a separate PR for that?” PR touches 2 files.
Why it matters
Scope creep is the #1 cause of unreviewed PRs. When an AI agent touches 15 files for what should have been a 2-file fix, the reviewer either rubber-stamps it or sends it back. Neither outcome is good. Tight scope means faster reviews, cleaner git history, and easier rollbacks.