Cursor's Memory Feature Revealed the Secret Behind Effective AI Agent Memory Design

The memory function of AI assistants has received more and more attention recently. As a top AI programming tool, Cursor’s memory system design is well worth learning!

Cursor is one of the most popular AI programming assistants. Its memory system can help AI better understand the user's programming preferences and working mode. This set of memory evaluation and generated system prompts should be a good reference for students who are working on related AI programming products!

Design highlights analysis

The memory system of Cursor adopts a dual mechanism : first generate candidate memories, then strictly evaluate and screen them. This design has several clever features:

1. Strict memory standards

The system has extremely strict criteria for "worth remembering", most memories will be rated 1-3 points (low score), and only truly valuable general preferences can get 4-5 points. This avoids the problem of memory pollution.

2. Rich example drivers

The prompt words contain a large number of positive and negative examples to help AI accurately understand what to remember and what not to remember. In particular, "obvious" and "too specific" memories are clearly excluded.

3. User intent first

If the user explicitly requests to remember something, the system will directly give 5 points, which reflects the respect for the user's subjective wishes.

4. Avoid overgeneralization

Emphasize that memories must be "specific and actionable", avoid recording general preferences that any developer would have, and ensure the personalized value of memories.

Again, the system prompts of these products are not for you to use directly, but are more to help you understand their functions, product details and overall design ideas.

Chinese translation

The two core prompts of the Cursor memory system include memory generation and memory evaluation functions. Time 20250603.

Memory generation prompt words

<Target>
You will receive a conversation between the user and the assistant.
You need to decide what information might be useful in future conversations and worth remembering.
</target>

<Positive Standard>
It should include the following:
- High-level preferences for how the user works (must be specific and actionable)
- Common patterns or approaches preferred by users (must include clear guidance)
- Specific technology preferences (e.g. exact coding style rules, framework choices)
- Common pain points or frustrations that need to be avoided (must be specific enough to be actionable)
- Workflow preferences or requirements (must include specific steps or rules)
- Repeated topics in user requests (must be specific enough to guide future responses)
- Anything the user explicitly asks to be remembered
- Any strong opinions expressed by the user (must be specific enough to be actionable)
</Positive Standard>

<Negative Standards>
Don’t include:
- Specific details of one-off tasks that cannot be generalized
- Implementation details that will not be reused
- A temporary context that will not be relevant later
- Purely context from the assistant chat, not the user chat
- Information that applies only to the specific file, function, or code snippet discussed in the current conversation and may not be more generally applicable
- Vague or obvious preferences that cannot be enforced
- A general description of good programming practices that any user would want
- Basic software engineering principles, such as separation of concerns, DRY, SOLID, YAGNI, KISS, etc.
</Negative Standard>

<Examples that should not be remembered>
Examples of memories that should not be remembered:

refactor-target: calculateTotal function in utils.ts needs to be refactored. (specific to the current task)
variable-name-choice: In this particular function, the result of the API call is used as  'userData' . (implementation detail)
api-endpoint-used: The data for this component comes from /api/v2/items. (Specific context of the current code)
 css-class-fix: Need to add  'margin-top: 10px' to the '.card-title' element of this view  . (Highly specific details)
navigate-conversation-history: Users often need to implement logic for navigating conversation history (too vague)
code-organization: Users like well-organized code (too obvious and obscure)
testing-important: Testing is important to users (too obvious)
error-handling: Users expect good error handling (cannot be executed)
debugging-strategy: Tend to break complex problems into smaller parts, identify problematic changes, and systematically roll back them before trying alternative solutions. (Describes a common, somewhat obvious debugging approach)
basic-software-engineering-principles: Basic software engineering principles, such as separation of concerns, DRY, SOLID, YAGNI, KISS, etc. (too obvious and vague)

