At Atlan, we’ve been living and breathing Cursor for a few months now.

We’ve tested it with background agents, AI-assisted PRs, code generation, bug fixes and many more, pushing the boundaries of AI-assisted development to the next level. Some of it has been surprisingly good. Some of it? Not so much.

But if there’s one thing we’ve learned, it’s this:
None of it works well without good rules.

That’s where Cursor rules come in — those quiet little .mdc files inside .cursor/rules/ that most people overlook are how you teach the AI about your project, tech stack, and workflows. They turn generic responses into contextually perfect code.

Why Rules Actually Matter

Before we dive into types and templates, let’s pause for the why.

Every Cursor feature — autocomplete, codegen, bug fixes, even background agents — becomes significantly better when the AI is working with your playbook(rules).

Well-written Rules are how you: 

• Make the AI smarter – understands your tech stack and project intent
• Make it Safer – avoids anti-patterns or breaking conventions
• Make it faster – fewer wrong suggestions = less backtracking
• Make it consistent  – becomes a memory extension of your team
  

Basically: Good rules = fewer “what is it doing?” moments.

Different Rule Types (and When to Use What)

Once you start writing rules in Cursor, you’ll quickly realize… not all rules are created equal.

Some should apply to everything you do in the project.
Some only make sense when you’re working in certain files.
Others should only kick in when Cursor is doing a specific task — like fixing a bug or writing a test.

So how do you tell Cursor when to use which rule?

That’s where rule types come in. You’re not just writing rules, you’re setting conditions for when those rules get applied. And that can completely change how smart (or confused) the AI becomes.

There are four main types. Each one is built for a different use case:

Each has its use. You’ll likely use a mix.

The 4 Kinds of Rules Every AI-Native Project Should Cover

So now you know that why rules are important and when to use what “Rule Types”.

But when it’s actually time to write your own rules — staring at that empty .mdc file , the big question hits:

“What kind of rules should I even write?”

Not every rule needs to be a masterpiece. But we think that every AI-native project should cover these four areas. Think of them as your AI rule scaffolding — the structure that helps Cursor behave more like a teammate, less like a confused intern.

Let’s break them down:

1. Project Rules

These rules tells AI what this project is, how it’s structured, and what matters most.

It’s like handing Cursor your README, onboarding doc, and architectural guide — but written in a way that AI actually understands.

Without this, Cursor is flying blind. It doesn’t know how your folders are laid out, what @src/components/ means, or which patterns are sacred vs. accidental.
So it guesses. And that’s how you end up with suggestions like utils/legacy/cursor-this-is-the-wrong-folder/.

Best for: Project overview, setup, project-structure, git guidelines, architecture, glossary, change-propagation etc.
Rule Type: "Always"

2. Tech Stack and Guidelines

This is where you capture your team’s technical preferences and conventions — the shared understanding of how your codebase works.

Think of this as your engineering playbook:

• How we write TypeScript
• How React components are structured
• How APIs are named and versioned
• How folder structures are organized

These rules create alignment. They help Cursor speak your language, follow your conventions, and avoid those “hmm, that’s not how we do it here” moments.

You’re turning what would usually live in onboarding calls and scattered docs into a clear, structured reference — for both humans and the AI.

They’re assertive. They remove ambiguity. They make collaboration smoother, especially when multiple devs (and one AI) are building in parallel.

Basically, by setting up these, you’re telling the AI how your team likes to work, so everyone gets faster, smarter, and more consistent code and Cursor becomes an extension of your best practices.

Best For: React patterns, API guidelines, naming conventions, tests, commands, utilities etc.
Rule Type: "Always" (core languages) or "Agent Requested" (specific tools)

3. Micro Workflows

If Tech Stack rules” are about how we write code, Micro Workflow rules are about how we behave.

They document the repeated, often subconscious patterns your team follows while building. For example:

• How we log and monitor things
• How we use feature flags
• What a migration should always include
• How we structure events or user actions

