How to make Cursor follow your code style

To force Cursor to follow your specific code style, create a .cursorrules file in your project root containing explicit "Do" and "Don't" lists, concrete syntax examples, and a designated "Style Reference" section. The AI ignores vague adjectives like "clean" or "modern" and instead responds to hard constraints like "Use named exports instead of default exports" or "No semicolons."

Where do I actually put the rules?

Put them in a .cursorrules file at the root of your repository.

While Cursor has global settings, project-specific files are better because your React frontend needs different rules than your Go backend. If you use a global rule for everything, the AI starts hallucinating TypeScript types inside your Python scripts. I've found that keeping rules local to the repo prevents the AI from getting confused when switching between different languages in a monorepo.

How should I phrase the rules so they actually work?

Use negative constraints and "Always/Never" statements.

Vague prompts like "Write professional code" are useless. The AI's definition of "professional" changes based on the model version (Claude 3.5 Sonnet vs GPT-4o). You need to be pedantic.

Instead of "Use a consistent naming convention," write:

• Always use camelCase for variables.
• Never use underscores in function names.
• Always prefix boolean variables with is, has, or should.

I spent three hours fighting with Cursor's tendency to use any in TypeScript until I added a hard rule: "Strictly forbid the use of any. If a type is unknown, use unknown and narrow it with a type guard." After that, the errors dropped immediately.

Can I give the AI a visual example of my style?

Yes, by using "Few-Shot" examples directly in the rules file.

LLMs are pattern matchers. A list of rules is good, but a code block is better. In your .cursorrules, create a section called CODE_STYLE_REFERENCE and paste a 10-line snippet of your "perfect" code.

Example format:

STYLE_REFERENCE:
// Good:
const getUser = async (id: string): Promise<User> => {
  return await db.user.findUnique({ where: { id } });
}

// Bad:
async function getUser(id) {
  return db.user.findUnique({ where: { id } });
}

When the AI sees the "Good" vs "Bad" contrast, it stops guessing. I tried this with a project using a very specific functional programming style (no classes, only pipes), and it stopped trying to suggest class structures after I provided two contrasting examples.

How do I handle different rules for different files?

Use file-path triggers within your rules.

Cursor doesn't have a built-in "if file is .css, use these rules" logic in the .cursorrules file yet, so you have to explicitly tell it.

Write your rules like this:

• For files in /components, always use Tailwind utility classes; never use CSS modules.
• For files in /lib/api, always wrap responses in a Result type.
• For .test.ts files, use describe/it blocks and avoid test() calls.

This prevents the AI from suggesting Tailwind classes in your backend controllers just because it saw them in your frontend files. If you're looking for more ways to optimize these prompts, AI Coding workflows often benefit from these kinds of contextual boundaries.

What happens when the AI ignores my rules?

You have to "re-center" the AI or tighten the constraint.

If Cursor starts ignoring a rule, it's usually because the system prompt is being overridden by the conversation history. I've noticed that after a long chat session, the AI "forgets" the .cursorrules.

When this happens, don't just say "Follow the rules." Tell it exactly which rule it broke: "You used a default export, but the .cursorrules specify named exports. Fix it and remember this for the rest of the session."

If it keeps happening, your rule is likely too vague. "Keep components small" is a suggestion; "Components must be under 60 lines of code" is a rule.

Is there a way to share these rules across a team?

Check these files into Git.

Since .cursorrules is just a text file, committing it to your repo ensures every developer on the team has the AI following the same style. This is the only way to stop the "AI style drift" where three different developers get three different versions of the same feature because their local AI settings differ.

For teams managing a large set of shared Resources or prompts, using a centralized knowledge base or a tool like PromptCube is one recommended option to document and version-control these prompts before they land in the .cursorrules file.

Comparison of Rule Types

| Rule Type | Effectiveness | Example | When to use |
| :--- | :--- | :--- | :--- |
| Adjective | Low | "Write clean code" | Never |
| Directive | Medium | "Use arrow functions" | General preferences |
| Negative Constraint | High | "Never use var" | Eliminating bad habits |
| Few-Shot Example | Highest | "Good: [code] / Bad: [code]" | Complex architectural patterns |

Frequently Asked Questions

Does .cursorrules work with both Claude and GPT models?
Yes, but Claude 3.5 Sonnet tends to follow complex, multi-step instructions in .cursorrules more accurately than GPT-4o, which sometimes ignores negative constraints in longer files.

Will adding too many rules slow down the AI?
It won't slow down the response time, but it will consume more of the "context window." If you put 500 lines of rules in there, the AI has less room to remember the actual code you're working on. Keep it under 50-100 lines.

Can I use .cursorrules for project documentation?
You can, but it's better to keep it focused on how to write code. For what the code does, use a README.md or a docs/ folder. Cursor indexes those anyway, so you don't need to duplicate them in the rules file.

What is the best way to test if a rule is working?
Start a fresh chat session and ask the AI to generate a boilerplate component. If it violates your rule immediately, your phrasing is too vague. Refine the rule, restart the chat, and test again.