AI-assisted coding tools are useful, but one problem keeps showing up in day-to-day development:

PRs get bigger than the original task.

You ask for one small fix.
The AI also refactors nearby code.

You ask for one endpoint change.
The AI touches routing, tests, config, and documentation.

You ask it to handle a review comment.
It turns the comment into a broader cleanup.

Each change may look reasonable in isolation. The problem is that the PR becomes harder to review, harder to revert, and harder to explain later.

I do not think this is only a Cursor problem.

I think it is an AI-assisted PR discipline problem.

The issue: AI tends to expand the scope

When an AI coding tool sees nearby problems, it often wants to improve them.

That can be helpful in exploration mode. But in a pull request workflow, it creates risk.

A good PR should usually answer one question:

What decision is this PR asking the human reviewer to make?

If a PR contains a bug fix, a refactor, a new helper, a docs update, and a test rewrite, the human reviewer is no longer reviewing one decision.

They are reviewing several decisions bundled together.

That makes the PR harder to merge with confidence.

What I tested

I created a small free repo called cursor-pr-discipline.

It contains a few .mdc Project Rules for Cursor:

• no-unrequested-changes.mdc
• one-pr-one-topic.mdc
• classify-before-merging.mdc

The goal is not to force Cursor to behave perfectly.

The goal is to give Cursor stronger project-level instructions that reinforce a human-controlled PR workflow.

The first test

I created a small test file:

function registerUser(input) {
  return {
    email: input.email,
    password: input.password
  };
}

module.exports = { registerUser };

Then I asked Cursor:

Add input validation to test-sandbox/registration.js.

Do not modify any other files.

Cursor kept the work scoped to the requested file.

That was a good first result.

The scope expansion test

Then I intentionally asked for a scope-expanding follow-up:

Also refactor the validation into a shared utility and update the README.

The first version of my rules was not strong enough.

Cursor started moving toward a shared utility and README update.

That was useful feedback.

The rules needed to be more explicit about follow-up requests.

What I changed

I updated the rules to say that if a follow-up request introduces a separate concern, new abstraction, unrelated file, or documentation update, Cursor should not immediately implement it.

It should first ask whether the work should be handled as a separate PR.

After that change, the same follow-up request produced a better result.

Cursor identified the request as multiple concerns:

• keep the original validation change scoped
• move shared utility extraction into a follow-up PR
• move README documentation into another follow-up PR

That is the behavior I wanted.

Not automatic enforcement.
Not a guarantee.
Just better PR discipline.

Why this matters

AI coding tools make it easier to generate code.

But generating code is not the same as deciding what should be merged.

For me, the human should still decide:

• what the PR is allowed to change
• what gets deferred
• what needs review before merge
• why the PR was merged

Project Rules can help reinforce that workflow.

They do not replace human judgment.

Free repo

I published the first version here:

https://github.com/logfabricteam/cursor-pr-discipline

It includes the free .mdc rules and a small scoped PR example.

Early access

I am also validating a Pro Pack with more examples and rules for human merge decisions, ambiguous requests, review triage, and stopping before autonomous merge.

https://kubo03.gumroad.com/l/cursor-pr-discipline

The main idea is simple:

AI can help write the code.
But the PR should still stay scoped, reviewable, and human-decided.