DEV Community: Hideaki Kubo

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

Hideaki Kubo — Sat, 27 Jun 2026 14:44:29 +0000

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

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.

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.

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

Dogfooding a Human-Controlled AI PR Workflow with Cursor and Claude

Hideaki Kubo — Thu, 25 Jun 2026 07:54:34 +0000

I recently updated the public LogFabric website using Cursor, Claude, and a human-controlled PR workflow.

This was not a demo.

It was a real website PR, and I used it to dogfood my own cursor-pr-discipline workflow.

The old website copy was still focused on Stripe post-payment operations.

The current focus is different: human-controlled AI PR workflows for Cursor.

So I opened a small PR and used my own workflow while doing the update.

What I’m building

I’m building cursor-pr-discipline.

It is a lightweight workflow governance pack for Cursor users who use AI-assisted coding but still want pull requests to stay:

scoped
reviewable
human-decided

The goal is not to make AI autonomous.

The goal is to make AI-assisted work easier to review before a human decides what gets merged.

The PR scope

The initial scope was simple:

Update the public homepage copy to align with cursor-pr-discipline Pro Pack v0.

The files eventually changed were:

index.html
privacy.html
terms.html

The important part was not just changing the homepage.

The privacy policy and terms page also needed to match the new product direction.

Otherwise, the homepage would say one thing, while the legal/supporting pages would still describe an older product idea.

How I used Cursor

I used Cursor for the first pass.

The instruction was intentionally narrow:

Only modify the homepage copy.

Cursor quickly updated the main landing page from the old post-payment operations positioning to the new Human-controlled AI PR workflow positioning.

It updated the hero, product sections, roadmap, and calls to action.

This part was fast.

The useful part was not that Cursor “did everything.”

The useful part was that it produced a reviewable change quickly.

Where the human review mattered

After the homepage looked good, I checked for old business terms.

I searched for terms like:

Stripe
post-payment
subscription
Webhook
MongoDB
early access

The homepage was clean.

But while checking the site manually, I noticed something else:

The footer links worked, but the privacy policy and terms page content still described the old product direction.

That was a human judgment point.

The PR scope had to be updated.

Not expanded randomly.

Updated deliberately.

The new scope became:

Update the public LogFabric website copy to align with cursor-pr-discipline Pro Pack v0.

Files in scope:

index.html
privacy.html
terms.html

Out of scope:

README changes
layout redesign
product ZIP changes
.cursor/rules/
unrelated implementation work

How I used Claude

For the privacy policy and terms page, I used Claude with a narrow instruction.

The task was not to create a complex legal document.

The task was to remove old product references and align the pages with the current product model:

digital ZIP product
delivered through Gumroad
Cursor .mdc rules
examples
decision templates
no customer repository access
no customer production secrets
no custom setup support
rules are instructions, not enforcement

Claude updated only privacy.html and terms.html.

Then I reviewed the result manually.

What I did not delegate to AI

I did not delegate the final decision.

The human-controlled parts were:

deciding the PR scope
deciding that privacy and terms pages were in scope
checking old wording
checking local links
reviewing the final diff
committing only the intended files
confirming .cursor/ was not committed
creating and merging the PR
checking the live website after merge

This is the point of the workflow.

AI can propose and edit.

But the human decides what belongs in the PR and whether it should be merged.

One important detail: local rules were not committed

During the dogfooding, I used local Cursor rules.

But those rule files were not part of the website PR.

They were local working materials.

Before pushing, I removed the local .cursor/ directory and confirmed the working tree was clean.

That matters because workflow rules and product files should not accidentally leak into unrelated PRs.

Result

The PR updated the public website copy and supporting pages.

It was merged.

The live site was checked after merge.

The workflow worked as intended:

Cursor helped move quickly.

Claude helped with a narrow follow-up edit.

The human kept the PR bounded, reviewed the public-facing consistency, and made the merge decision.

Takeaway

For AI-assisted development, the risky part is not only whether the AI can generate code or copy.

The risky part is whether the work stays scoped and reviewable.

In this small PR, the pattern was:

AI assisted.

Human reviewed.

Human decided.

That is the workflow I want cursor-pr-discipline to support.

Free Pack on GitHub: https://github.com/logfabricteam/cursor-pr-discipline
Pro Pack v0 on Gumroad: https://kubo03.gumroad.com/l/cursor-pr-discipline

Why AI-assisted PRs expand, and how Cursor Project Rules can help

Hideaki Kubo — Tue, 23 Jun 2026 07:58:02 +0000

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.

How to try it now

The free repo includes three .mdc rules and a small scoped PR example:

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

Copy the .mdc files into your project's .cursor/rules/ directory, then try a small task in Cursor and watch whether the PR stays scoped.

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.

How do you manage AI scope creep in your own workflow?

Do you use Cursor Project Rules, custom prompts, review checklists, or something else?