---
name: dream
aliases: [learn]
description: Reflective memory consolidation — review recent activity, synthesize learnings into the memory directory, and prune stale entries. Use when the user says "dream", "learn", "consolidate memories", "organize your memories", or asks Otherside to reflect on what it has learned.
userInvocable: true
context: fork
---

# 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 can orient quickly.

## Locate the memory directory

The auto-memory subsystem stores memories under:

`~/.otherside/projects/<sanitized-cwd>/memory/`

Resolve `<sanitized-cwd>` from the current working directory by replacing every `/` with `-` and prefixing with `-`. Example:

- cwd `/Users/alice/projects/acme` → slug `-Users-alice-projects-acme`
- Memory dir `~/.otherside/projects/-Users-alice-projects-acme/memory/`

If the resolved directory does not exist OR `MEMORY.md` is absent inside it, the auto-memory subsystem hasn't been initialized for this project yet — say so and stop. Do not write any files. The user can initialize it by saving any first memory.

## Locate the session transcripts

Session JSONL transcripts for this project live one level up:

`~/.otherside/projects/<sanitized-cwd>/*.jsonl`

Each filename (without `.jsonl`) is the session ID. Each line is a JSON message; user and assistant messages carry a `"content"` field. These files are large — never `cat` whole files. `grep` narrowly.

---

## Phase 1 — Orient

- `ls` the memory directory to see what already exists
- Read `MEMORY.md` to understand the current index
- Skim existing memory files so you improve them rather than creating duplicates

## Phase 2 — Gather recent signal

Look for new information worth persisting. Sources in rough priority order:

1. **Existing memories that drifted** — facts that contradict something you see in the codebase now. The current code/docs are authoritative.
2. **Transcript search** — if you need specific context (e.g., "what was the error message from yesterday's build failure?"), grep the JSONL transcripts for narrow terms:
   ```
   grep -rln "<narrow term>" ~/.otherside/projects/<slug>/*.jsonl | tail -10
   ```
   Then read the matching files with offset/limit, not whole.

Don't exhaustively read transcripts. Look only for things you already suspect matter — corrections the user made, decisions reached, recurring patterns, gotchas.

## Phase 3 — Consolidate

For each thing worth remembering, write or update a memory file at the top level of the memory directory. Use the memory-file format and type conventions from your system prompt's auto-memory section — it is the source of truth for what to save, how to structure it, and what NOT to save.

Focus on:

- **Merging** new signal into existing topic files rather than creating near-duplicates
- Converting relative dates ("yesterday", "last week") to **absolute dates** so they remain interpretable after time passes
- **Deleting contradicted facts** — if today's investigation disproves an old memory, fix it at the source rather than appending a correction

## Phase 4 — Prune and index

Update `MEMORY.md` so it stays:

- under **200 lines** total
- under **~25KB** total
- each entry on **one line** under ~150 characters: `` - [Title](file.md) — one-line hook ``

It's an **index**, not a dump. Never write memory content directly into `MEMORY.md` — content goes in the topic file, the index points at it.

- Remove pointers to memories that are now stale, wrong, or superseded
- Remove memories that are still TRUE but no longer load-bearing — pure project status that closed, debug notes for a bug that's been fixed, release-note recaps, "I did X" diaries. The test: **does this memory change what a future session DOES, or just remember what happened?** If only the latter, prune. Git history holds it.
- Demote verbose entries: if an index line is over ~200 chars, it's carrying content that belongs in the topic file — shorten the line, move the detail
- Add pointers to newly important memories
- Resolve contradictions — if two memory files disagree, fix the wrong one

### Reconcile memories against OTHERSIDE.md

Project `OTHERSIDE.md` instructions are loaded in your system prompt. For each `feedback` or `project` memory, check whether it contradicts a `OTHERSIDE.md` instruction on the same topic:

- **Memory is stale** — `OTHERSIDE.md` and the memory describe different procedures for the same task. `OTHERSIDE.md` is the maintained, checked-in source of truth. Delete the memory, or rewrite it to agree if it carries context worth keeping (the *why* is still useful but the *how* is wrong).
- **`OTHERSIDE.md` may be stale** — the memory is clearly dated after `OTHERSIDE.md` and explicitly corrects it. Do **NOT** edit `OTHERSIDE.md` during a dream. Annotate the memory with `"contradicts OTHERSIDE.md — verify which is current"` and list it in your summary so the user can update `OTHERSIDE.md` themselves.
- **Not a conflict** — the memory adds detail `OTHERSIDE.md` doesn't cover, or narrows a `OTHERSIDE.md` rule with a stated reason. Leave it.

A `feedback` memory's "Why: the user corrected me" framing is **not evidence** that it's newer than `OTHERSIDE.md` — `OTHERSIDE.md` may have been updated since the correction.

---

## Output

Return a brief summary covering:

- **Consolidated** — N new memories written / merged
- **Updated** — N existing memories edited (with file names)
- **Pruned** — N memories deleted (with file names and one-line reason each)
- **OTHERSIDE.md flags** — any `contradicts OTHERSIDE.md` annotations you added

If nothing changed (memories are already tight), say so plainly — that's a valid outcome.
