---
name: dream
type: workflow
description: "Consolidates and prunes the memory directory through a 4-phase reflective pass: Orient, Gather, Consolidate, Prune. Run after intensive sessions, when memories feel duplicated, or when MEMORY.md approaches the 200-line limit."
argument-hint: "[optional: topic keyword to focus on, e.g. 'feedback' or 'project']"
user-invocable: true
allowed-tools: Read, Write, Glob, Grep, Bash
effort: 4
when_to_use: "Clean up and consolidate the memory directory (MEMORY.md + topic files) after long sessions, when memories are duplicated, or when MEMORY.md is approaching the 200-line/25KB limit"
Dream: Memory Consolidation
You are performing a dream — a reflective pass over your memory files. Synthesize what you've learned recently into durable, well-organized memories so that future sessions orient quickly.
Memory directory: find the path from your system prompt — look for the "auto memory" section which says "You have a persistent, file-based memory system at <path>". That is your memory directory. If no such section exists, default to ~/.claude/projects/<sanitized-cwd>/memory/ where <sanitized-cwd> is the current working directory with / replaced by -.
Session transcripts: look for *.jsonl files in the project directory inside ~/.claude/projects/ that corresponds to the current working directory. These are signal sources — grep narrowly, do NOT read whole files.
If the user passed a topic argument (e.g., /dream feedback), focus Phase 2–3 on that topic only. Still run Phase 1 and Phase 4 in full.
Phase 1 — Orient
mkdir -p the memory directory if it doesn't exist yet.
ls the memory directory — note all existing topic files.
- Read
MEMORY.md (if it exists) to understand the current index. If it doesn't exist, this is a fresh start — you'll create it in Phase 4.
- Skim existing topic files to build a picture of what's already recorded — so you improve rather than duplicate.
- If
logs/ or sessions/ subdirectories exist, note their presence for Phase 2.
- Check for topic files missing mandatory YAML frontmatter (name, description, type) — flag these for repair in Phase 3.
Report: memory directory path, file count, MEMORY.md line count (or "new"), any frontmatter issues found.
Phase 2 — Gather recent signal
Look for new information worth persisting. Do NOT exhaustively read transcripts. Look only for things you already suspect matter.
Sources in priority order:
- Daily logs (
logs/YYYY/MM/YYYY-MM-DD.md) if present — append-only stream, check recent entries first.
- Drifted facts — scan existing memories for claims that may contradict the current codebase (file paths, function names, flags). Verify with Glob/Grep before marking as stale.
- Transcript search — grep JSONL files narrowly for specific context:
grep -rn "<narrow term>" ~/.claude/projects/ --include="*.jsonl" | tail -50
Useful search terms: user corrections ("don't", "no not", "stop"), confirmations ("exactly", "perfect"), role signals ("I'm a", "I own"), decisions ("we're going with", "we decided"), deadlines, external system URLs.
Signal categories to look for:
| Category |
Type |
Trigger phrases |
| User corrections |
feedback |
"no", "don't", "stop doing", "not like that", "actually..." |
| Confirmed approaches |
feedback |
"yes exactly", "perfect", silent acceptance of unusual choice |
| Role / expertise |
user |
"I'm a ...", "I've been writing X for Y years", "I own the ..." |
| Project decisions |
project |
"we're going with", "we decided", deadlines, incidents |
| External pointers |
reference |
Dashboard URLs, issue trackers, Slack channels, doc links |
What NOT to gather (strict exclusions):
- Code patterns, architecture, file paths, project structure — derivable from reading code.
- Git history or who-changed-what —
git log / git blame are authoritative.
- Debugging solutions — the fix is in the code; context is in the commit message.
- Anything already in CLAUDE.md files.
- Ephemeral task state or current conversation context.
- PR lists / activity summaries — save only what was surprising or non-obvious.
Phase 3 — Consolidate
Before making any file modifications, show the user a plan:
- List files to be created, updated, merged, or deleted.
- Wait for user approval before proceeding.
After approval, execute:
3a. Repair missing frontmatter
For any topic file flagged in Phase 1, add the required YAML frontmatter:
---
name: {{memory name}}
description: "Consolidates and prunes the memory directory through a 4-phase reflective pass: Orient, Gather, Consolidate, Prune. Run after intensive sessions, when memories feel duplicated, or when MEMORY.md approaches the 200-line limit."
type: {{user | feedback | project | reference}}
---
3b. Merge duplicates and near-duplicates
If two or more files cover the same topic (e.g., feedback_testing_1.md and feedback_testing_2.md), merge them into one canonical file. Delete the originals after merging.
3c. Write / update memories for new signal
For each new signal found in Phase 2, either update an existing file or create a new one.
Memory type conventions:
- feedback — Lead with the rule, then
**Why:** (the reason the user gave) and **How to apply:** (when/where this kicks in). Always include Why — it enables edge-case judgement instead of blind rule-following.
- project — Lead with the fact/decision, then
**Why:** (motivation, constraint, deadline) and **How to apply:** (how this shapes suggestions). Convert all relative dates to absolute dates (e.g., "Thursday" → "2026-04-10").
- user — Factual profile: role, expertise, preferences, responsibilities.
- reference — Pointer + purpose. One or two lines.
3d. Fix contradictions
If today's investigation proves an old memory wrong, fix it at the source — edit or delete the old file. Do not leave contradicting entries.
Phase 4 — Prune and index
Rebuild MEMORY.md so it stays under 200 lines AND under ~25KB.
Rules for the index:
- Each entry is exactly one line, under ~150 characters:
- [Title](file.md) — one-line hook
- Never write memory content directly into
MEMORY.md — it's an index, not a dump.
- Remove pointers to deleted or superseded files.
- If an index line is over ~200 chars, shorten it — move the detail into the topic file.
- Organize semantically by topic (user → feedback → project → reference), not chronologically.
Output
Return a brief summary of what was consolidated, updated, merged, pruned, or repaired. If nothing changed (memories are already tight), say so explicitly.
End with a stats line in this exact format:
Dream complete: X memories total | Y created, Z updated, W merged, V pruned.
(Omit categories with a count of 0.)
1---2name: dream3description: ---4---5---6name: dream7type: workflow8description: "Consolidates and prunes the memory directory through a 4-phase reflective pass: Orient, Gather, Consolidate, Prune. Run after intensive sessions, when memories feel duplicated, or when MEMORY.md approaches the 200-line limit."9argument-hint: "[optional: topic keyword to focus on, e.g. 'feedback' or 'project']"10user-invocable: true11allowed-tools: Read, Write, Glob, Grep, Bash12effort: 413when_to_use: "Clean up and consolidate the memory directory (MEMORY.md + topic files) after long sessions, when memories are duplicated, or when MEMORY.md is approaching the 200-line/25KB limit"14---1516# Dream: Memory Consolidation1718You are performing a dream — a reflective pass over your memory files. Synthesize what you've learned recently into durable, well-organized memories so that future sessions orient quickly.1920**Memory directory:** find the path from your system prompt — look for the "auto memory" section which says "You have a persistent, file-based memory system at `<path>`". That is your memory directory. If no such section exists, default to `~/.claude/projects/<sanitized-cwd>/memory/` where `<sanitized-cwd>` is the current working directory with `/` replaced by `-`.2122**Session transcripts:** look for `*.jsonl` files in the project directory inside `~/.claude/projects/` that corresponds to the current working directory. These are signal sources — grep narrowly, do NOT read whole files.2324**If the user passed a topic argument** (e.g., `/dream feedback`), focus Phase 2–3 on that topic only. Still run Phase 1 and Phase 4 in full.2526---2728## Phase 1 — Orient29301. `mkdir -p` the memory directory if it doesn't exist yet.312. `ls` the memory directory — note all existing topic files.323. Read `MEMORY.md` (if it exists) to understand the current index. If it doesn't exist, this is a fresh start — you'll create it in Phase 4.334. Skim existing topic files to build a picture of what's already recorded — so you improve rather than duplicate.345. If `logs/` or `sessions/` subdirectories exist, note their presence for Phase 2.356. Check for topic files missing mandatory YAML frontmatter (name, description, type) — flag these for repair in Phase 3.3637Report: memory directory path, file count, MEMORY.md line count (or "new"), any frontmatter issues found.3839---4041## Phase 2 — Gather recent signal4243Look for new information worth persisting. **Do NOT exhaustively read transcripts.** Look only for things you already suspect matter.4445Sources in priority order:46471. **Daily logs** (`logs/YYYY/MM/YYYY-MM-DD.md`) if present — append-only stream, check recent entries first.482. **Drifted facts** — scan existing memories for claims that may contradict the current codebase (file paths, function names, flags). Verify with Glob/Grep before marking as stale.493. **Transcript search** — grep JSONL files narrowly for specific context:50 ```bash51 grep -rn "<narrow term>" ~/.claude/projects/ --include="*.jsonl" | tail -5052 ```53 Useful search terms: user corrections ("don't", "no not", "stop"), confirmations ("exactly", "perfect"), role signals ("I'm a", "I own"), decisions ("we're going with", "we decided"), deadlines, external system URLs.5455**Signal categories to look for:**5657| Category | Type | Trigger phrases |58|---|---|---|59| User corrections | feedback | "no", "don't", "stop doing", "not like that", "actually..." |60| Confirmed approaches | feedback | "yes exactly", "perfect", silent acceptance of unusual choice |61| Role / expertise | user | "I'm a ...", "I've been writing X for Y years", "I own the ..." |62| Project decisions | project | "we're going with", "we decided", deadlines, incidents |63| External pointers | reference | Dashboard URLs, issue trackers, Slack channels, doc links |6465**What NOT to gather** (strict exclusions):66- Code patterns, architecture, file paths, project structure — derivable from reading code.67- Git history or who-changed-what — `git log` / `git blame` are authoritative.68- Debugging solutions — the fix is in the code; context is in the commit message.69- Anything already in CLAUDE.md files.70- Ephemeral task state or current conversation context.71- PR lists / activity summaries — save only what was *surprising* or *non-obvious*.7273---7475## Phase 3 — Consolidate7677**Before making any file modifications, show the user a plan:**78- List files to be created, updated, merged, or deleted.79- Wait for user approval before proceeding.8081After approval, execute:8283### 3a. Repair missing frontmatter84For any topic file flagged in Phase 1, add the required YAML frontmatter:85```markdown86---87name: {{memory name}}88description: "Consolidates and prunes the memory directory through a 4-phase reflective pass: Orient, Gather, Consolidate, Prune. Run after intensive sessions, when memories feel duplicated, or when MEMORY.md approaches the 200-line limit."89type: {{user | feedback | project | reference}}90---91```9293### 3b. Merge duplicates and near-duplicates94If two or more files cover the same topic (e.g., `feedback_testing_1.md` and `feedback_testing_2.md`), merge them into one canonical file. Delete the originals after merging.9596### 3c. Write / update memories for new signal97For each new signal found in Phase 2, either update an existing file or create a new one.9899**Memory type conventions:**100101- **feedback** — Lead with the rule, then `**Why:**` (the reason the user gave) and `**How to apply:**` (when/where this kicks in). Always include Why — it enables edge-case judgement instead of blind rule-following.102- **project** — Lead with the fact/decision, then `**Why:**` (motivation, constraint, deadline) and `**How to apply:**` (how this shapes suggestions). Convert all relative dates to absolute dates (e.g., "Thursday" → "2026-04-10").103- **user** — Factual profile: role, expertise, preferences, responsibilities.104- **reference** — Pointer + purpose. One or two lines.105106### 3d. Fix contradictions107If today's investigation proves an old memory wrong, fix it at the source — edit or delete the old file. Do not leave contradicting entries.108109---110111## Phase 4 — Prune and index112113Rebuild `MEMORY.md` so it stays **under 200 lines AND under ~25KB**.114115Rules for the index:116- Each entry is exactly **one line**, under ~150 characters: `- [Title](file.md) — one-line hook`117- Never write memory content directly into `MEMORY.md` — it's an index, not a dump.118- Remove pointers to deleted or superseded files.119- If an index line is over ~200 chars, shorten it — move the detail into the topic file.120- Organize semantically by topic (user → feedback → project → reference), not chronologically.121122---123124## Output125126Return a brief summary of what was consolidated, updated, merged, pruned, or repaired. If nothing changed (memories are already tight), say so explicitly.127128End with a stats line in this exact format:129130**Dream complete:** X memories total | Y created, Z updated, W merged, V pruned.131132*(Omit categories with a count of 0.)*