Cursor Rules Not Working? Here's Why (And the Fix)

#ai #cursor #webdev #programming

If Cursor rules aren't working, you're not alone. You wrote .cursor/rules (or a legacy .cursorrules file) telling the agent to use named exports, Zod validation, and your error-handling pattern — and the agent still generates default exports and skips validation.

This usually means one of three things:

The rules file is in the wrong place or format
The rules are too vague for the model to prioritize
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

This is the most common complaint from teams adopting AI coding tools. The agent has strong defaults; your rules compete with open files, chat history, and generic model behavior.

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.

Fix: Check Cursor's docs for your version and migrate to the current rules directory structure.

Cause 2: Rules compete with everything else

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.

I wrote more about 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 forever, 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 push

Teammates clone the repo and Cursor picks up the same skill — no per-developer rule files, no copy-paste.

(Free for individuals and OSS repos; team workspaces have a trial on codehabits.dev/pricing.)

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 automated extraction own the long-lived patterns.