Your Cursor rules have a governance problem, not a rules problem

The directory everyone has

Most teams that adopt an AI coding assistant end up with a .cursor/rules/ directory. Someone enthusiastic writes it in an afternoon, announces it in the team channel, and for a few weeks it works. Then it quietly stops. The author still follows it. Two colleagues who were in the room when it was written follow it. Everyone else has drifted to their own habits, their own prompts, their own idea of what the assistant should do.

Nobody decided this. The rules were never wrong. They simply had nobody looking after them, no way to change, and no way to tell whether they were changing anything.

That is not a rules problem. Better wording will not fix it. It is a governance problem, and it has the same three parts governance always has: who owns it, how it changes, and how you know it works.

Why a mandate does not take

The usual first move is to announce the rules and ask everyone to follow them. It produces a few people who read them once, a majority who assume nothing changes for them, and a file that ages until someone deletes it as out of date.

The reason is not laziness. A rule someone did not help write, and cannot connect to a defect they have personally seen, has no weight against whatever the model was going to produce anyway. People defend rules that explain their own incidents. They tolerate rules that arrived from elsewhere.

So the adoption that works starts before any rule is installed: a week of collecting, in one shared document, every AI-assisted change that had to be caught in review or in production. An invented config key. A route with no auth check. A test that asserted a mock. That list becomes the foundation — each rule you install is presented as the answer to entries on it, and any rule that answers nothing on it is removed rather than kept "just in case".

Ownership: one name, everyone proposes

A ruleset with no owner grows by accretion until nobody reads it. A ruleset with one owner and no contributors becomes that person's file, and leaves with them.

What works is a single named owner who does not decide matters of taste. Their job is narrower: hold the budget for what is always loaded, and make sure a proposed change gets decided rather than discussed forever. Anyone can propose a change, through normal code review, with an approval from someone other than the owner. Rotating the role every few months keeps it from turning into a personal fiefdom.

The owner refuses two things on sight: a rule with no named failure behind it, and a rule added to the always-on file without another one leaving it.

A budget for what is always loaded

Every rule in the always-on file competes for the model's attention on every request. When guidance about migrations is attached while someone edits a stylesheet, the model attends to all of it a little and follows none of it closely. The failure is silent: the rules are still in the directory, they have just stopped changing the output.

The defence is a hard budget for the always-on part, with everything else scoped to the paths where it applies. Once there is a budget, adding an always-on rule means removing one or scoping it. That is unpopular the first time it is enforced, and it is what keeps the set working months later.

A change process with a threshold

The change process can be short:

1. Someone hits a defect and adds it to the incident list, with a date.
2. If the same kind of defect recurs, they open a change to the rules that quotes the incidents and says which existing rule failed to cover them.
3. The owner and one other person review it, and the change is announced in one line.

The recurrence threshold matters. A rule per incident produces a document nobody reads. Waiting for the second occurrence filters out the one-offs.

Deleting belongs in the process too. A rule that has never been quoted in a review, for a failure that has not come back in months, is describing a solved problem. A rule that contradicts another teaches the model that the rules are approximate. Removing them is a success, not a loss: a set that only grows is a set that stops being read.

Measuring without a dashboard

"It feels better" is what every team says about anything it has just adopted. To know whether the rules are doing anything, take a baseline before installing them and look at a few signals a person can gather by hand:

• Review comments per merged change, split into defects and preferences. Both should fall.
• Recurrence on the incident list: entries that fall into a pattern a rule already covers should approach zero.
• Production defects by shape: fabricated identifiers, missing guards, silent fallbacks, tests that could not have failed.
• Time from opened to merged, as a guardrail: if review time rises sharply, the rules have a cost someone should decide to accept.

What not to measure is just as useful: lines of code, the share of code that is AI-generated, or a "compliance rate" that would require judging every change against every rule.

Where to start

Cursor Rules Team System is built around this: seven rules with a small always-on baseline, and three documents that carry the governance — ADOPTION.md for the four-week rollout that starts with the incident list, GOVERNANCE.md for ownership, the word budget, the change process and deletion, and MEASURING.md for the four signals. ANTI-PATTERNS.md lists the ways team rule sets die. It is written for teams of roughly three to thirty engineers; below that you need rules, not governance.

For the structural side of the question — which decisions a team ruleset has to keep consistent in the first place — see Cursor rules that scale beyond one developer. And for what one framework-specific ruleset inside that system looks like, see why AI-written Laravel code passes review and fails in production.