DEV Community

Hideaki Kubo
Hideaki Kubo

Posted on

The .mdc rules I use to stop Cursor from expanding my PRs

#ai #productivity #github #cursor

Cursor is fast. But left unchecked, it expands PRs.

Here are the three .mdc rules I use to keep that from happening.
Free on GitHub.

The problem in one sentence

You ask for one fix. Cursor touches five files.

Each change might look reasonable. But the PR becomes harder to review,
harder to revert, and harder to explain.

Rule 1: no-unrequested-changes.mdc

This rule tells Cursor not to modify anything outside the scope of
the original request.

- Do not edit unrelated files that are outside the current task scope
- Do not refactor working code as part of an unrelated task
- Do not add new utilities, helpers, or abstractions unless asked
Enter fullscreen mode Exit fullscreen mode

Rule 2: one-pr-one-topic.mdc

This rule tells Cursor that a PR should answer one question:
what decision is this asking the human reviewer to make?

- Do not combine unrelated changes in a single PR
- Do not mix implementation and refactoring in the same PR
- If the user adds a new request that introduces a separate concern,
  ask whether it should be handled as a separate PR.
Enter fullscreen mode Exit fullscreen mode

Rule 3: classify-before-merging.mdc

Before merging, this rule prompts a classification step.
The human decides. Not the AI.

- Do not merge without identifying which changes are accepted as-is
- Do not carry over follow-up work silently — make it explicit before merge
- If any item requires a human decision before merge, do not proceed.
Enter fullscreen mode Exit fullscreen mode

How to use them

Copy the three .mdc files into your project's .cursor/rules/ directory.

Then try a task in Cursor. Watch whether the PR stays scoped.

Free Pack on GitHub:
https://github.com/logfabricteam/cursor-pr-discipline

Pro Pack v0 on Gumroad ($29):
https://kubo03.gumroad.com/l/cursor-pr-discipline

Top comments (1)

Collapse
 
nazar_boyko profile image
Nazar Boyko •

Cursor turning a small fix into a five-file PR is basically the overeager intern who reformats the whole file while fixing your typo. These rules will nudge it in the right direction, but the thing about prose rules is the model can drift past them on a long task and you won't notice until review. I'd back rule 2 with something the model can't argue with, like a CI check that fails the PR when it touches more than N files or crosses package boundaries. The rule sets the intent, the check actually enforces it.