Cursor Rules Not Working? Here's Why (And the Fix)
If your .cursor/rules or .cursorrules file is being ignored, you're not alone. Here's the common causes — and how team intelligence from PR history solves the problem permanently.
Cursor rules not working usually means one of three things: the rules file is in the wrong place, the rules are too vague for the model to prioritize, or the conventions you wrote don't match what your team actually enforces in PR review. Cursor rules are static instructions you maintain by hand — they don't learn from your PR history unless you rebuild them constantly.
Symptom: Cursor ignores your rules
You added a .cursor/rules file (or legacy .cursorrules) telling the agent to use named exports, Zod validation, and your error-handling pattern. The agent still generates default exports and skips validation. This is the most common complaint we hear from teams adopting AI coding tools.
Cause 1: Wrong file location or format
Cursor has moved from a single .cursorrules file to the .cursor/rules/ directory with individual rule files. If your rules live in the old location, newer Cursor versions may not load them consistently. Check Cursor's docs for your version and migrate to the current rules directory structure.
Cause 2: Rules compete with everything else
Cursor loads rules alongside open files, chat history, and generic model behavior. Vague rules like "write clean code" lose against strong defaults. Specific, evidence-backed rules work better — but writing them for every convention your team enforces takes hours and drifts out of date. We covered this dynamic in why AI tools ignore your team's patterns.
Cause 3: Rules don't match PR reality
The gap between what you think your team does and what PR review actually enforces is large. A rule file written by one engineer often misses conventions that only appear in review comments — the named-export preference, the ban on console.log, the custom error base class. Without PR-derived evidence, rules are guesswork.
The fix: evidence-ranked team intelligence
Instead of hand-writing rules, extract conventions from merged and closed PRs where your team already enforced them. Codehabits analyzes review comments and code patterns, ranks each convention by confidence, and writes structured intelligence to .codehabits/ plus an Agent Skill that Cursor auto-discovers.
npx @codehabits/cli enable
git add .codehabits/ .cursor/skills/ AGENTS.md
git commit -m "chore: add team intelligence"
git pushTeammates clone the repo and Cursor picks up the same skill — no per-developer rule files, no copy-paste.
When hand-written rules still make sense
Project-specific one-offs (a migration in progress, a temporary API freeze) belong in explicit rules. Team-wide conventions that repeat in every PR belong in intelligence extracted from evidence. Use both: keep short-lived rules in .cursor/rules/ and let Codehabits own the long-lived patterns.