Setting Up Cursor Rules So the AI Stops Breaking Your Codebase Style

My first month with Cursor, every agent edit worked and still felt wrong — tabs where my repo uses spaces, default exports in a codebase of named ones, tests written in a style our CI rejects. The fix was not better prompting. It was rules files, set up properly.

Cursor reads rules from .cursor/rules in your repo. Start with one project-level rules file covering the non-negotiables: package manager, import ordering, naming conventions, and the two or three patterns your codebase uses that differ from common defaults. Keep it under about 50 lines — a rules file nobody maintains becomes noise the model learns to ignore.

The underrated feature is per-directory rules. Our components directory gets a rule: function components only, props typed inline, no default export. Our server directory gets another: no client-side imports, every handler validates input. This split did more for output quality than anything I wrote in the global file, because the model only sees the rules that apply to the files it is touching.

Three rules earned their place through pure repetition. First: 'After editing, run the existing lint command and fix all errors you introduced.' Second: 'Match the import style of the file you are editing, not the style you prefer.' Third: 'If a change requires a new dependency, stop and ask instead of installing.' That last one came after I found five new packages in a diff that needed one.

What I stopped doing: repeating style instructions in every chat message. With rules in place, my prompts describe intent — what to build, what to avoid — and the rules file handles the house style. The prompt got shorter and the output got more consistent, which is the whole game.

One maintenance habit: when the agent repeatedly makes the same mistake, add a rule instead of scolding it in chat. Chat corrections die with the conversation; rules files compound. My rules file has grown by about two lines a week, and each line has a bug fix behind it.

Frequently asked questions:

Q: Do rules files slow Cursor down?

A: Not noticeably. They are injected into context alongside your prompt. The real cost is a bloated rules file diluting attention, which is why I cap mine and delete rules the codebase has outgrown.

Q: Should rules be committed to the repo?

A: Yes, if you want the whole team to benefit — treat them like a linter config. Keep personal preferences in the user-level rules instead of the project file.

Q: How are rules different from just writing a good system prompt?

A: Rules apply automatically to every request in their scope, survive across sessions, and are versioned with the code. A system prompt in your head benefits nobody but you and evaporates every time you start a new chat.