How it works together

  • Mneme HQ stores architectural decisions in .mneme/project_memory.json — typed, scoped, versioned
  • A single export command generates a .cursorrules file from the active decision corpus
  • Mneme's precedence engine resolves conflicts before export — Cursor sees a clean, non-contradictory rule set
  • You edit decisions in Mneme; re-export to update Cursor Rules

What Mneme adds to the workflow

  • Source of truth is structured JSON — not the .cursorrules file itself
  • Conflict resolution happens in Mneme before Cursor ever sees the rules
  • Decisions carry rationale, supersedes, and status fields — .cursorrules carries none of this
  • When you add Claude Code to the stack, Mneme's hook-level enforcement applies automatically — no migration

Setup

pip install mneme-hq
# Export active decisions to .cursorrules
mneme export --format cursor-rules > .cursorrules

Recommended workflow

  1. Record decisions via /mneme-record (Claude Code) or edit project_memory.json directly
  2. Re-export before opening Cursor: mneme export --format cursor-rules > .cursorrules
  3. Commit both files — Mneme corpus is the source, .cursorrules is the derived surface

If you use Cursor and Claude Code

Running both editors against the same codebase? Mneme keeps them consistent without duplication:

  • Cursor sessions use the .cursorrules export for context injection
  • Claude Code sessions use the PreToolUse hook for enforcement
  • Both draw from the same Mneme corpus — one authoritative source, two surfaces

See how they compare. For a detailed breakdown of what each tool does and where they overlap, read the full comparison: Mneme HQ vs Cursor Rules →

What changes when you wire Mneme into Cursor

Cursor's strength is interactive coding: an engineer types intent, the editor surfaces context, the model responds. The .cursorrules file is how that context arrives at the model. Without governance, the file accumulates ad-hoc rules that the editor injects on every session — useful for personal preferences, weak as architectural enforcement.

With Mneme, the rules become a generated artifact rather than a hand-edited file. The decision corpus in project_memory.json is the source of truth; mneme cursor generate writes a scoped .cursor/rules/mneme.mdc file that Cursor picks up automatically. Three things change in practice:

  • Rules get version-controlled with the code. Architectural decisions live in the same repo and same review process as the rest of the codebase. Changes show up in PR diffs.
  • Conflicts get resolved deterministically. When two rules overlap (e.g. team-wide vs service-specific), the precedence engine picks the more specific scope. Cursor sees a single resolved view.
  • The same corpus drives every other surface. Claude Code hooks and the GitHub Actions enforcement gate read the same JSON. The Cursor session, the terminal session, and CI all enforce the same decisions without duplication.

FAQ

Does Mneme replace Cursor Rules entirely?
No — Mneme generates the Cursor Rules file from a structured source. Cursor still reads .cursor/rules/ at session start; the difference is that the file is now a derived artifact with precedence resolution and version history rather than a manual document. See the full comparison.
Can I edit .cursorrules directly while Mneme is in place?
You can, but the next regenerate will overwrite it. The recommended workflow is to update project_memory.json and re-run mneme cursor generate. That way the change is tracked as a decision-record edit rather than a quiet rule-file change.
Does this work with Cursor's MCP integration?
Yes. Mneme is on the roadmap to expose its decision store as an MCP server; once shipped, Cursor's MCP-aware sessions can query the corpus directly without going through the rules file. See the standards landscape.