What Cursor Rules are
- A
.cursorrulesfile (plain text) placed at the root of a repo - Injected as system prompt preamble when Cursor opens a session in that directory
- Written manually — no schema, no typed fields, no version tracking
- One flat file per repo — the same rules apply to every file regardless of context
- Cursor-native: they only work in the Cursor editor
- Suggestions: the model receives them as instructions but can still ignore or contradict them
Cursor Rules solve a practical problem: you want the model to know your project conventions without pasting them into every prompt. For individual developers in Cursor, they work well within those limits.
What Mneme HQ does differently
| Dimension | Cursor Rules | Mneme HQ |
|---|---|---|
| File format | Plain text (.cursorrules) | Structured JSON (typed fields: id, scope, status, rationale, supersedes) |
| Enforcement | Model suggestion — can be ignored | Hook-level blocking on Edit/Write operations |
| Scope | Whole repo — same rules everywhere | Per-file glob pattern matching (e.g. services/payments/**) |
| Conflict resolution | None — conflicts resolved by the model | Deterministic precedence engine |
| Decision versioning | No status field, no history | draft / active / superseded with supersedes chain |
| Multi-agent support | One file per repo | Shared decision corpus queryable by all agents |
| AI editor | Cursor-native only | Claude Code-native (hooks API) |
| Open source | Feature of Cursor (closed) | Self-hosted, MIT licence |
| Cross-team sharing | Committed per repo, no central registry | Queryable corpus; team-wide policies possible |
When Cursor Rules are sufficient
- You use Cursor as your primary editor and have no plans to change
- You are a solo developer — no multi-engineer or multi-agent workflows
- Your rules apply uniformly to every file in the project
- Suggestions are acceptable — you don't need a violation to actually block
- You have no conflicting rule sets (org policy vs team exception, for example)
- You don't need to track when a decision changed or why it was superseded
When Mneme HQ is required
- You use Claude Code. Cursor Rules only work in Cursor. Mneme HQ integrates directly with Claude Code's hooks API — it operates at the Edit/Write operation level, not at the editor level.
- Your rules are context-specific. A flat
.cursorrulesfile cannot distinguish betweenservices/payments/**andanalytics/**. Mneme HQ's glob-scoped rules enforce the right constraints for the right files. - You need a violation to be stopped. Cursor Rules are injected as context — the model may still generate the forbidden thing. Mneme HQ's hooks block the Edit/Write operation before it lands.
- Your rules conflict. Org-wide policy vs team override vs individual exception — without a precedence model, conflict resolution falls to the model's judgment. Mneme HQ resolves conflicts deterministically.
- You run AI agents. Agents don't read system prompts the way an interactive session does. Hook-level enforcement is the only governance that applies uniformly to both human and agent sessions.
- Decision history matters. When a rule was introduced, when it was superseded, and why — Mneme HQ tracks this. A rules file doesn't.
The fundamental distinction: Cursor Rules are configuration — a text file the model is asked to respect. Mneme HQ is enforcement — a hook that runs at operation time and blocks violations before they happen. For teams where architectural boundaries must hold, configuration is not enough.
If you use both Cursor and Claude Code
Many engineering teams use Cursor for interactive coding and Claude Code for agentic tasks (refactoring runs, code generation pipelines, automated PR workflows). In that setup, Cursor Rules cover the Cursor sessions and Mneme HQ covers the Claude Code sessions.
They don't conflict — they operate on different editors. But only Mneme HQ provides enforcement at the hook level. If a rule violation matters enough to block, it needs to be in Mneme HQ regardless of which editor it originated from.
The migration path
Teams that have already written .cursorrules files can treat them as a starting point for Mneme HQ's decision corpus. The rules are the same — the difference is converting them into typed JSON entries with scope, status, and rationale fields, then enabling hook-level enforcement.
For a deeper look at how the two differ in practice, see the editorial comparison: Mneme vs Cursor Rules.