MemoryReview

MemoryReview — curate long-term memory

A deliberate pass that keeps LTM accurate: decide what pending proposals become memories, re-check memories the code has moved past, and retire duplicates and contradictions. Tool names and categories come from the Ltm skill (../Ltm/SKILL.md); every tool below is mcp__plugin_openltm_memory__<name>.

Rules

• Change memory only through the MCP tools — never run SQL or edit the database file.
• Never forget without explicit approval. Show the exact IDs and content first and wait for a yes that covers those IDs. Extra care for importance-5 memories.
• Prefer relate … supersedes over forget when the old memory explains why something changed.
• Keep a pass to about 20 items; offer another pass if more remain.

Step 1 — Scope

Default to the current project. Ask only if the user hinted at something else ("all projects", "just proposals", "only stale ones").

Step 2 — Gather (read-only)

Run these and collect candidates:

1. Pending proposals — proposals {action: "list"}. Each has a session_id and index.
2. Stale memories — recall {project, verbose: true, limit: 50} (no query lists the project's top memories; add a query to focus an area). Keep rows where stale_flagged_at is set; stale_reason names the commit or files.
3. Conflicts and supersedes — from those rows, note contradicts relations and supersedes targets that are still active. For a tangled area, graph {memory_ids, depth: 2} shows the chain.
4. Duplicates and low value — memories in the same category that say the same thing; operational noise (one-off command output, transient state); facts derivable from the code or git log.

Step 3 — Present

One compact table per group, skipping empty groups:

### Pending proposals (3)
| # | session:index | category ★ | content | suggest |
|---|---------------|------------|---------|---------|
| 1 | a1b2c3d4:0 | gotcha ★4 | Bun prepare() caches statements… | accept |

### Stale (2)
| # | id | content | stale because | suggest |