I spent way too long figuring out Cursor rules. Here's what actually worked for me

Ok so I've been building a full-stack app (React + Express + Supabase + some AI stuff) and my cursor rules situation was a mess for months. Started with one big `.cursorrules` file, kept adding to it, and eventually realized Cursor was just... ignoring most of it.

Took me a while to figure out why, but it clicked when I started thinking about it in terms of tokens. Every rule you load eats context window. Context window is literally all Cursor can "think about" at once. So stuffing 2000 lines of rules into always-on files is like handing someone a manual and asking them to keep the whole thing in their head while writing code. Of course it drops stuff.

So I rebuilt my whole rules setup around one question: what does Cursor actually need to know *right now* for *this specific task*?

# What I landed on (the 2-4-2 thing)

8 files, three tiers. Not because 8 is magic but because thats what my project needed.

**2 always-on files.** These load on every conversation so they have to be short. Like, under 200 lines each, ideally shorter.

First one is basically project context. If a new developer joined tomorrow, what would they need to know before touching anything? The tech stack, folder structure, where important files live, and the handful of rules that are never ok to break. For me those are things like language/direction requirements, brand colors, and some domain-specific stuff. This file answers "what are we even building."

Second one is code standards. Naming conventions, file size limits, how we handle errors, TypeScript rules, that kind of thing. Stuff that applies no matter what part of the codebase you're in. This answers "what does good code look like here."

Thats it for always-on. Everything else is conditional.

**4 auto-attached files** that activate based on file globs. Each one covers a "zone" of the codebase:

* Frontend (`client/src/**`): component library, design system, data fetching patterns, i18n/RTL stuff
* Backend (`server/routes.ts`, etc): API patterns, middleware, reponse formats, auth per role
* Database (`server/supabase.ts`, `shared/schema.ts`): query patterns, RLS, schema conventions
* AI/ML (various AI files): model integration, prompt standards, how to handle when AI returns garbage

These only load when you're actually editing files that match the globs. So if I'm working on a React component, Cursor gets the frontend rules but doesn't waste context on database query patterns. These can be longer since they're not always loaded, mine are like 150-300 lines.

The zone split will be different for every project obviously. A Next.js app probably needs fewer. The principle is just: group by domain, not by file type.

**2 agent-requested files.** These are the ones people sleep on. Cursor reads the description you write and decides on its own whether to pull them in.

I have one for security (auth flows, token handling, access control, env variables) and one thats basically a new feature checklist. The checklist one is great because when Cursor is building something end to end it reminds itself to think about database migrations, route guards, loading states, cache invalidation, all the stuff you forget at 2am.

The security one alone has caught so many missing auth middleware situations. Worth the setup time just for that.

# Why bother with all this

Honestly the main reason is Cursor actually listens to shorter focused files. I don't have data to back this up but after months of using both approaches, the difference is night and day. With one giant file it would follow maybe 60% of my conventions. With this setup its closer to 90%.

Also maintanence. Updating one focused file when your API patterns change is easy. Hunting through a 1500 line mega-file to find the relevant section and hoping you dont break some other rule in the process... not fun.

And you stop getting those wierd situations where rules contradict each other because you wrote one section in January and another in March and forgot about the first one.

# Things I learned the hard way

Your rules should describe *how* to build, not *what* to build. Patterns and conventions, not feature specs. "Every route must validate input and return errors" is a good rule. "The login page should have a forgot password link" is not.

Tell Cursor what NOT to do. Seriously. My frontend rules explicitly list libraries it shouldn't install because it kept trying to add axios when we already have fetch, or moment when we have date-fns. Saved me a lot of cleanup.

Use real file paths in your rules. Don't say "follow the established pattern." Say "follow the patterns in `client/src/hooks/useDataCache.ts`." Cursor can actually go read that file then. Game changer.

Be absolutely ruthless about what goes in always-on files. Every single line in those files gets processed on every single message. If something only matters when you're touching the database, it goes in the database file, period.

For the agent-requested files, the description field is everything. Write it like you're telling a coworker when they should grab this binder off the shelf. "Security patterns, auth flows, token handling, RLS policies" works way better than just "security stuff."

And review your rules regularly. Stale rules are genuinely worse than no rules because Cursor will confidently follow patterns your codebase has moved on from. I try to look at mine every couple weeks, takes like 20 minutes.

# TLDR

Stop putting everything in one file. Split your rules into tiers based on when Cursor actually needs them: always-on (keep tiny), auto-attached by file globs (bulk of your rules), and agent-requested for cross-cutting stuff. The specific number of files doesn't matter, the tiering principle does.

Happy to answer questions. Curious how others are handling this too.



*Edit: this is for the* `.cursor/rules/` *system with* `.mdc` *files, not the old single* `.cursorrules` *file. If you haven't migrated yet the glob-based auto-attach alone makes it worth it.*