Cursor's .cursorrules file works like a CLAUDE.md — it loads into context and shapes how the AI behaves in your project. Most people either don't have one or use a generic template that doesn't do much.
Here are the rules that actually change behavior.
The scope rule (most important)
Minimal footprint. Only modify files directly required for the task. Do not refactor adjacent code, add comments to files you didn't change, or fix issues outside your scope. If you notice other problems, note them as TODO comments but do not implement fixes.
This stops Cursor from editing 6 files when you asked it to change one. Without it, "fix this function" can cascade into types, callers, tests, and config — all "improvements" you didn't ask for.
The verification rule
Do not say work is complete until tests pass. Show the test output. If tests don't exist for the changed code, note it.
Without this, Cursor says "done" when the code compiles. With it, done means verified.
The no-confirmation rule
Do not ask for confirmation before making edits. Make the edit and report what you changed.
Saves the back-and-forth of approving every step.
Stack-specific rules that matter
For Next.js App Router:
This project uses Next.js 15 App Router. Do not use Pages Router patterns. Use Server Components by default — only add 'use client' when the component needs browser APIs or event handlers. Do not use useEffect for data fetching.
For TypeScript:
Strict mode is enabled. No 'any' types. No type assertions unless required. Run tsc --noEmit after changes.
For Python/FastAPI:
Use async functions for all endpoints. Validate input with Pydantic models. Never use bare except:. Log errors with context (include relevant IDs).
The general principle
Rules that say what Cursor MUST do work. Rules that say what Cursor SHOULD prefer don't work. "Never use array index as key" is a rule. "Prefer to avoid using array index as key" gets ignored.
Build a free .cursorrules file at builtbyzac.com/tools/cursorrules-generator.html
Top comments (0)