Cursor rules: teaching Cursor how you actually work

Ahmet Karaca · 2026-10-12

Where Cursor looks

• Project rules — files in the project's .cursor/rules folder, committed with the code. Each one can apply always, only to matching files, or when the agent decides it is relevant.
• User rules — your own instructions in Cursor's settings, applied in every project.
• MCP servers — tools Cursor can call during a task, configured in .cursor/mcp.json in your home folder or in a project. Nothing from them is loaded until the agent asks.

Rules are read as text at the start of a request, so everything in an always-on rule is paid for every time. Scope a rule to the files it is about whenever you can.

What makes a rule worth keeping

A rule earns its place when it changes what Cursor does. "Write clean code" changes nothing; "read the existing file before proposing a new one" does. The best source of such rules is the corrections you have made: every time you said "no, not like that", the default was wrong in a way a rule could fix.

Write the reason with the rule when it is not obvious. A model that knows why you avoid hard-coded numbers will apply it to a case you never mentioned.

---
description: How I like changes to be made
alwaysApply: true
---

- Read the existing file before proposing a new one.
- Ask before deleting files or running destructive commands.
- Plan in a few lines before touching more than three files.
- Formulas over hard-coded numbers.

The same person, in every tool

If you use more than one assistant, each keeps its own copy of you: a Cursor rule here, a CLAUDE.md there, a custom instruction somewhere else. They drift apart, and the one you edited last is the only one that is current.

The way out is to keep the picture in one place and let each tool read it. MCP makes that possible: Cursor, Claude, Claude Code and Codex can all call the same local server, so a rule added once is seen everywhere.