Cursor System Prompt Rules Explained

Cursor is the AI code editor that put system prompts into millions of developers' hands. Every Cursor project has its own customizable rules file (.cursorrules or the newer .cursor/rules/ directory) that sits on top of Cursor's built-in system prompt. Most developers never touch it, which is a missed opportunity. A well-written project rules file dramatically improves the quality of Cursor's suggestions.

To draft Cursor rules from scratch with a structured starting point, use the free system prompt generator with the Code Assistant template — output is copy-ready for the rules file.

How Cursor Layers System Prompts

Cursor's actual system prompt that the model sees is built from three layers:

1. Cursor's built-in system prompt — internal, set by the Cursor team. This handles things like file editing format, diff syntax, and basic coding conventions. You cannot modify it directly.
2. User rules — your global preferences across all projects. Set in Cursor Settings → Rules.
3. Project rules — specific to one project. Lives in .cursor/rules/ (or the older .cursorrules file at the project root).

The three layers are concatenated into a single system prompt at request time. Project rules typically take precedence over user rules for the active project.

What Goes in Project Rules

The most valuable content for project rules is the stuff Cursor cannot infer from your code:

• Stack details — "This project uses React 18, TypeScript strict mode, Tailwind 3, Vitest"
• Conventions — "Functional components only. No class components. Use hooks for state."
• Naming — "Files use kebab-case. Components use PascalCase. Variables use camelCase."
• Forbidden patterns — "Do not use any. Do not use console.log in shipped code. Do not import from /utils — use /shared instead."
• Project-specific knowledge — "This is a SaaS for fitness studios. Users are gym owners. Voice should be professional but warm."
• External integrations — "We use Stripe for payments, Postmark for email, Sentry for errors. When suggesting integration code, use these specific libraries."

Common Cursor System Prompt Mistakes

Watching r/Cursor and the Cursor Discord, the most common rule-writing mistakes are:

• Too long — rules over 1,000 tokens cause Cursor to ignore parts of them. Keep rules under 500 tokens.
• Vague directives — "write good code" is meaningless. "Use early returns instead of nested if/else" is actionable.
• Conflicting rules — "be concise" plus "explain every choice in detail" cancel each other out.
• Stale rules — rules written for an old version of the stack still in the file after migration. Rules go stale fast — review them quarterly.
• Copying someone else's .cursorrules — they were written for a different stack and project. They will produce wrong output for yours.

Sell Custom Apparel — We Handle Printing & Free Shipping

A Project Rules Template That Actually Works

Here is a working baseline you can adapt:

"You are a senior engineer working on [project name]. The stack is [list]. Use [conventions]. Never use [forbidden]. When suggesting changes, read the existing file first and match its style. Show only the lines that need to change in diffs — do not repeat unchanged code. Ask one clarifying question if a request is ambiguous before generating code. Admit when you don't know something — never invent APIs or library functions."

That is roughly 100 tokens. Add stack-specific details and you have a tight, effective rules file.

When to Use User Rules vs Project Rules

User rules apply across every project. Use them for personal preferences that hold no matter what code you are writing — preferred coding style, comment style, your name in commit messages, your timezone for date references.

Project rules apply only to the active project. Use them for stack-specific, codebase-specific, or domain-specific knowledge. The split exists because most developers work on multiple projects with different stacks — bundling everything into one global rules file produces conflicting behavior.

Updating Rules as You Learn

The best Cursor rules files are not written once and forgotten. They are updated every time you catch Cursor doing something wrong. If Cursor keeps suggesting console.log debugging when you use a logger, add "use the logger module, never console.log" to your rules. The next session, the suggestion goes away.

Treat the rules file as living memory of your team's coding standards. Every fix you have to make twice is a candidate for a new rule.