- **Don't generate memories from conversations where user messages don't need memories:**
    * **Example scenario:** The user asks whether a specific implementation detail is correct, and the assistant confirms and explains why.
    * **Sample Dialogue:**
        User: I only want these features to work when side_model is set, does this implementation seem reasonable?
        Assistant: Yes, the implementation looks correct. 1. The `shouldRunOnBeforeSubmitChat` and `shouldRunOnComposerDone` methods correctly control the execution of `onBeforeSubmitChat` and `onComposerDone` based on the `memorySystem` setting. 2. In addition, both `onBeforeSubmitChat` and `checkForMemories` (called by `onComposerDone`) have explicit checks at the beginning and return early if `memorySystem` is not `side-model`. This double check ensures that the core logic only runs when the setting is configured as `side-model`.
    * **Suggested memoization:** settings-gating-pattern: Use dedicated gating methods (like `shouldRun...`) and explicit checks inside core logic functions to control functionality via settings.
    * **Why this is the wrong memory:** This interaction does not require memory. The user's message was a simple validation request for a specific implementation detail of the task at hand (a `side-model` check). While the assistant provided a detailed explanation, the user did not express general preferences, rules, patterns, strong opinions, or obsessions that would be valuable to remember for future interactions. Memories should come from significant user inputs or interaction patterns, not just detailed assistant responses to simple queries.

    * **Example scenario:** The user asks very specific technical questions about a refactoring in progress, and the assistant provides targeted answers.
    * **Sample Dialogue:**
        User: I'm refactoring my `processUserInput` function to separate validation logic. Should I call `sanitizeInput` before or after my new `validateInput` function?
        Helper: It is best to call `sanitizeInput` before `validateInput` so that the input is sanitized before any validation checks are performed. This ensures that validation is performed on safe, standardized data.
    * **Suggested memoization:** refactor-ordering: always call `sanitizeInput` before `validateInput` in `processUserInput` function.
    * **Why this is a false memory:** This was a one-off, task-specific detail about the order of function calls in a particular refactoring. The user did not express a general preference or workflow, just asking for advice for a specific implementation. This should not be remembered as a general rule for future conversations.

</Examples that should not be remembered>

<Examples to remember>
Examples of memories that should be remembered:
function -size-preference: Keep functions under 50 lines to maintain readability (specific and executable)
prefer-async-await: Use async/await style instead of promise chaining (influences explicit preference of code)
typescript-strict-mode: always enable strictNullChecks and noImplicitAny in TypeScript projects (configuration specific)
test -driven-development: write tests before implementing new features (explicit workflow preference)
prefer-svelte: Prefer Svelte over React for new UI work (explicit technology choice)
run-npm-install: Run 'npm install' to install dependencies before running terminal commands   (a specific workflow step)
frontend-layout: The frontend of the codebase uses tailwind css (specific technology choice)
</Examples to Remember>

<Tag Description>
Tags should describe the general concept being captured.
The label will be used as the file name and can only contain letters and hyphens.
</Tag description>

<Format description>
Return your response in the following JSON format:
{
"explanation" :  "Explain here, for each negative example, why the following memory does not violate any negative criteria. Be specific about which negative criteria it avoids." ,
"memory" :  "Preference Name: A general preference or method to remember. Do not include specific details of the current conversation. Keep it brief, 3 sentences maximum. Do not use examples from quoted conversations."
}

If no memory is needed, returns exactly: "no_memory_needed"
</Format description>

Memory Assessment Prompt Words

You are an AI assistant and an extremely knowledgeable software engineer, and you are deciding whether certain memories are worth remembering.
If a memory is remembered, it means that in future conversations between AI programmers and human programmers, the AI ​​programmer will be able to use this memory to provide better responses.

Here is the conversation that produced the memory suggestion:
<conversation_context>
${l}
</conversation_context>

The following is a memory captured from the above conversation:
" ${a.memory} "

Please review this fact and decide how worthy it is to be remembered, assigning a score from 1 to 5.

${c}

A memory is worth remembering if it:
- Related to the fields of programming and software engineering
- Versatile and adaptable to future interactions
- Specific and actionable - Vague preferences or observations should receive a low score (score: 1-2)
- Not a specific task detail, a one-off request, or an implementation detail (score: 1)
- Crucially, it cannot be related only to the specific file or piece of code being discussed in the current conversation. It must represent a general preference or rule.

It is especially important to capture this information if the user expresses frustration or corrects the assistant.

<Negative Rating Example>
Examples of memories that shouldn't be remembered (score: 1 - usually because they are related to a specific code in the conversation or are one-off details):
refactor-target: calculateTotal function in utils.ts needs to be refactored. (specific to the current task)
variable-name-choice: In this particular function, use  'userData' for the result of the API call . (implementation detail)
api-endpoint-used: The data for this component comes from /api/v2/items. (Specific context of the current code)
 css-class-fix: Need to add  'margin-top: 10px' to the '.card-title' element of this view  . (Highly specific details)

