claude-remember git:20260925.32ce6c0A

Immutable. This exact content never changes and is served at /api/v1/blob/83a66f725d7438bc.

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