These aren’t language-level rules. They’re team habits.

And once the AI knows them, it starts feeling less like a helpful assistant, and more like a teammate who already gets how your org works.

And because these behaviors happen all the time, across features, across teammates — the impact of getting them right compounds fast.
Fewer reminders. Fewer code comments. Fewer tiny mistakes that slow things down.

Cursor gets smarter. Your team moves faster. And your defaults become your superpower.

Best For: Auth wrappers, logging structure, when to use feature flags, DB migrations, event tracking, error handling etc.
Rule Type: "Agent Requested" or "Manual"

4. Meta Rules

Okay, this one’s underrated.
These are “rules about you rules”.

They’re the layer most people skip, but they’re often what makes the whole system actually work.

Meta Rules guide Cursor on how to interpret, prioritize, and apply all the other rules you’ve written.

Think of them like principles, not policies.

• When should one rule take precedence over another?
• What should the AI do when no rule matches?
• Should rules in subfolders override global ones?

These questions might seem edge-casey — until they’re not.
Because once you start working with multiple rules across different contexts, clarity beats cleverness.

A good Meta Rule setup makes Cursor feel less like a patchwork of rules… and more like a cohesive, opinionated system.

You’re basically writing a rule engine… for your rule engine.

Best For: Rule prioritization, cursor rule structure, context management, conflict resolution,  mcp guides etc.
Rule Type: "Always"

Rule Writing Philosophy
(Or: Things I Wish I Knew on Day 1)

Writing great rules isn’t about sounding smart — it’s about being insanely clear.

Think of it like onboarding the world’s fastest, most literal intern.
Writing great rules isn’t about sounding smart — it’s about being insanely clear.

Think of it like onboarding the world’s fastest, most literal intern.
The better you teach it, the better it builds.

Here’s what we’ve learned makes a difference, and what we wish we knew when we started.

Be Assertive, Not Suggestive

This is the first trap most people fall into.

LLMs don’t handle nuance well. If you’re vague, they’ll guess , and guessing AI is unpredictable AI.

So instead of this:
"Consider using TypeScript interfaces"

Say this:
"Always define TypeScript interfaces for component props"

You’re not writing documentation. You’re giving instructions.
Use action words. Be direct. Be unmissable.

Ask yourself: Would I say this out loud to a junior dev on my team? If not, rewrite it.

Place Important Context Last

This one surprised us more than it should have.

We noticed that Cursor was often ignoring the most important part of our rules — the nuance, the edge cases, the “this only applies if…” stuff.

Turns out, LLMs often prioritize information at the end of a rule file.
So we flipped the order:

1. What to do
2. How to do it (with examples)
3. Why it matters

It felt weird at first, but once we tried it, we started seeing better responses almost immediately.

Extract Reusable Patterns

If you’re anything like us, you’ll start noticing the same rule fragments popping up again and again.

Rather than repeating yourself, extract them. Cursor supports @include, which lets you reuse shared snippets across files.

# In .cursor/rules/setup.mdc

@include ../shared/setup.md

This keeps your rules clean and prevents the dreaded “outdated copy-paste” problem.

When Rules Don’t Work – Debugging Rules

Even with all the right intentions, sometimes Cursor still gets it wrong.
And when that happens, the instinct is to blame the AI. But 9 times out of 10, it’s the rule.

Here’s a quick checklist we wish we had sooner:

• Is your rule type correct?
  For example, Agent Requested rules only kick in if they’re well-described, meaning they need context to know when to apply.
• Do your glob patterns match real files?
  A small typo here means your rule silently never gets picked up.
• Is the rule too vague?
  Cursor doesn’t like “maybe.” Be specific, or the rule gets ignored.
• Want to test it fast?
  Try calling the rule manually with @rule-name.mdc in chat to force apply it and see what happens.

Sometimes, it’s not broken — it just needs a nudge in the right direction.

Advanced Features You’ll Love