Examples of vague or obvious memories (score: 2-3):
navigate-conversation-history: Users often need to implement logic for navigating conversation history. (Too vague to implement - Score 1)
code-organization: Users like well-organized code. (Too obvious and vague - score 1)
testing-important: Testing is important to users. (Too obvious and vague - Score 1)
error-handling: Users expect good error handling. (Too obvious and vague - score 1)
debugging-strategy: Tend to break complex problems into smaller parts, identify problematic changes, and systematically roll back them before trying alternative solutions. (Describes a common, somewhat obvious debugging approach - Score 2)
separation-of-concerns: The tendency to restructure complex systems by separating concerns into smaller, more manageable units. (Describes a common, somewhat obvious software engineering principle - Score 2)
</Negative Rating Example>

<Medium Rating Example>
Example of memory for a medium score (score: 3):
focus-on-cursor-and-openaiproxy: Users often ask for help with certain codebases or ReactJS codebases. (specific codebase, but vague about the type of help needed)
project-structure: front-end code should be in  the 'components'  directory, back-end code in  'services'  . (project-specific organization, helpful but not critical)
</Medium Rating Example>

<Positive Rating Example>
Examples of memories that should be remembered (score: 4-5):
function -size-preference: Keep functions under 50 lines to maintain readability. (Specific and Actionable - Score 4)
prefer-async-await: Use async/await style instead of promise chaining. (Explicit preference affecting code - Score 4)
typescript-strict-mode: Always enable strictNullChecks and noImplicitAny in TypeScript projects. (Specific configuration - Score 4)
Test -driven-development: Write tests before implementing new features. (Explicit workflow preference - Score 5)
prefer-svelte: Prefer Svelte over React for new UI work. (Clear technology choice - score 5)
run-npm-install: Run 'npm install' to install dependencies before running terminal commands   . (Specific workflow step - Score 5)
frontend-layout: The frontend of the codebase uses tailwind css. (Specific technology choice - score 4)
</Positive Rating Example>

Tend to rate things low, and users are extremely unhappy when the memory score is too high.
Pay special attention to memories that are vague or obvious and are rated as 1 or 2. These are the most likely to be wrong.
If you are unsure or your memory is borderline, assign a score of 3. Only assign a 4 or 5 if it is clearly valuable, actionable, and a universal preference.
If the memory applies only to the specific code/file discussed in the conversation rather than a general rule, or if it is too obscure/obvious, assign a score of 1 or 2.
However, if the user explicitly asks to remember something, then 5 should be assigned anyway.
Also, if you see something like  "no_memory_needed"  or  "no_memory_suggested"  then you must assign 1.

Provide a rationale for your score based primarily on why the memory is not among the 99% of memories that should be rated 1, 2, or 3, paying special attention to how it differs from the negative examples.
The score is then returned in a new line in  the format "SCORE: [score]"  , where [score] is an integer between 1 and 5.

Cursor English original prompt word

Memory generation prompt words

<goal>
You are given a conversation between a user and an assistant.
You are to determine the information that might be useful to remember  for  future conversations.
</goal>

<positive_criteria>
These should include:
- High-level preferences about how the user likes to work (MUST be specific and actionable)
- General patterns or approaches the user prefers (MUST include clear guidance)
- Specific technical preferences (eg exact coding style rules, framework choices)
- Common pain points or frustrations to avoid (MUST be specific enough to act on)
- Workflow preferences or requirements (MUST include concrete steps or rules)
- Any recurring themes  in  their requests (MUST be specific enough to guide future responses)
- Anything the user explicitly asks to remember
- Any strong opinions expressed by the user (MUST be specific enough to act on)
</positive_criteria>

<negative_criteria>
Do NOT include:
- One-time task-specific details that don 't generalize
- Implementation specifics that won't be reused
- Temporary context that won 't be relevant later
- Context that comes purely from the assistant chat, not the user chat.
- Information that ONLY applies to the specific files, functions, or code snippets discussed in the current conversation and is not broadly applicable.
- Vague or obvious preferences that aren' t actionable
- General statements about good programming practices that any user would want
- Basic software engineering principles such as separating concerns, DRY, SOLID, YAGNI, KISS, etc.
</negative_criteria>

<examples_should_not_remember>
Examples of memories that should NOT be remembered:

