dream

Dream — local memory consolidation

Emulates the Anthropic Dreams pipeline (POST /v1/dreams, research preview) against Claude Code's local storage. A dream reads an existing memory store alongside past session transcripts, then produces a new, reorganized memory store: duplicates merged, stale or contradicted entries replaced with the latest value, and new insights surfaced.

Prime directive (identical to the API): the input store is NEVER modified. All output goes to new files/directories. The user reviews the result and either applies it or discards it.

Invocation

/dream [N] [instructions...]

• N (optional integer, first token): number of recent session transcripts to mine. Default 10, max 100 (API limit). 0 means curate the store only, no transcript mining.
• instructions (optional, everything after N): steering text, equivalent to the API's instructions field. Examples: "focus on coding-style preferences; ignore one-off debugging notes", "preserve all reference memories unchanged".

Per the API docs, instructions are synthesis guidance (what to read closely, what to merge or drop, how to structure the output), not line-level edit commands. If the user asks for a targeted edit to one memory ("change X to Y"), edit that file directly instead of running a dream.

Phase 0 — Locate inputs

Compute the project slug from the current working directory: replace every / and . with - (e.g. /Users/maxgoff/Dreams → -Users-maxgoff-Dreams).

Gather, reporting to the user what was found (file counts, sizes):

1. Memory store (the primary input): ~/.claude/projects/<slug>/memory/ — markdown files with frontmatter (name, description, metadata.type) plus the MEMORY.md index.
   • If the directory is missing or empty, proceed with an empty input store and build the output purely from mined sessions (the API's "create an empty memory store first" path).
2. Session transcripts: ~/.claude/projects/<slug>/*.jsonl, sorted by mtime descending. Take the N most recent. Note that the newest file is usually the current, in-progress session — include it but weight its content as provisional.
3. CLAUDE.md instruction files (each curated separately, in place as *.dream proposals):
   • <cwd>/CLAUDE.md and <cwd>/CLAUDE.local.md (project)
   • ~/.claude/CLAUDE.md (global)
4. claude-mem store (if ~/.claude-mem/claude-mem.db exists): SQLite, read-only. Relevant rows:

   sqlite3 -readonly ~/.claude-mem/claude-mem.db \
     "SELECT id, type, title, subtitle, facts, created_at FROM observations
      WHERE project = '<project>' ORDER BY created_at_epoch DESC"
   

   Discover the project name first: SELECT DISTINCT project FROM observations; and match against the cwd basename. If claude-mem is absent, skip silently.

Phase 1 — Inventory the store

Read every file in the memory store. Build an internal inventory: name, type (user/feedback/project/reference), description, key claims, [[links]], and apparent age. Flag candidates for: exact/near duplicates, mutual contradictions, entries that look stale (reference things that may no longer exist — verify against the repo before dropping), and one-off notes with no durable value.

Phase 2 — Mine the sessions

Transcripts are JSONL and dominated by tool results. Never read raw .jsonl files into the main context. Extract conversational text first:

jq -r '
  select(.type == "user" or .type == "assistant")
  | .type as $role
  | (.message.content // empty)
  | if type == "string" then "\($role): \(.)"
    else ([.[] | select(.type? == "text") | .text] | select(length > 0) | "\($role): \(join("\n"))")
    end
' <transcript>.jsonl

Fan out with parallel subagents (Explore or general-purpose), batching 1–5 transcripts per agent depending on size (split large transcripts across more agents; for files > 5 MB, mine the extracted text in chunks). Each agent receives the steering instructions and returns a structured list of findings:

• category: user | feedback | project | reference
• fact: the durable insight, stated absolutely (convert relative dates to absolute)
• evidence: short quote or paraphrase from the transcript
• contradicts: name of an existing memory this supersedes, if any
• confidence: high / medium / low

Instruct agents to mine for: explicit user corrections and preferences, confirmed working approaches, recurring project facts and constraints, external references (URLs, tickets, dashboards) — and to ignore one-off debugging noise, transient state, and anything already derivable from the repo or git history.

Phase 3 — Synthesize the output store

Write the rebuilt store to a sibling directory: ~/.claude/projects/<slug>/memory.dream-<YYYY-MM-DD>/. If it already exists from an earlier run today, append -2, -3, ….

Rules, mirroring the Dreams pipeline:

• Merge duplicates and near-duplicates into single canonical memories.
• Latest wins: where store entries or mined findings contradict, keep the most recent value; note the supersession in the body if useful.
• Drop stale entries (verified-dead references), one-off debugging notes, and anything contradicted with high confidence.
• Add new memories for high/medium-confidence mined insights not already in the store.
• Preserve the file format exactly: one fact per file, frontmatter (name, description, metadata.type), **Why:** / **How to apply:** lines for feedback/project types, [[name]] cross-links (repair links broken by merges/renames).
• Rebuild MEMORY.md as the index: one - [Title](file.md) — hook line per memory, ordered by usefulness-at-recall, no memory content in the index itself.
• Apply the user's steering instructions throughout all of the above.

CLAUDE.md proposals: for each CLAUDE.md found, if curation would change it (dedupe, remove stale directives, fold in mined feedback that belongs in standing instructions), write the proposal to <path>.dream-<date> next to the original. Be conservative — these are the user's hand-written directives; reorganize and dedupe, don't rewrite voice or drop anything you can't show is stale.

claude-mem report: write ~/.claude/projects/<slug>/memory.dream-<date>/claude-mem-report.md listing duplicate/stale/contradicted observation IDs with reasons, plus a ready-to-run claude-mem-curation.sql (DELETEs/UPDATEs by ID). Never execute it — the DB has FTS triggers and a live worker process; the user applies it manually after stopping claude-mem, or feeds the report to claude-mem's own tooling.

Phase 4 — Review, then apply or discard

Present a summary the user can judge without opening files:

	input store	output store
memories kept as-is
merged
updated (latest-wins)
dropped
new from sessions

…plus 3–5 notable examples (the most consequential merge, drop, and new insight), the list of CLAUDE.md proposals written, and claude-mem report counts.

Then ask the user to choose (use AskUserQuestion when available):

• Apply — atomically swap, keeping the input as backup:

  mv memory memory.pre-dream-<date> && mv memory.dream-<date> memory
  

  For each approved CLAUDE.md proposal: cp CLAUDE.md CLAUDE.md.pre-dream-<date> && mv CLAUDE.md.dream-<date> CLAUDE.md. Offer per-file choice — the user may want the memory swap but not the global CLAUDE.md change.
• Keep for review — leave the dream directory in place; tell the user the paths and how to apply later.
• Discard — delete the dream directory and any *.dream-<date> proposals.

Never auto-apply. On failure mid-pipeline, leave whatever was written (the API's failed semantics: partial output persists for inspection) and report what completed.

Fidelity notes

Dreams API	This skill
memory_store input	~/.claude/projects/<slug>/memory/
sessions input (1–100)	local .jsonl transcripts (N, default 10)
instructions	trailing /dream arguments
output store in outputs[]	memory.dream-<date>/ sibling dir
input never modified	input never modified
review then attach/discard	review then swap/discard
async job, observable session	runs in-session with progress updates