Cursor Memories: How They Work vs Rules and Skills

Cursor Memories are short, sentence-sized facts that Cursor's agent saves about you and your project — "this repo uses pnpm, not npm," "prefer named exports," "tests live next to the source file" — and automatically pulls into future conversations. They get created in two ways: Cursor proposes them in the background while you chat, or you explicitly tell the agent to remember something. They're scoped to the project you're working in and personal to your Cursor setup.

That last part is the detail most teams miss. Memories are not rules: they don't live in your repo, they aren't versioned, and your teammates never see them. This guide covers how memories get created, where they fit next to rules and skills, how to audit and delete them, and how to promote a good memory into a shared rule your whole team gets.

What Cursor Memories are and how they get created

Think of memories as Cursor's attempt to stop you from repeating yourself. Rules are context you wrote down deliberately; memories are context Cursor extracted from your behavior. There are two creation paths:

1. Automatic extraction from chat

While you work in agent chats, a background process watches for durable facts — corrections you make repeatedly, preferences you state, project conventions you explain. When it spots one, it proposes a memory. Cursor asks for your approval before a background-generated memory is saved, which is the right default: an unreviewed memory is an invisible system prompt you never agreed to.

Typical auto-extracted memories look like:

- The user prefers arrow-function components with named exports.
- This project uses Vitest, not Jest. Do not import from "jest".
- Database access goes through the repository layer in src/db/repos/.

2. Explicit "remember this" requests

You can also create a memory on demand. Just say it in chat:

Remember: all API errors in this repo must use the AppError class
from src/lib/errors.ts, never raw throw new Error().

The agent stores it as a memory and applies it in later sessions. Explicit memories tend to be higher quality than auto-extracted ones because you chose the wording — treat the memory text like a mini rule, not a chat message.

Memories vs rules vs skills: the mental model

The cursor memories vs rules question comes down to one axis: who is the context for, and who controls it?

A workable mental model:

• Memories are what Cursor learned about you.
• Rules are what your team decided about this repo. See the complete guide to Cursor rules for how .mdc files, globs, and alwaysApply work.
• Skills are what your team packaged as a reusable capability — instructions plus supporting files that work across tools, covered in our Cursor skills guide.

Memories are one form of Cursor persistent context, but they're the weakest form for anything that matters to more than one person. If a fact would cause a code-review comment when violated, it belongs in a rule or a skill, not a memory.

Reviewing, approving, and deleting memories

Memories accumulate silently, and a stale memory is worse than no memory — it keeps steering the agent toward a convention you abandoned months ago. Audit them like you'd audit a dotfile:

1. Open Cursor's settings and find the Rules & Memories section (in older versions, memories are listed under Rules). You'll see every saved memory for the current project.
2. Approve or reject pending memories. Background-generated memories wait for your sign-off. Read each one critically: is it true, is it durable, and is it phrased as an instruction the agent can actually follow?
3. Delete anything stale or wrong. Migrated from Jest to Vitest? Delete the Jest-era memories. If a memory contradicts a current rule, the ambiguity alone degrades output — remove it.
4. Rewrite vague memories as explicit ones. If an auto-extracted memory captured the right idea with mushy wording, delete it and dictate a sharper version in chat: "Remember: [precise instruction]."
5. Repeat monthly, or whenever the agent starts making a mistake you're sure you corrected before. A contradictory memory set is a common cause.

The bar for keeping a memory: you'd be comfortable seeing it silently prepended to every prompt you send. Because functionally, that's what it is.

Promoting a memory into a versioned rule

The healthiest lifecycle for a good memory is graduation. When you notice a memory that's really a team convention in disguise, promote it:

1. Find the memory in Cursor's settings and copy its text.
2. Create a rule file in your repo:

mkdir -p .cursor/rules
touch .cursor/rules/error-handling.mdc

3. Write the rule with proper metadata, upgrading the memory's phrasing into a real convention with an example:

---
description: Error handling conventions for API code
globs: ["src/**/*.ts"]
alwaysApply: false
---

All API errors must use the AppError class from src/lib/errors.ts.
Never throw raw Error instances in route handlers.

Correct:
throw new AppError("NOT_FOUND", "Skill not found", 404);

Wrong:
throw new Error("not found");

