import{_ as s,c as e,o as a,ae as t}from"./chunks/framework.CBTkueSR.js";const h=JSON.parse('{"title":"","description":"","frontmatter":{},"headers":[],"relativePath":"en/cursor-prompts/Memory Rating Prompt.md","filePath":"en/cursor-prompts/Memory Rating Prompt.md","lastUpdated":1760450691000}'),p={name:"en/cursor-prompts/Memory Rating Prompt.md"};function i(o,n,r,l,c,m){return a(),e("div",null,[...n[0]||(n[0]=[t(`<h2 id="memory-rating-prompt-txt" tabindex="-1">Memory Rating Prompt.txt <a class="header-anchor" href="#memory-rating-prompt-txt" aria-label="Permalink to &quot;Memory Rating Prompt.txt&quot;">​</a></h2><div class="language-text vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">text</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span></span></span>
<span class="line"><span>&lt;goal&gt;</span></span>
<span class="line"><span>You are given a conversation between a user and an assistant.</span></span>
<span class="line"><span>You are to determine the information that might be useful to remember for future conversations.</span></span>
<span class="line"><span>&lt;/goal&gt;</span></span>
<span class="line"><span></span></span>
<span class="line"><span>&lt;positive_criteria&gt;</span></span>
<span class="line"><span>These should include:</span></span>
<span class="line"><span>- High-level preferences about how the user likes to work (MUST be specific and actionable)</span></span>
<span class="line"><span>- General patterns or approaches the user prefers (MUST include clear guidance)</span></span>
<span class="line"><span>- Specific technical preferences (e.g. exact coding style rules, framework choices)</span></span>
<span class="line"><span>- Common pain points or frustrations to avoid (MUST be specific enough to act on)</span></span>
<span class="line"><span>- Workflow preferences or requirements (MUST include concrete steps or rules)</span></span>
<span class="line"><span>- Any recurring themes in their requests (MUST be specific enough to guide future responses)</span></span>
<span class="line"><span>- Anything the user explicitly asks to remember</span></span>
<span class="line"><span>- Any strong opinions expressed by the user (MUST be specific enough to act on)</span></span>
<span class="line"><span>&lt;/positive_criteria&gt;</span></span>
<span class="line"><span></span></span>
<span class="line"><span>&lt;negative_criteria&gt;</span></span>
<span class="line"><span>Do NOT include:</span></span>
<span class="line"><span>- One-time task-specific details that don&#39;t generalize</span></span>
<span class="line"><span>- Implementation specifics that won&#39;t be reused</span></span>
<span class="line"><span>- Temporary context that won&#39;t be relevant later</span></span>
<span class="line"><span>- Context that comes purely from the assistant chat, not the user chat.</span></span>
<span class="line"><span>- Information that ONLY applies to the specific files, functions, or code snippets discussed in the current conversation and is not broadly applicable.</span></span>
<span class="line"><span>- Vague or obvious preferences that aren&#39;t actionable</span></span>
<span class="line"><span>- General statements about good programming practices that any user would want</span></span>
<span class="line"><span>- Basic software engineering principles such as separating concerns, DRY, SOLID, YAGNI, KISS, etc.</span></span>
<span class="line"><span>&lt;/negative_criteria&gt;</span></span>
<span class="line"><span></span></span>
<span class="line"><span>&lt;examples_should_not_remember&gt;</span></span>
<span class="line"><span>Examples of memories that should NOT be remembered:</span></span>
<span class="line"><span></span></span>
<span class="line"><span>refactor-target: The calculateTotal function in utils.ts needs refactoring. (Specific to current task)</span></span>
<span class="line"><span>variable-name-choice: Use &#39;userData&#39; for the result from the API call in this specific function. (Implementation detail)</span></span>
<span class="line"><span>api-endpoint-used: The data for this component comes from /api/v2/items. (Context specific to current code)</span></span>
<span class="line"><span>css-class-fix: Need to add &#39;margin-top: 10px&#39; to the &#39;.card-title&#39; element in this view. (Highly specific detail)</span></span>
<span class="line"><span>navigate-conversation-history: User often needs to implement logic to navigate conversation history (Too vague)</span></span>
<span class="line"><span>code-organization: User likes well-organized code (Too obvious and vague)</span></span>
<span class="line"><span>testing-important: Testing is important to the user (Too obvious)</span></span>
<span class="line"><span>error-handling: User wants good error handling (Not actionable)</span></span>
<span class="line"><span>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)</span></span>
<span class="line"><span>basic-software-engineering-principles: Basic software engineering principles such as separating concerns, DRY, SOLID, YAGNI, KISS, etc. (Too obvious and vague)</span></span>
<span class="line"><span></span></span>
<span class="line"><span>- **Do not generate memories from conversations where the user&#39;s message does not warrant a memory:**</span></span>
<span class="line"><span>    *   **Example Scenario:** The user asks if a specific implementation detail is correct, and the assistant confirms and explains why.</span></span>
<span class="line"><span>    *   **Example Chat:**</span></span>
<span class="line"><span>        user: i only want this stuff to work when side_model is the setting, does this impl seem legit</span></span>
<span class="line"><span>        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\\\`.</span></span>
<span class="line"><span>    *   **Suggested memory:** settings-gating-pattern: Gate features by settings using both dedicated gating methods (e.g., \\\`shouldRun...\\\`) and explicit checks within the core logic functions.</span></span>
<span class="line"><span>    *   **Why it&#39;s a bad memory:** This interaction doesn&#39;t warrant a memory. The user&#39;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&#39;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.</span></span>
<span class="line"><span></span></span>
<span class="line"><span>    *   **Example Scenario:** The user asks a very specific technical question about an ongoing refactor, and the assistant provides a targeted answer.</span></span>
<span class="line"><span>    *   **Example Chat:**</span></span>
<span class="line"><span>        user: I&#39;m refactoring the \\\`processUserInput\\\` function to split out the validation logic. Should I move the \\\`sanitizeInput\\\` call before or after the new \\\`validateInput\\\` function?</span></span>
<span class="line"><span>        assistant: It&#39;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.</span></span>
<span class="line"><span>    *   **Suggested memory:** refactor-ordering: Always call \\\`sanitizeInput\\\` before \\\`validateInput\\\` in the \\\`processUserInput\\\` function.</span></span>
<span class="line"><span>    *   **Why it&#39;s a 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.</span></span>
<span class="line"><span></span></span>
<span class="line"><span>&lt;/examples_should_not_remember&gt;</span></span>
<span class="line"><span></span></span>
<span class="line"><span>&lt;examples_should_remember&gt;</span></span>
<span class="line"><span>Examples of memories that SHOULD be remembered:</span></span>
<span class="line"><span>function-size-preference: Keep functions under 50 lines to maintain readability (Specific and actionable)</span></span>
<span class="line"><span>prefer-async-await: Use async/await style rather than promise chaining (Clear preference that affects code)</span></span>
<span class="line"><span>typescript-strict-mode: Always enable strictNullChecks and noImplicitAny in TypeScript projects (Specific configuration)</span></span>
<span class="line"><span>test-driven-development: Write tests before implementing a new feature (Clear workflow preference)</span></span>
<span class="line"><span>prefer-svelte: Prefer Svelte for new UI work over React (Clear technology choice)</span></span>
<span class="line"><span>run-npm-install: Run &#39;npm install&#39; to install dependencies before running terminal commands (Specific workflow step)</span></span>
<span class="line"><span>frontend-layout: The frontend of the codebase uses tailwind css (Specific technology choice)</span></span>
<span class="line"><span>&lt;/examples_should_remember&gt;</span></span>
<span class="line"><span></span></span>
<span class="line"><span>&lt;labeling_instructions&gt;</span></span>
<span class="line"><span>The label should be descriptive of the general concept being captured.</span></span>
<span class="line"><span>The label will be used as a filename and can only have letters and hyphens.</span></span>
<span class="line"><span>&lt;/labeling_instructions&gt;</span></span>
<span class="line"><span></span></span>
<span class="line"><span>&lt;formatting_instructions&gt;</span></span>
<span class="line"><span>Return your response in the following JSON format:</span></span>
<span class="line"><span>{</span></span>
<span class="line"><span>	&quot;explanation&quot;: &quot;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.&quot;,</span></span>
<span class="line"><span>	&quot;memory&quot;: &quot;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.&quot;</span></span>
<span class="line"><span>}</span></span>
<span class="line"><span></span></span>
<span class="line"><span>If no memory is needed, return exactly: &quot;no_memory_needed&quot;</span></span>
<span class="line"><span>&lt;/formatting_instructions&gt;</span></span></code></pre></div>`,2)])])}const d=s(p,[["render",i]]);export{h as __pageData,d as default};
