---

name: claude-remember description: "Review auto-memory entries and produce a report of proposed promotions across the memory hierarchy (project-level, user-level, daily log, shared), plus cleanup of duplicate, outdated, and conflicting entries. Adaptable to any AI agent's memory layout. Use when the user wants to review, organize, or promote their auto-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。用法：/claude-remember [optional focus area or specific memory to review]" allowed-tools: ["Read", "Write", "Edit", "Glob", "Grep", "AskUserQuestion"] argument-hint: "[optional focus area or specific memory to review]"

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:

Destination	What belongs there	Examples
项目 MEMORY.md	项目级约定和规范，所有协作者应遵循	"用 bun 不用 npm"、"API 路由使用 kebab-case"、"测试命令是 bun test"
用户 MEMORY.md	跨项目的用户个人偏好和习惯	"偏好简洁回复"、"总是解释 trade-off"、"运行测试前不要提交"
项目日报	每日工作日志，仅追加	当天完成的工作、技术选型、项目约定变更
保持在自动记忆	临时上下文、工作笔记、不明确归属的条目	会话特定观察、不确定的模式

• 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.