---
name: agent-memory-implementation
description: "Restructures a chaotic or overgrown MEMORY.md into a clean 2-layer architecture based on how Claude Code's autoDream system organizes memory — a lightweight pointer index (always loaded) and topic files (loaded on demand). Stale or superseded memories are deleted or corrected in place — not archived. Use this skill whenever the user says \"clean up MEMORY.md\", \"reorganize my memory files\", \"MEMORY.md is getting too long\", \"fix my memory structure\", or when you observe that MEMORY.md exceeds 200 lines, contains full paragraphs instead of pointers, or mixes index entries with topic content."
license: "Skill implementation guide for personal/educational use."
---

# memory-architect

Restructures memory files into the 2-layer architecture that Claude Code's `autoDream` service uses internally — designed to keep the always-loaded index small while making deeper knowledge accessible on demand.

## The 2-Layer Architecture

Claude Code's memory system (`services/autoDream/`) uses this structure:

```
MEMORY.md          ← Layer 1: Always loaded, pointer-only index (~200 lines max)
├── topic-file.md  ← Layer 2: Domain knowledge, loaded when relevant
└── another-topic.md
```

**Layer 1 — MEMORY.md index**: Loaded into every conversation. Must stay under ~200 lines (lines beyond 200 get truncated). Each entry is a one-line pointer: `- [Title](file.md) — one-line hook`. No content, just pointers. This is what Claude scans to decide what to load.

**Layer 2 — Topic files**: Contain the actual knowledge. Claude loads these on demand when their pointer appears relevant. Can be as long as needed. Each file has YAML frontmatter with `name`, `description`, and `type`.

**No archive layer**: The autoDream system does not maintain an archive directory. Stale, superseded, or contradicted memories are **deleted or corrected in place** (see `consolidationPrompt.ts` Phase 3–4). The memory directory is always the current truth, not a history log.

## How Claude Code Writes Memories Automatically

Understanding the auto-extraction pipeline helps you restructure files in a way that works *with* the system rather than against it.

### The extraction forked agent

At the end of every query loop (when the model returns a final response with no pending tool calls), Claude Code fires a **forked agent** in the background via `executeExtractMemories()` in `services/extractMemories/extractMemories.ts`. This agent:

1. Receives the last N user/assistant messages as context
2. Scans the memory directory for existing files (reads only frontmatter — the `description` field is the primary signal)
3. Decides what is worth saving from this conversation
4. Writes or updates `.md` files inside the memory directory, then updates `MEMORY.md`

The fork shares the parent conversation's **prompt cache** (same tool list, same system prompt prefix, same cache key), so the extra token cost is near zero.

**Mutual exclusion**: if the main agent already wrote to the memory directory during the conversation (e.g., the user said "remember this"), the forked agent detects that and skips — no double-writes.

**Turn budget**: hard cap of 5 turns. The agent is instructed to batch all reads in turn 1 and all writes in turn 2 — no interleaving.

### The extraction agent's prompt (reference: `services/extractMemories/prompts.ts`)

The prompt is assembled by `buildExtractAutoOnlyPrompt()` in four parts:

**Part 1 — Role + tool constraints + efficiency strategy (hardcoded)**
```
You are now acting as the memory extraction subagent.
Analyze the most recent ~{N} messages above and use them to update
your persistent memory systems.

Available tools: Read, Grep, Glob, read-only Bash (ls/find/cat/stat/
wc/head/tail), and Edit/Write for paths inside the memory directory
only. Bash rm is not permitted.

Turn budget strategy:
  turn 1 — issue all Read calls in parallel for every file you might update
  turn 2 — issue all Write/Edit calls in parallel

You MUST only use content from the last ~{N} messages.
Do not grep source files, read code to confirm patterns, or run git commands.
```

**Part 2 — Existing memory manifest (injected dynamically)**
```
## Existing memory files

- [feedback] feedback_testing.md: no DB mocks in integration tests
- [user] user_role.md: user is a PM learning the codebase
- ...

Check this list before writing — update an existing file rather than
creating a duplicate.
```

Generated by `scanMemoryFiles()` scanning each file's frontmatter. The `description` field in your frontmatter **is** this manifest line — if it's vague, the agent can't tell whether to update the file or create a new one.

**Part 3 — Four memory types + What NOT to save (shared with system prompt)**

