PORTAL / LIBRARY / dream

[ OPERATIONS · OPERATOR UTILITY ]

/dream

Transcripts (JSONL) live at: `C:\Users\faris\.claude\projects\<id>\`

Download the skill file (.md)

Placeholders like ACME Agency, <id> and you@example.com mark values that are per-agency — your install fills them with YOUR clients and accounts. If a section references a helper script you don't have yet, it ships with that workflow's install.

Dream — Memory Consolidation

Triggers

Paths

ScopeMemory dirIndex fileMax index lines
ProjectC:\Users\faris\.claude\projects\<id>\memory\MEMORY.md in that dir200
Global (all)C:\Users\faris\.claude\memory\MEMORY.md in that dir100

Transcripts (JSONL) live at: C:\Users\faris\.claude\projects\<id>\


Phase 1 — Orient

  1. List the memory directory to see what files exist
  2. Read the INDEX_FILE (MEMORY.md) to understand the current index
  3. Skim each existing topic file so you improve them rather than creating duplicates
  4. If logs/ or sessions/ subdirectories exist, ACME Agencyw recent entries there

The goal is to build a mental map of what's already known before looking for new signal.


Phase 2 — Gather recent signal

Look for new information worth persisting. Work through these sources in order, stopping when you have enough:

  1. Daily logs (logs/YYYY/MM/YYYY-MM-DD.md) — if present, these are the append-only stream of what happened
  2. Drifted memories — facts in existing files that contradict what you see in the codebase right now (e.g., a file path that no longer exists, an integration status that changed)
  3. Transcript search — only if you suspect something specific is missing. Grep narrowly:

``bash grep -rn "<narrow term>" "C:\Users\faris\.claude\projects\<id>\" --include="*.jsonl" | tail -50 `` Don't exhaustively read transcripts — look only for things you already suspect matter.

What's worth saving (from the auto-memory system prompt):

What NOT to save: code patterns, git history, debugging recipes, anything already in CLAUDE.md, or ephemeral task details.


Phase 3 — Consolidate

For each piece of new signal:

  1. Check for an existing file to update rather than creating a duplicate
  2. Write or update the memory file using this format:

```markdown


name: <memory name> description: <one-line description — specific enough to judge relevance> type: <user | feedback | project | reference>


<memory content> `` For feedback and project` types, structure as: rule/fact first, then Why: and How to apply: lines.

  1. Convert relative dates to absolute dates (e.g., "yesterday" → "2026-03-25")
  2. Delete contradicted facts — if today's investigation disproves an old memory, fix it at the source rather than adding a correction note

Phase 4 — Prune and index

Update the INDEX_FILE so it stays under the line limit AND under the 24.4 KB load cap — aim for ≤ 22 KB so there's margin. This is a HARD limit: above it, the harness loads only PART of the index and silently drops the rest, so future sessions lose memory pointers. If you can't get under 22 KB by tightening lines, the index has too many entries — consolidate related memories into one file and remove the redundant pointers.

Index format — each entry is one line:

- [Title](file.md) — one-line hook under ~150 chars

Rules:


For /dream all

Repeat all four phases twice:

  1. First for the project scope (paths above)
  2. Then for the global scope (C:\Users\faris\.claude\memory\)

The global memory dir may not exist yet — if it doesn't, skip it silently (don't create an empty structure).


Output

Return a brief summary:

If nothing changed (memories are already tight and accurate), say so explicitly.