Scope creep in Cursor sessions comes from the same place it comes from with humans: unclear boundaries and the temptation to improve things while you're in the neighborhood.
These patterns stop it.
Pattern 1: File-level scope declaration
Add to the start of your task description, not your .cursorrules:
"Only modify [filename]. No other files."
But back it up in .cursorrules:
When given a task with specific files mentioned, only modify those files. If other files need changes to complete the task, ask before proceeding.
Pattern 2: The stop-and-ask rule
If completing this task requires modifying a file not mentioned in the request, stop and explain what change is needed and why, before making it.
This surfaces hidden dependencies. Sometimes Cursor needs to touch a types file or a config to make your change work. Better to know about it than have it appear in the diff.
Pattern 3: Separate refactoring from feature work
Do not refactor code while adding features. Refactoring and feature work are separate commits. If you want to suggest a refactor, note it at the end of your response as a separate suggestion.
Mixing refactoring with feature work produces hard-to-review PRs. The rule keeps them separate.
Pattern 4: The TODO pattern
If you notice code quality issues, bugs, or improvements outside your task scope: add a TODO comment and continue. Do not fix them in this session.
This preserves the observation (the TODO) without the unreviewed fix. You decide later if it's worth addressing.
What this adds up to
Small diffs. Each PR changes exactly what it says it changes. Reviews take 10 minutes instead of 30. Bugs from unrelated changes stop appearing.
The configuration is 4 rules. It takes 2 minutes to add.
Top comments (0)