NEW: Claude Code Security — research preview

Memory Prompts

How to manage context across long sessions — conversation summarization, session notes, persistent memory extraction, and memory consolidation.

Read time: 8 min

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:

  1. Primary Request and Intent — What the user originally wanted and the deeper goal behind it
  2. Key Technical Concepts — Frameworks, patterns, algorithms, architectures, or domain knowledge involved
  3. Files and Code Sections — Enumerate every relevant file by path. Include complete code snippets. Explain why each matters.
  4. Errors and Fixes — Every error that surfaced, how it was resolved, and any user reactions or corrections
  5. Problem Solving — Reasoning chains, alternative approaches considered, debugging strategies applied
  6. All User Messages — List ALL non-tool-result messages from the user, preserving their substance
  7. Pending Tasks — Work that remains unfinished or was deferred
  8. Current Work — Precise description of what was actively being worked on at conversation end, with file names and code fragments
  9. 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:

SectionPurpose
Session TitleA short label for this work session
Current StateWhere things stand right now — ALWAYS update this (vital for continuity)
Task SpecificationWhat was asked for and acceptance criteria
Files and FunctionsWhich files and functions were touched or are relevant
WorkflowSteps taken, commands run, order of operations
Errors & CorrectionsProblems hit and how they were resolved
Codebase and System DocumentationArchitectural notes, environment details, system behavior discovered
LearningsInsights gained that apply beyond this session
Key ResultsConcrete outcomes produced
WorklogChronological 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 rm command 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:

CategoryExamples
User preferencesCoding style, tool choices, naming conventions, communication preferences
Project patternsArchitectural decisions, directory conventions, dependency choices
Error correctionsRecurring mistakes and their proven fixes
Workflow notesDeployment 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 / low

Memory 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.