The Scope Contract

Every task you give Claude Code has an implicit scope — the set of files, systems, and actions that are relevant to the task. The problem is that the agent's inference about scope and your assumption about scope are frequently different. The agent will touch files you did not expect it to touch, make changes you did not expect it to make, and take actions you did not authorize — not because it is malfunctioning, but because the scope was never defined and it made a reasonable inference.

A scope contract is an explicit definition of what is in and out of bounds for a task. It can live in CLAUDE.md as a default, in a project-specific instruction block, or in the task prompt itself. The format does not matter. What matters is that the agent cannot execute the task without a defined scope — and that when you give it a task, the scope is part of the specification.

Fix the authentication bug in src/auth/loginHandler.ts.

Scope:
- IN SCOPE: src/auth/ directory, src/middleware/authMiddleware.ts
- OUT OF SCOPE: Any other files — do not edit them, even if you identify related issues
- OUT OF SCOPE: Test files — report failing tests but do not modify them

If the fix requires changes outside this scope, stop and ask before proceeding.

1. Define scope at the file/directory level Scope should name specific files or directories, not concepts. "Only touch authentication-related files" is ambiguous. "Only touch src/auth/ and src/middleware/authMiddleware.ts" is not.
2. Explicitly exclude adjacent areas The most important part of the scope contract is what is excluded. Stating exclusions forces you to think through adjacencies you might otherwise leave implicit — and gives the agent explicit direction when it encounters them.
3. Specify the out-of-scope action "Out of scope" should specify what to do when the agent encounters an out-of-scope item: stop and ask, note it but proceed, or ignore it entirely. The agent needs a directive, not just a boundary.