I went through 20 public .cursorrules files on GitHub to see what developers are actually writing. Most of them are reasonable. A few patterns kept showing up that consistently cause problems.
The problems
Rules that describe intent instead of behavior
The most common issue. Things like:
Write clean, maintainable code.
Follow best practices.
Use modern patterns.
These tell Cursor nothing. "Clean" and "best practices" are subjective. Cursor has to guess what you mean, and it guesses based on training data from millions of repos, not your codebase.
Rules need to be specific enough that a reasonable developer could check compliance. "All components go in src/components/" is checkable. "Write clean code" is not.
Rules that only cover the happy path
A lot of .cursorrules files define conventions for new code but say nothing about how to handle existing code. Then Cursor adds a new helper function in a style that contradicts everything already in the file.
Add a section explicitly about consistency:
Before adding new code, read nearby code in the same file.
Match the style of existing code even if it differs from these rules.
Only apply these rules when there's no existing pattern to follow.
Too many rules
Several of the files I looked at had 80+ rules. The longer the list, the more rules get ignored. Cursor (and the model underneath) weights rules at the top of context more heavily.
Rule of thumb: if you have more than 20 rules, you probably have duplicates or rules that don't actually matter. Cut to the ones that would cause a real problem if violated.
No negative constraints
Rules stated as preferences ("prefer X") are weaker than rules stated as prohibitions ("never Y"). If there's a pattern you really don't want, say so explicitly:
Never create files outside of src/.
Never add inline styles.
Never import from ../../../ (use path aliases instead).
The negative form removes the option from consideration rather than just down-ranking it.
What the good ones had in common
The most useful .cursorrules files I saw were short (under 30 lines), covered the things that actually caused problems (not aspirational ideals), and included explicit file paths and patterns rather than general guidance.
One file I found had exactly this at the top:
If you're unsure where a file goes or what to name it, ask before creating.
One line. Stops 80% of the structural drift.
I compiled 30 rules like these into a Cursor Rules Starter Pack — organized by project type (Next.js, Python, Node.js, TypeScript) with notes on what each one prevents. builtbyzac.com/cursor-rules.html, $19.
Top comments (0)