4. Delete the original memory so the rule is the single source of truth. Keeping both invites drift between two copies of the same instruction.
5. Commit and push. Now every teammate — and every fresh clone — gets the convention automatically. For more patterns worth stealing, browse these real-world .cursorrules examples.

If the convention applies beyond one repo or one tool, take it a step further and publish it as a skill. One published skill can install into every tool your team uses:

npm install -g @localskills/cli
localskills login
localskills publish

# teammates install it into Cursor, Claude Code, and Windsurf at once
localskills install your-org/error-handling --target cursor claude windsurf

The CLI writes each tool's native format — .cursor/rules/*.mdc for Cursor, .claude/skills/ for Claude Code, .windsurf/rules/ for Windsurf — from one versioned source. The localskills docs cover the full publish flow.

Team caveats: memories are personal, rules are shared

If you lead a team, memories deserve a short policy, because their failure modes are all invisible:

• The onboarding blind spot. Your Cursor works great because six months of accumulated memories encode the team's conventions. A new hire clones the repo and gets none of that. Everything a new teammate needs on day one must live in rules or skills, not in anyone's memories.
• Silent divergence. Two engineers correct the agent in slightly different ways, grow slightly different memory sets, and get differently-styled generated code from identical prompts. Nobody can see why, because nobody can see anyone else's memories.
• No review, no history. Rules go through pull requests; memories don't. There's no diff, no blame, no rollback. That's fine for "I prefer terse commit messages" and unacceptable for "we validate all input with zod."
• Machines don't sync through the repo. Memories follow your Cursor setup, not your codebase. A fresh environment starts cold. Rules in git are the only project context guaranteed to survive a re-clone.

The policy that works: memories for personal ergonomics, rules for repo conventions, published skills for anything cross-repo or cross-tool. Teams standardizing across Cursor, Claude Code, and Copilot should read how AI coding rules work across tools before duplicating the same conventions by hand in each format.

Troubleshooting Cursor memories that won't stick

When the agent keeps forgetting something you told it, walk this list:

1. Memories are disabled. Check the Rules & Memories settings — if the feature is off, "remember this" requests get acknowledged in chat and silently dropped.
2. The memory is stuck at pending. Background-generated memories need approval. If you dismissed the prompt, the memory was never saved. Check the pending list in settings.
3. You're in a different project. Memories are project-scoped. A convention memorized in your API repo does not follow you into the frontend repo. Re-create it, or better, promote it to a shared skill.
4. A rule is overriding it. Rules are deliberate context and effectively outrank a mumbled memory. If a rule says "use Jest" and a memory says "use Vitest," fix the rule — that's the file your team actually controls.
5. The memory is too vague to act on. "User cares about error handling" gives the agent nothing. Delete it and dictate a concrete instruction with the exact class names and paths.
6. You're relying on memory for something structural. If the fact must hold on every machine and every branch, memory was the wrong tier from the start. Put it in .cursor/rules/ and commit it.

Cursor Memories FAQ

What's the difference between Cursor Memories and a memory bank?

A cursor memory bank is a community pattern, not a Cursor feature: you maintain structured markdown files in the repo (project brief, active context, progress log) and instruct the agent via rules to read and update them each session. It's shareable and versioned because it's just files in git, but it depends entirely on prompt discipline. Native memories are automatic and zero-maintenance but personal and unversioned. Plenty of teams run both: a memory bank for shared project state, native memories for individual preferences.

Are Cursor Memories shared with my team?

No. Memories are personal to your Cursor setup and never enter the repository. Anything your team depends on should be a committed rule or an installable skill — those travel with the code.

Can I turn Cursor Memories off?

Yes. The Rules & Memories section of Cursor's settings has a toggle. Some teams disable auto-generated memories entirely and keep all persistent context in reviewed, committed rules — a reasonable call in regulated codebases where every instruction the AI receives should be auditable.

Should coding standards live in memories or rules?

Rules, always. Memories are best for low-stakes personal preferences. A standard that isn't versioned and visible isn't a standard — it's a habit one person's editor happens to have. Promote it to a rule, and if it applies across repos or tools, publish it as a versioned skill.

---

Got a memory your whole team should have? Create a free localskills account and publish it as a versioned skill that installs into Cursor, Claude Code, Windsurf, and more.

npm install -g @localskills/cli
localskills login
localskills publish