Uses the same constants (`TYPES_SECTION_INDIVIDUAL`, `WHAT_NOT_TO_SAVE_SECTION`) from `memdir/memoryTypes.ts` that appear in the main agent's system prompt. One source of truth — the extraction agent uses the same criteria the main agent uses.

**Part 4 — How to save (two-step write spec)**
```
Step 1 — write topic file with frontmatter:
  ---
  name: <slug>
  description: <one-line summary — used for relevance matching>
  type: user | feedback | project | reference
  ---

Step 2 — add one pointer line to MEMORY.md:
  - [Title](file.md) — one-line hook
```

### Implications for restructuring

- **`description` is load-bearing** — it's what both the extraction agent (dedup check) and the relevance scorer (read-time selection) use. A vague description like "notes" means neither can work correctly. Make it specific enough to answer "would this be relevant if the user asked about X?"
- **frontmatter type drives filing** — the extraction agent uses the type taxonomy to decide which criteria apply. A file with the wrong type (or no type) will be handled incorrectly on future updates.
- **MEMORY.md pointer hooks matter** — the hook text after `—` is what Claude reads to decide whether to load the full file. A hook that just says "misc notes" wastes the slot.

## Memory Type Definitions

Read [`references/memory-type-definitions.md`](references/memory-type-definitions.md) for the verbatim XML from `memdir/memoryTypes.ts` — the four type specs (`user`, `feedback`, `project`, `reference`) and the exclusion list. Load it when deciding what to extract from a conversation and which type to assign to each memory.

---

## Restructuring Process

### Step 1 — Audit what exists

Read `MEMORY.md` and all memory files in the same directory. Catalog:
- Total line count of MEMORY.md
- Which entries are pointer-only (good) vs. have inline content (needs extraction)
- Which topic files have grown unwieldy (>200 lines) and should be split
- Which entries are clearly stale, superseded, or contradicted

### Step 2 — Classify each entry

For each piece of content, decide its layer:

| Content type | Layer |
|---|---|
| Universal facts, always-relevant rules | L1 pointer → L2 file |
| Project-specific decisions, current constraints | L1 pointer → L2 file |
| Historical "why we did X" context | Condense into relevant L2 file or delete |
| Superseded approaches | Delete |
| Contradicted facts | Delete or correct at source |
| Step-by-step implementation details | Delete (code is the record) |

### Step 3 — Restructure

**For MEMORY.md:**
- Keep only pointer lines (one per memory file)
- Format: `- [Descriptive Title](filename.md) — one-line hook (what makes this relevant?)`
- Keep under 200 lines total
- Group related pointers with brief section headers if helpful (e.g., `## Architecture`, `## User preferences`)
- Remove entries for deleted files

**For topic files:**
- Each file gets proper frontmatter:
  ```markdown
  ---
  name: <topic name>
  description: <one-line — used to judge relevance in future conversations>
  type: user | feedback | project | reference
  ---
  ```
- `feedback` type: lead with the rule, then `**Why:**` and `**How to apply:**` lines
- `project` type: lead with the fact/decision, then `**Why:**` and `**How to apply:**`
- Consolidate near-duplicate files (same topic, slightly different angles) into one
- Convert relative dates to absolute dates ("last week" → "2026-03-15")

### Step 4 — Verify

After restructuring:
- MEMORY.md under 200 lines? 
- Every pointer in MEMORY.md points to an existing file?
- Every topic file has valid frontmatter?
- No content directly in MEMORY.md (only pointers)?
- No duplicate or near-duplicate topic files?

### Step 5 — Report

Tell the user:
- Before/after line count for MEMORY.md
- How many topic files created/merged/deleted
- Any contradictions found and how resolved

## Common anti-patterns to fix

**Bloated index** — MEMORY.md has paragraphs of content instead of pointers. Extract to topic files.

**One giant file** — Everything dumped into a single `memories.md`. Split by topic.

**Missing frontmatter** — Topic files without `name`/`description`/`type`. Add it — the description is what helps Claude decide whether to load the file.

**Stale facts** — Memory says "using postgres 14" but codebase shows 16. Fix at source.

**Temporal decay** — "We decided last week to use X". Convert to absolute date; also verify if decision still stands.

**Historical context in index** — Old decisions or "why we did X" cluttering MEMORY.md. Either condense the rationale into the relevant topic file's `**Why:**` line, or delete if no longer relevant.