@Roei_Shoustak, thanks for coming back to this specific point. Your answer about several months of real-world use is exactly what was missing from the thread.
I fully agree with the second point, and I think it’s underrated. If a rule has no “why”, it’s scary to delete because no one remembers whether something depends on it. The agent also has nothing to guide it when two rules conflict. Even a single line like Source: PR #123, 2026-08 right in the rule already gives the model a reason to prefer the newer one. That costs nothing and works in plain markdown.
The third point can be partially covered with built-in tools. In .cursor/rules/*.mdc, a rule can be tied to paths with globs and only gets included when those files are in context: Rules | Cursor Docs. The weak spot is exactly what you’re describing. If a path gets renamed, the rule silently stops firing, and no one finds out. So I’d add a CI check that fails if a glob or path from the rules and AGENTS.md matches nothing. The drift-check utility I mentioned above does roughly that: Built a small CLI to detect AGENTS.md drift (missing commands, dead paths, conflicting nested files)
Two questions for you:
- What do you do with rules that aren’t about a specific file, but about a concept? Something like “use pnpm” doesn’t point to any path. One option is to tie it to an artifact that confirms the rule, like
pnpm-lock.yaml. I’d be curious how you handle that. - In your 3,905 files, what was the most common anti-pattern? Duplication between
CLAUDE.mdandAGENTS.md, or outdated commands?