Prune Memory

Prune Memory

Audit the per-project memory directory and remove entries that no longer reflect reality. Suggest-only: surface candidates with reasons, confirm before touching files, never rewrite memory bodies.

Locate the memory directory

Derive from the current working directory: replace every / with -, prepend ~/.claude/projects/, append /memory/. Example: /Users/jenc/code/agent-skills → ~/.claude/projects/-Users-jenc-code-agent-skills/memory/.

If the directory is missing or empty, report and stop. If MEMORY.md is absent but memory files exist, flag the index drift first.

Workflow

1. Inventory. List *.md files in the memory dir and read MEMORY.md. Read every memory file in full — they are small.
2. Classify each memory by frontmatter metadata.type (user, feedback, project, reference). Different types decay at different rates (see Bias by type below).
3. Extract concrete claims from each memory body — file paths in backticks, function/symbol names, flag/env-var names, dates (YYYY-MM-DD), external URLs, person names, ticket IDs.
4. Verify against current state using one tool call per claim type:
   • File path → Read or ls; gone → stale.
   • Symbol / flag → Grep across the repo; zero hits → stale.
   • Date → compare to today; past → stale if the memory's premise was the date.
   • URL → leave alone (not the agent's job to fetch).
5. Cross-check the index. Files not listed in MEMORY.md → orphaned file. MEMORY.md entries pointing at missing files → orphaned link.
6. Find duplicates by frontmatter description overlap and body subject. Two memories on the same rule → propose keeping the more specific / more recent one.
7. Group findings into a single report:
   • dead-reference — cites artifact that no longer exists
   • past-dated — project memory whose premise (deadline, freeze, sprint) has passed
   • orphaned — file ↔ index mismatch
   • duplicate — overlapping subject with another memory
   • contradicted — body claims X, current code does not-X (only flag when confidence is high)
8. Confirm per item. Present each candidate with: path, type, one-line rationale, suggested action (delete / unlink from index / keep). Ask the user to approve, skip, or batch-approve a category. Default action on skip is keep.
9. Apply approved actions. For deletes: remove the file and the matching line in MEMORY.md. For index repairs: Edit MEMORY.md to add or remove the pointer. Never rewrite memory bodies — that is out of scope.
10. Report. Reviewed N, pruned M, kept N-M. <one line per pruned file>.

Bias by type

• feedback and user memories are durable — only prune on dead-reference or duplicate. Personal preferences and rules do not expire just because a file moved.
• project memories decay fast — past-dated, contradicted, and dead-reference all apply. Most pruning targets live here.
• reference memories — verify URLs/paths still resolve in name only (does the file/dir exist); do not fetch.

What you must NOT do

• Do not edit memory bodies. If a memory needs an update, flag it for the user; auto-save will fix it next time the underlying fact is observed.
• Do not delete MEMORY.md itself, even if empty.
• Do not prune memories that reference external projects or systems just because they are not in the current repo — reference memories often point off-repo on purpose.
• Do not consolidate by merging two memories into one; that is rewriting.
• Do not act without per-item confirmation, except for the bulk-approve path the user explicitly chooses.

Final assistant-message summary

Memory pruned: <M>/<N> reviewed.

- <path>: <category> — <one-line reason>
- <path>: <category> — <one-line reason>

Index updated: MEMORY.md (<+a/-b> lines).
Kept: <N-M> (no action needed or user declined).

If nothing was prunable, say so and list the categories you checked.