Memory Review

Purpose

Review the user's memory landscape and produce a clear report of proposed changes, grouped by action type. The skill never applies changes by itself — it presents proposals for user approval. It also surfaces duplicates, outdated entries, and cross-layer conflicts.

When to Use

• The user wants to review, organize, or promote their auto-memory entries.
• The user asks what should be promoted into MEMORY.md, or where an entry belongs.
• The user suspects duplicate, stale, or contradictory memory entries.
• Trigger phrases: "review my memories", "organize memories", "promote to MEMORY.md", "clean up memories", "memory review", "check for duplicate memories", "what should go in MEMORY.md", 整理记忆, 检查记忆, 记忆回顾, 清理记忆, 提升到 MEMORY.md。

When NOT to Use

• The user just wants something written to a memory file now -> write it directly with Edit/Write; the review-and-propose flow is unnecessary overhead.
• The user wants to change a tool's own settings (editor theme, IDE keybindings) -> that is not assistant memory; direct them to the tool's configuration.
• The target file does not exist and the user only wants it created -> create it, then optionally offer the review.

Workflow

Each step has a success criterion; do not advance until it is met.

1. Gather all memory layers. Read every existing memory file in the layers above. The auto-memory content is already in your system prompt — review it there. Note which team memory sections exist, if any. Success: you hold the contents of all layers and can compare them.
2. Classify each auto-memory entry. For every substantive entry, determine the best destination using the table in ## Decision Rules. Success: each entry has a proposed destination or is flagged as ambiguous.
3. Identify cleanup opportunities. Scan across all layers for duplicates (already captured in project/user memory), outdated entries (contradicted by newer auto-memory), and conflicts (contradictions between any two layers, noting which is more recent). Success: all cross-layer issues identified.
4. Present the report grouped by action type, per ## Output. Success: the user can approve or reject each proposal individually.

If auto-memory is empty, say so and offer to review existing memory files for cleanup instead.

Decision Rules

Destination mapping:

• Entry's destination is clear -> propose it directly.
• Entry is a tool preference (editor theme, IDE shortcuts) -> do NOT promote; not assistant memory.
• Entry looks like a workflow practice (PR conventions, merge strategy, branch naming) -> treat as ambiguous and ask the user whether it is personal or team-wide.
• Entry contradicts another layer -> propose resolving the older layer, stating which is newer.
• Still unsure -> ask via AskUserQuestion; do not guess.
• Need the layer definitions or the reasoning behind these rules -> read references/memory-layers.md.

Constraints

• Present all proposals before making any changes.
• Do NOT modify files without explicit user approval.
• Do NOT create new files unless the target does not exist yet.
• Ask about ambiguous entries — never guess a destination.
• Use AskUserQuestion for clarifications when needed.
• "No action needed" is a required conclusion category, not an omission.

Verification

Before reporting done:

• All memory layers present in the environment were actually read.
• Every substantive auto-memory entry has a proposed destination or an ambiguity flag.
• Duplicates, outdated entries, and conflicts were scanned across layers, not just within one.
• No file was modified; only proposals were produced.
• Every proposal is individually approve/reject-able by the user.

Output

A structured report grouped by action type:

1. Promotions — entries to move, with destination and rationale.
2. Cleanup — duplicates, outdated entries, conflicts to resolve.
3. Ambiguous — entries needing the user's input on destination.
4. No action needed — brief note on entries that should stay put.

• Outcome: a review report; no file changes.
• Done when: the user can review and approve/reject each proposal individually.
• Evidence: each proposal names the source layer, the target, and the reason; if auto-memory is empty, the report says so explicitly and offers cleanup of existing files.

References

Load only when needed:

• references/memory-layers.md — read when a destination is ambiguous, when the user asks why an entry belongs in one layer rather than another, or when two layers conflict and you need the tie-break rule.