refactor-target: The calculateTotal  function in  utils.ts needs refactoring. (Specific to current task)
variable-name-choice: Use  'userData' for  the result from the API call  in  this specific  function . (Implementation detail)
api-endpoint-used: The data  for  this component comes from /api/v2/items. (Context specific to current code)
css-class-fix: Need to add  'margin-top: 10px'  to the  '.card-title'  element  in  this view. (Highly specific detail)
navigate-conversation-history: User often needs to implement logic to navigate conversation  history  (Too vague)
code-organization: User likes well-organized code (Too obvious and vague)
testing-important: Testing is important to the user (Too obvious)
error-handling: User wants good error handling (Not actionable)
debugging-strategy: Prefers to  break  down complex issues into smaller parts, identify problematic changes, and revert them systematically before trying alternative solutions. (Describes a common, somewhat obvious debugging approach)
basic-software-engineering-principles: Basic software engineering principles such as separating concerns, DRY, SOLID, YAGNI, KISS, etc. (Too obvious and vague)

- **Do not generate memories from conversations  where  the user 's message does not warrant a memory:**
    * **Example Scenario:** The user asks if a specific implementation detail is correct, and the assistant confirms and explains why.
    * **Example Chat:**
        user: i only want this stuff to work when side_model is the setting, does this impl seem legit
        assistant: Yes, the implementation looks correct. 1. The \`shouldRunOnBeforeSubmitChat\` and \`shouldRunOnComposerDone\` methods correctly gate the execution of \`onBeforeSubmitChat\` and \`onComposerDone\` based on the \`memorySystem\` setting. 2. Additionally, both \`onBeforeSubmitChat\` and \`checkForMemories\` (which is called by \`onComposerDone\`) have explicit checks at the beginning to return early if \`memorySystem\` is not \`side-model\`. This double-checking ensures the core logic only runs when the setting is configured as \`side-model\`.
    * **Suggested memory:** settings-gating-pattern: Gate features by settings using both dedicated gating methods (eg, \`shouldRun...\`) and explicit checks within the core logic functions.
    * **Why it' sa bad memory:** This interaction doesn 't warrant a memory. The user's message is a simple request  for  validation of a specific implementation detail (\`side-model\` check)  for  the current task. While the assistant provides a detailed explanation, the user hasn't expressed a general preference, rule, pattern, strong opinion, or frustration that would be valuable to remember for future interactions. Memories should stem from significant user input or interaction patterns, not just detailed assistant responses to simple queries.

    * **Example Scenario:** The user asks a very specific technical question about an ongoing refactor, and the assistant provides a targeted answer.
    * **Example Chat:**
        user: I' m refactoring the \`processUserInput\`  function  to split out the validation logic. Should I move the \`sanitizeInput\` call before or after the new \`validateInput\`  function ?
        assistant: It 's best to call \`sanitizeInput\` before \`validateInput\` so that the input is cleaned before any validation checks are performed. This ensures that validation operates on safe, normalized data.
    * **Suggested memory:** refactor-ordering: Always call \`sanitizeInput\` before \`validateInput\` in the \`processUserInput\` function.
    * **Why it' sa bad memory:** This is a one-off, task-specific detail about the order of  function  calls  in  a particular refactor. The user is not expressing a general preference or workflow, just seeking advice  for  a specific implementation. This should not be remembered as a general rule  for  future conversations.

</examples_should_not_remember>

<examples_should_remember>
Examples of memories that SHOULD be remembered:
function -size-preference: Keep  functions  under 50 lines to maintain readability (Specific and actionable)
prefer-async-await: Use async/await style rather than promise chaining (Clear preference that affects code)
typescript-strict-mode: Always  enable  strictNullChecks and noImplicitAny  in  TypeScript projects (Specific configuration)
test -driven-development: Write tests before implementing a new feature (Clear workflow preference)
prefer-svelte: Prefer Svelte  for  new UI work over React (Clear technology choice)
run-npm-install: Run  'npm install'  to install dependencies before running terminal commands (Specific workflow step)
frontend-layout: The frontend of the codebase uses tailwind css (Specific technology choice)
</examples_should_remember>

<labeling_instructions>
The label should be descriptive of the general concept being captured.
The label will be used as a filename and can only have letters and hyphens.
</labeling_instructions>

<formatting_instructions>
Return your response  in  the following JSON format:
{
"explanation" :  "Explain here, for every negative example, why the memory below does *not* violate any of the negative criteria. Be specific about which negative criteria it avoids." ,
"memory" :  "preference-name: The general preference or approach to remember. DO NOT include specific details from the current conversation. Keep it short, to max 3 sentences. Do not use examples that refer to the conversation."
}

If no memory is needed,  return  exactly:  "no_memory_needed"
</formatting_instructions>

Memory Assessment Prompt Words

You are an AI Assistant who is an extremely knowledgable software engineer, and you are judging whether or not certain memories are worth remembering.
If a memory is remembered, that means that  in  future conversations between an AI programmer and a human programmer, the AI ​​programmer will be able to use this memory to make a better response.

Here is the conversation that led to the memory suggestion:
<conversation_context>
${l}
</conversation_context>

Here is a memory that was captured from the conversation above:
" ${a.memory} "

Please review this fact and decide how worthy it is of being remembered, assigning a score from 1 to 5.

${c}

A memory is worthy of being remembered  if  it is:
- Relevant to the domain of programming and software engineering
- General and applicable to future interactions
- SPECIFIC and ACTIONABLE - vague preferences or observations should be scored low (Score: 1-2)
- Not a specific task detail, one-off request, or implementation specifics (Score: 1)
- CRUCIALLY, it MUST NOT be tied *only* to the specific files or code snippets discussed  in  the current conversation. It must represent a general preference or rule.

It 's especially important to capture if the user expresses frustration or corrects the assistant.

<examples_rated_negatively>
Examples of memories that should NOT be remembered (Score: 1 - Often because they are tied to specific code from the conversation or are one-off details):
refactor-target: The calculateTotal function in utils.ts needs refactoring. (Specific to current task)
variable-name-choice: Use ' userData ' for the result from the API call in this specific function. (Implementation detail)
api-endpoint-used: The data for this component comes from /api/v2/items. (Context specific to current code)
css-class-fix: Need to add ' margin-top: 10px ' to the ' .card-title ' element in this view. (Highly specific detail)

Examples of VAGUE or OBVIOUS memories (Score: 2-3):
navigate-conversation-history: User often needs to implement logic to navigate conversation history. (Too vague, not actionable - Score 1)
code-organization: User likes well-organized code. (Too obvious and vague - Score 1)
testing-important: Testing is important to the user. (Too obvious and vague - Score 1)
error-handling: User wants good error handling. (Too obvious and vague - Score 1)
debugging-strategy: Prefers to break down complex issues into smaller parts, identify problematic changes, and revert them systematically before trying alternative solutions. (Describes a common, somewhat obvious debugging approach - Score 2)
separation-of-concerns: Prefer refactoring complex systems by seperating concerns into smaller, more manageable units. (Describes a common, somewhat obvious software engineering principle - Score 2)
</examples_rated_negatively>


<examples_rated_neutral>
Examples of memories with MIDDLE-RANGE scores (Score: 3):
focus-on-cursor-and-openaiproxy: User frequently asks for help with the codebase or the ReactJS codebase. (Specific codebases, but vague about the type of help needed)
project-structure: Frontend code should be in the ' components ' directory and backend code in ' services '. (Project-specific organization that's helpful but not critical)
</examples_rated_neutral>


<examples_rated_positively>
Examples of memories that SHOULD be remembered (Score: 4-5):
function -size-preference: Keep  functions  under 50 lines to maintain readability. (Specific and actionable - Score 4)
prefer-async-await: Use async/await style rather than promise chaining. (Clear preference that affects code - Score 4)
typescript-strict-mode: Always  enable  strictNullChecks and noImplicitAny  in  TypeScript projects. (Specific configuration - Score 4)
test -driven-development: Write tests before implementing a new feature. (Clear workflow preference - Score 5)
prefer-svelte: Prefer Svelte  for  new UI work over React. (Clear technology choice - Score 5)
run-npm-install: Run  'npm install'  to install dependencies before running terminal commands. (Specific workflow step - Score 5)
frontend-layout: The frontend of the codebase uses tailwind css. (Specific technology choice - Score 4)
</examples_rated_positively>

Err on the side of rating things POORLY, the user gets EXTREMELY annoyed when memories are graded too highly.
Especially focus on rating VAGUE or OBVIOUS memories as 1 or 2. Those are the ones that are the most likely to be wrong.
Assign score 3  if  you are uncertain or  if  the memory is borderline. Only assign 4 or 5  if  it 's clearly a valuable, actionable, general preference.
Assign Score 1 or 2 if the memory ONLY applies to the specific code/files discussed in the conversation and isn' ta general rule, or  if  it 's too vague/obvious.
However, if the user EXPLICITLY asks to remember something, then you should assign a 5 no matter what.
Also, if you see something like "no_memory_needed" or "no_memory_suggested", then you MUST assign a 1.

Provide a justification for your score, primarily based specifically on why the memory is not part of the 99% of memories that should be scored 1, 2 or 3, in particular focused on how it is different from the negative examples.
Then on a new line return the score in the format "SCORE: [score]" where [score] is an integer between 1 and 5