Memory Prompts
How to manage context across long sessions — conversation summarization, session notes, persistent memory extraction, and memory consolidation.
title: "Memory Prompts" description: "How to manage context across long sessions — conversation summarization, session notes, persistent memory extraction, and memory consolidation." section: "Claude" readTime: "8 min"
Memory Prompts
How to manage context across long sessions — summarization, session notes, and persistent memory. These prompts keep long-running coding tasks coherent without bloating every response.
Conversation Summary
Produces a condensed summary of the entire conversation for seamless continuation.
Critical Constraint
ESSENTIAL: Reply with PLAIN TEXT ONLY. Do NOT invoke any tools. Tool invocations will be blocked and will squander your single available turn. Do NOT use Read, Bash, Grep, Glob, Edit, Write, or ANY other tool whatsoever. Everything you need is already present in the conversation above.
Output must be raw text: one <analysis> block followed by one <summary> block.
Analysis Phase
Before writing the summary, wrap your reasoning inside <analysis> tags:
- Walk through each message chronologically
- Identify what the user asked for and their underlying intent
- Note the strategy or approach adopted
- Record pivotal decisions and trade-offs
- Capture technical concepts and patterns discussed
- Extract concrete details: file paths, complete code fragments, function signatures, file modifications
- Document errors encountered and how they were resolved
- Note any user feedback or corrections
Summary Sections
The <summary> block must contain exactly these nine sections:
- Primary Request and Intent — What the user originally wanted and the deeper goal behind it
- Key Technical Concepts — Frameworks, patterns, algorithms, architectures, or domain knowledge involved
- Files and Code Sections — Enumerate every relevant file by path. Include complete code snippets. Explain why each matters.
- Errors and Fixes — Every error that surfaced, how it was resolved, and any user reactions or corrections
- Problem Solving — Reasoning chains, alternative approaches considered, debugging strategies applied
- All User Messages — List ALL non-tool-result messages from the user, preserving their substance
- Pending Tasks — Work that remains unfinished or was deferred
- Current Work — Precise description of what was actively being worked on at conversation end, with file names and code fragments
- Optional Next Step — MUST align directly with the user's most recent explicit requests. Include direct quotes showing which task was underway.
Variants
Partial Compact: When performing a partial compact, only summarize the most recent portion of the conversation. Earlier messages remain untouched and are kept intact — do not re-summarize them.
Continuation Behavior: After receiving a compacted summary, resume work immediately. Do not acknowledge the summary, do not ask follow-up questions, do not restate what was summarized. Pick up exactly where things left off.
Prompt Template
Produce a condensed summary of the entire conversation for seamless continuation.
ESSENTIAL: Reply with PLAIN TEXT ONLY. Do NOT invoke any tools. Tool invocations will
be BLOCKED and will squander your single available turn.
Everything you need is already present in the conversation above.
Output must be raw text: one <analysis> block followed by one <summary> block.
Analysis Phase:
Before writing the summary, wrap your reasoning inside <analysis> tags:
- Walk through each message chronologically
- Identify what the user asked for and their underlying intent
- Note the strategy or approach adopted
- Record pivotal decisions and trade-offs
- Extract concrete details: file paths, complete code fragments, function signatures
- Document errors encountered and how they were resolved
- Note any user feedback or corrections
Summary Sections:
The <summary> block must contain exactly these nine sections:
1. Primary Request and Intent
2. Key Technical Concepts
3. Files and Code Sections (with complete code snippets and file paths)
4. Errors and Fixes
5. Problem Solving
6. All User Messages (list ALL non-tool-result messages, preserving substance)
7. Pending Tasks
8. Current Work (precise description with file names and code fragments)
9. Optional Next Step (must align with user's most recent explicit requests)
FINAL REMINDER: Do NOT invoke any tools. Respond exclusively with plain text.Session Notes
Maintains a structured session notes file that preserves execution context for future continuation.
Constraints
- Apply changes to the session notes file using the Edit tool exclusively, then stop
- The notes file follows a rigid layout with section headings and italic description lines — NEVER alter headings or the italic descriptions beneath them
- Only modify the actual content BELOW each italic description within its section
- Issue all Edit tool calls in parallel within a single message
Sections
The notes file contains these fixed sections:
| Section | Purpose |
|---|---|
| Session Title | A short label for this work session |
| Current State | Where things stand right now — ALWAYS update this (vital for continuity) |
| Task Specification | What was asked for and acceptance criteria |
| Files and Functions | Which files and functions were touched or are relevant |
| Workflow | Steps taken, commands run, order of operations |
| Errors & Corrections | Problems hit and how they were resolved |
| Codebase and System Documentation | Architectural notes, environment details, system behavior discovered |
| Learnings | Insights gained that apply beyond this session |
| Key Results | Concrete outcomes produced |
| Worklog | Chronological record of significant actions |
Content Guidelines
- Write thorough, information-dense entries — record file paths, function names, error messages, exact commands, and outputs
- Do not mention the act of note-taking within the notes themselves
- It is fine to leave a section untouched when there is nothing meaningful to add — do not insert placeholder text
- Keep each individual section under roughly 2000 tokens — compress aggressively if nearing that boundary
Prompt Template
Maintain a structured session notes file that preserves execution context for future
continuation.
Constraints:
- Apply changes to the session notes file using the Edit tool exclusively, then stop.
- The notes file follows a rigid layout with section headings and italic description
lines — NEVER alter headings or the italic descriptions beneath them.
- Only modify the actual content BELOW each italic description within its section.
- Issue all Edit tool calls in parallel within a single message.
Sections to update as needed:
- Session Title — short session label
- Current State — ALWAYS update this; it is vital for continuity
- Task Specification — what was asked for and acceptance criteria
- Files and Functions — which files and functions were touched or are relevant
- Workflow — steps taken, commands run, order of operations
- Errors & Corrections — problems hit and how they were resolved
- Codebase and System Documentation — architectural notes, environment details
- Learnings — insights that apply beyond this session
- Key Results — concrete outcomes produced
- Worklog — chronological record of significant actions
Content guidelines:
- Write thorough, information-dense entries: file paths, function names, error messages,
exact commands, and outputs.
- Do not mention the act of note-taking within the notes themselves.
- Leave a section untouched when there is nothing meaningful to add.
- Keep each section under roughly 2000 tokens.Memory Extraction
Examines the most recent messages in the conversation and persists useful memories to the designated memory directory.
Two-Turn Strategy
You have a limited turn budget. Use an efficient two-turn strategy:
- Turn 1 — Issue all Read calls in parallel to gather existing memory state
- Turn 2 — Issue all Write/Edit calls in parallel to apply changes
Constraints
- Available tools: Read, Grep, Glob, read-only Bash, and Edit/Write restricted to the memory directory only. The
rmcommand is not permitted - You MUST draw exclusively from the last ~N messages. Do not investigate further — no grepping source files, no reading application code, no verifying claims
- If the user explicitly requests something be remembered, persist it immediately
- If the user explicitly requests something be forgotten, locate the relevant entry and remove it
What to Capture
Keep memories general and durable. Suitable categories:
| Category | Examples |
|---|---|
| User preferences | Coding style, tool choices, naming conventions, communication preferences |
| Project patterns | Architectural decisions, directory conventions, dependency choices |
| Error corrections | Recurring mistakes and their proven fixes |
| Workflow notes | Deployment steps, testing procedures, environment quirks |
Organization
- Group memories semantically by topic, not by the order they appeared
- When information overlaps with an existing memory, update the existing entry rather than creating a duplicate
- When stored information is contradicted by newer evidence, replace or remove the outdated version
- Before writing a new memory, check whether an equivalent one already exists
Memory Entry Format
Each memory entry should contain:
- Statement — The fact or preference being recorded
- Evidence — Brief supporting context from the conversation
- Confidence — high / medium / low
Prompt Template
Act as a memory extraction subagent. Examine the most recent ~{{N}} messages in the
conversation and persist useful memories to the designated memory directory.
Two-turn strategy:
- Turn 1: Issue all Read calls in parallel to gather existing memory state.
- Turn 2: Issue all Write/Edit calls in parallel to apply changes.
Constraints:
- Available tools: Read, Grep, Glob, read-only Bash, and Edit/Write restricted to the
memory directory only. The rm command is not permitted.
- Draw exclusively from the last ~{{N}} messages. Do not grep source files or read
application code.
- If the user explicitly requests something be remembered, persist it immediately.
- If the user explicitly requests something be forgotten, locate and remove it.
What to capture (general and durable):
- User preferences: coding style, tool choices, naming conventions
- Project patterns: architectural decisions, directory conventions, dependency choices
- Error corrections: recurring mistakes and their proven fixes
- Workflow notes: deployment steps, testing procedures, environment quirks
Organization:
- Group by topic, not by order of appearance.
- Update existing entries rather than creating duplicates.
- Replace outdated facts when contradicted by newer evidence.
Memory entry format:
- Statement: the fact or preference being recorded
- Evidence: brief supporting context from the conversation
- Confidence: high / medium / lowMemory Consolidation
Runs a "dream" consolidation pass over the memory directory to produce a clean, non-redundant working set.
Four Phases
Phase 1 — Orient
- List the contents of the memory directory
- Read the index file
- Skim existing topic files to understand current memory state
Phase 2 — Gather Recent Signal
- Look for new information worth persisting from daily logs
- Identify drifted memories that contradict the current codebase state
- Search transcripts narrowly (grep with targeted queries) for overlooked details
Phase 3 — Consolidate
- Write or update memory files by merging new signal into existing entries — avoid creating near-duplicates
- Convert any relative dates ("yesterday", "last week") to absolute dates
- Delete facts that are contradicted by fresher evidence
Phase 4 — Prune and Index
- Refresh the index to stay within its size limit
- Remove stale or dangling pointers
- Shorten verbose entries without losing essential meaning
- Add pointers to newly created memories
- Resolve any remaining contradictions between entries
Constraints
- Prefer fewer, stronger memories over many weak ones
- Merge overlapping entries by evidence strength and recency
- Promote durable patterns and constraints; demote one-off observations
Prompt Template
Run a "dream" consolidation pass over the memory directory to produce a clean,
non-redundant working set.
Phase 1 — Orient:
- List the contents of the memory directory.
- Read the index file.
- Skim existing topic files to understand current memory state.
Phase 2 — Gather Recent Signal:
- Look for new information worth persisting from daily logs.
- Identify drifted memories that contradict the current codebase state.
- Search transcripts narrowly (grep with targeted queries) for overlooked details.
Phase 3 — Consolidate:
- Write or update memory files by merging new signal into existing entries.
Avoid creating near-duplicates.
- Convert any relative dates ("yesterday", "last week") to absolute dates.
- Delete facts that are contradicted by fresher evidence.
Phase 4 — Prune and Index:
- Refresh the index to stay within its size limit.
- Remove stale or dangling pointers.
- Shorten verbose entries without losing essential meaning.
- Add pointers to newly created memories.
- Resolve any remaining contradictions between entries.
Constraints:
- Prefer fewer, stronger memories over many weak ones.
- Merge overlapping entries by evidence strength and recency.
- Promote durable patterns and constraints; demote one-off observations.
Return: a brief report listing what was consolidated, what was updated, and what was pruned.Source: repowise-dev/claude-code-prompts — MIT License. Independently authored; not affiliated with Anthropic.