I've tried a lot of CLAUDE.md scope rules. Some work, some get ignored. Here are the ones that hold in practice.
Rules that work
Specific file constraints:
"Only modify files in src/api/. Do not touch src/web/ or any configuration files."
Works because it's unambiguous. Claude knows exactly which files are in scope.
The minimal footprint rule:
"Minimal footprint. Only touch files directly required for the stated task. Do not refactor adjacent code, add comments to files you didn't change, or fix issues you weren't asked to fix."
Works because it addresses the specific behaviors that cause scope drift.
The note-don't-fix rule:
"If you notice other issues while working, note them in a TODO comment but do not implement the fix."
Works because it gives Claude an action (note it) instead of just saying no.
Done criteria:
"Do not mark a task complete until: tests pass, tsc shows zero errors, and you have run the lint check."
Works because it's a checklist Claude can verify against.
Rules that don't work
Vague preference language:
"Try to keep changes small" — Claude interprets "small" differently than you do.
"Prefer to minimize changes" — "prefer" is not a constraint.
"Where possible, follow existing patterns" — this is weak and gets overridden by judgment.
The pattern
Rules that work are: specific, observable, and testable. You can look at the diff and verify compliance.
Rules that don't work are: vague, advisory, or rely on Claude's judgment about what "small" or "minimal" means.
If you can't tell from the output whether the rule was followed, the rule is too vague.
Top comments (0)