Cursor Rules vs. Memories: What Belongs in Each

Cursor rules are explicit instructions you maintain; Memories refers to context captured from conversations for later use. Put an approved requirement in a rule, and treat a remembered observation as something to verify before making it a requirement.

The distinction matters when an assistant turns a temporary workaround into the default approach. Tools like fenbs keep project decisions and progress outside one editor, so the next supported assistant can check what people approved. Keep editor instructions focused on how to work with the code.

What is the practical difference?

Cursor’s rules documentation↗ (opens in a new tab) describes project rules stored as files and user rules set for your environment. A rule supplies instructions to an assistant; it does not change the underlying model permanently. Think of it as a reusable briefing that must reach the relevant session.

Memory suggests a different starting point: something the assistant learned from an interaction. That observation may be useful without being an instruction. “The import test failed on this branch” describes a result. “Run the import test before finishing changes to the importer” describes a working rule.

Are Memories available in every Cursor setup?

Do not assume that an old screenshot matches your installation. Cursor’s Memories introduction↗ (opens in a new tab) described facts remembered from conversations, stored per project for an individual and managed in Settings. A later official update↗ (opens in a new tab) described approval for memories generated in the background.

Those announcements establish how the feature was described, not universal availability in every current account. The former Memories page↗ (opens in a new tab) redirects to Cursor’s documentation home, while the current rules guide describes its supported instruction types. Check the controls actually present before following a memory-specific tutorial.

If you do not see Memories, you can still write explicit instructions and maintain a project handoff. You do not need to weaken privacy settings or change your working setup merely to reproduce someone else’s interface. Choose a method whose contents you can inspect today.

What belongs in an explicit rule?

Use a rule for a stable requirement that a person can review. Good candidates include the project’s test command, the location of generated files, or an instruction to check existing patterns before adding a new dependency. Each should explain a concrete action rather than demand that the assistant “be careful.”

For a hypothetical reporting app, compare these instructions: “Make good exports” and “When changing a CSV export, preserve the existing column names unless a person approves the change.” The second tells the assistant what matters and when it needs a decision. It is also possible for a reviewer to check.

• Name the situation in which the instruction applies.
• State the expected action or constraint.
• Point to the relevant code or reference when a short link is enough.
• Keep the approval boundary visible when a change affects users.
• Remove obsolete instructions when the project deliberately changes direction.

Cursor supports rules that always apply, rules selected for relevant work, rules attached to matching files, and rules invoked manually. Choose the narrowest appropriate scope. A rule about export files need not fill every conversation about page layout.

Our Cursor rules examples offers more instruction patterns. For the mechanics of file matching, use the separate rule file-pattern guide rather than expanding a memory comparison into a configuration manual.

What belongs in remembered context?

Remembered context is most useful when it saves rediscovery without pretending to settle a decision. Say you explored a legacy import path and learned that one customer format uses a different date order. That observation needs evidence and scope before it becomes a rule for every import.

Review a proposed memory for overgeneralization. A one-time instruction to skip a slow check during investigation should not turn into a permanent instruction to omit testing. A preference you expressed while drafting a comment should not override the project’s published documentation standards.

Ask three questions: what happened, how do we know, and does it still apply? If you cannot answer them, keep the point tentative. If a person approves a lasting change, write that approval explicitly instead of waiting for an assistant to infer it from the conversation.

For a lasting project choice, fenbs Decisions and rules keeps the person’s decision and reason available alongside the work. This avoids making an individual editor memory carry the authority of a team agreement.

Where do rules and memories fail?

A clear rule can still be irrelevant to a particular task, out of date, or contradicted by another instruction. A memory can preserve an incomplete interpretation of a conversation. Both need maintenance, and neither replaces checking the assistant’s proposed changes.

When behavior surprises you, examine one concrete example. Identify the file being changed, the instruction you expected to apply, and what the assistant actually did. Then ask it to identify the instruction it used. Its explanation is a diagnostic clue, so compare it with the visible rules and the resulting edit.

Avoid solving every miss by adding another paragraph. First remove the contradiction, correct the scope, or simplify the instruction. More text can give the assistant more competing directions. A short, testable requirement is often easier for a person to maintain than a long collection of repeated warnings.

A small review exercise helps. Start a fresh session on a harmless change and ask the assistant to explain the relevant requirement before editing. Then inspect whether the edit follows it. If the requirement is absent, investigate how it was supplied; if it is present but misunderstood, rewrite the instruction with a concrete example. This separates a delivery problem from an unclear sentence without guessing that the assistant has forgotten the entire project.

Keep changing status out of permanent rules. “The parser is half finished” belongs with the current task. “Do not change the public format without approval” belongs with the project’s requirements. Mixing them leaves yesterday’s progress looking like today’s instruction.

Which approach should you choose for a team?

Choose explicit, reviewable instructions for conventions everyone must follow. Keep their wording close to the code where reviewers can check whether a proposed change updates both behavior and guidance. Personal preferences should stay personal unless the team agrees otherwise.

Use remembered observations as a convenience where your setup supports them. Do not make another teammate depend on your private recollection. If the information changes what someone else should do, give it a visible home with enough evidence for them to evaluate it.

The guide to Cursor rules for AI projects covers building a useful instruction set, while our Cursor overview explains the wider editor. The decision here is smaller: separate approved requirements from observations and changing progress.

How to do this with fenbs

1. Create a free account and add one active project with its current tasks.
2. Record a real approved choice in Decisions and rules. Include who decided, the reason, and whether it is a continuing rule or a choice for this case.
3. Connect Cursor through Integrations using MCP, a standard way for an AI app to use an outside tool. Approve the connection in your browser.
4. Ask Cursor to read project context before working. Keep repository-specific instructions in Cursor rules and record changing task progress in fenbs.
5. Before stopping, save Where we left off with the remaining work and checks. Ask the next connected assistant to read it before proposing changes.

fenbs does not import Cursor Memories or automatically synchronize rule files. It is not the right fit if all you need is a personal instruction inside one editor. Start when you need decisions and handoffs to survive a change of session, assistant, or teammate.

Try one ordinary handoff: record the approved export format, the completed parser work, and the test still waiting to run. A fresh session should be able to distinguish those three facts. Explore the AI memory hub when you need to extend the same discipline to other work.