Let’s say you’re vibing with Cursor now and you’ve got a few rules, things are working, and AI feels less annoying.
Here’s what you’ll want to explore next:

Generate From Chat

This one’s easy to miss, but super powerful.

Let’s say you’re chatting with Cursor, correcting its code or refining a response.
Once you feel like, “Yep, that’s exactly how we do it,” then don’t let it disappear.

Instead, run: /Generate Cursor Rules

Cursor will turn that conversation into a reusable .mdc rule, capturing everything it just learned from you.

No need to rewrite it yourself. No need to remember it next time.
Just teach it once → turn it into a rule → reuse forever.

Bonus: You can also run /generate cursor rules [brief description] to get a head start from scratch, even without a conversation.

Enable Memories

Go to Cursor Settings → Rules → Toggle on “Memories”
This makes your rules persist across sessions, so you don’t have to reteach it every time you reopen a file or project.

It’s like giving Cursor a long-term memory

It’s a massive upgrade for long-running projects or tools with lots of moving pieces

Use Subdirectory Rules

Yes, you can scope rules to subfolders.

Just drop .cursor/rules/ inside any subdirectory, and Cursor will apply those rules locally.

Great for monorepos, plugin-heavy systems, or just staying organized.

You Don’t Have to Start From Scratch

1. Cursor Directory

Visit cursor.directory for pre-built rules for popular frameworks:

• React + TypeScript rules
• Python + FastAPI rules
• Next.js project rules
• And many more tech stacks

2. GitHub Goldmine

Check out community collections:

• awesome-cursorrules – Curated list of great rules
• Search “cursor rules” + your tech stack on GitHub
• Browse real project .cursor/rules directories

Pro tip: Start with existing rules, then customize for your specific needs.

3. Your own conversations

Some of your best rules are buried in your chat history. Use them.

After a productive chat where you’ve refined AI behavior, run:
/Generate Cursor Rules

Or if you want to start from scratch, even without a conversation, run:
/Generate Cursor Rules [ description of rule you want or more instruction ]

Getting Started: Start Small, Iterate Often

You don’t need a library of rules to see results. Just a few well-written ones can change how Cursor works for your team.

Here’s a solid way to begin:

1. Start with these 4 kinds of rules
Define one rule in each of the four categories we talked about:

• Project Rule: What this project is and how it’s structured
• Tech Stack Rule: How your team writes code
• Micro Workflow Rule: How your team behaves (logging, flags, etc.)
• Meta Rule: How Cursor should interpret and prioritize your rules

This gives Cursor the baseline context it needs, without writing a whole thesis.

2. Watch for pain points
Every time you think “ugh, it did that again” — that’s your cue to write a new rule.

3. Keep it tight
Aim for ~1 concept per rule. Under 50–80 lines is a good benchmark. Quality > verbosity.

4. Extract reusable bits
Use @include to share logic across rules and keep things DRY.

# In .cursor/rules/setup.mdc
@include ../shared/setup.md

5. Review monthly
Rules are code — refactor them like code.
Update what’s old. Delete what’s stale. Keep it clean.

Conclusion

Good rules don’t just help Cursor perform better.
They help your team perform better.

Because at the end of the day, rules are just a way of turning what your team already knows — the habits, the patterns, the “we always do it this way”, into something Cursor can actually use.

You stop repeating yourself.
You stop fixing the same stuff over and over.
The AI starts pulling its weight.

And suddenly, it doesn’t feel like a tool you’re babysitting, but rather a teammate who gets it.

If there’s one thing we’d recommend: don’t wait around trying to write the perfect rules.
Just start with a few.
Project. Tech stack. A workflow. Maybe a meta rule.
Then pay attention to where the AI fumbles, and then teach it better next time.

That’s how you get from “What is this Cursor even doing?” to “Whoa, that’s exactly how we would’ve done it.”

Pick one pain point. Write one rule. Try it.
You’ll see the difference. We did.