remember

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Memory Review

内存审核

Goal

目标

Review the user's memory landscape and produce a clear report of proposed changes, grouped by action type. Do NOT apply changes - present proposals for user approval.
审核用户的内存状况,并按操作类型分组生成清晰的修改建议报告。请勿直接应用修改——仅提交建议供用户批准。

Steps

步骤

1. Gather all memory layers

1. 收集所有内存层

Read CLAUDE.md and CLAUDE.local.md from the project root (if they exist). Your auto-memory content is already in your system prompt - review it there. Note which team memory sections exist, if any.
Success criteria: You have the contents of all memory layers and can compare them.
从项目根目录读取CLAUDE.md和CLAUDE.local.md(如果存在)。你的自动内存内容已包含在系统提示中——请在此处查看。记录是否存在团队内存部分(如有)。
成功标准:你已获取所有内存层的内容并可进行对比。

2. Classify each auto-memory entry

2. 对每个自动内存条目进行分类

For each substantive entry in auto-memory, determine the best destination:
DestinationWhat belongs thereExamples
CLAUDE.mdProject conventions and instructions for Claude that all contributors should follow"use bun not npm", "API routes use kebab-case", "test command is bun test", "prefer functional style"
CLAUDE.local.mdPersonal instructions for Claude specific to this user, not applicable to other contributors"I prefer concise responses", "always explain trade-offs", "don't auto-commit", "run tests before committing"
Team memoryOrg-wide knowledge that applies across repositories (only if team memory is configured)"deploy PRs go through #deploy-queue", "staging is at staging.internal", "platform team owns infra"
Stay in auto-memoryWorking notes, temporary context, or entries that don't clearly fit elsewhereSession-specific observations, uncertain patterns
Important distinctions:
  • CLAUDE.md and CLAUDE.local.md contain instructions for Claude, not user preferences for external tools (editor theme, IDE keybindings, etc. don't belong in either)
  • Workflow practices (PR conventions, merge strategies, branch naming) are ambiguous - ask the user whether they're personal or team-wide
  • When unsure, ask rather than guess
Success criteria: Each entry has a proposed destination or is flagged as ambiguous.
针对自动内存中的每个实质性条目,确定最佳目标位置:
目标位置适用内容示例
CLAUDE.md所有贡献者都应遵循的项目约定及针对Claude的指令"使用bun而非npm", "API路由使用短横线命名法(kebab-case)", "测试命令为bun test", "优先使用函数式风格"
CLAUDE.local.md针对当前用户的Claude专属个人指令,不适用于其他贡献者"我偏好简洁的回复", "始终解释权衡利弊", "不要自动提交", "提交前先运行测试"
团队内存适用于所有仓库的组织级知识(仅当配置了团队内存时)"部署PR需通过#deploy-queue", "预发布环境地址为staging.internal", "平台团队负责基础设施"
保留在自动内存中工作笔记、临时上下文或无法明确归类到其他位置的条目会话特定观察结果、不确定的模式
重要区分
  • CLAUDE.md和CLAUDE.local.md包含针对Claude的指令,而非用户对外部工具的偏好(如编辑器主题、IDE快捷键等不属于这两者)
  • 工作流实践(PR约定、合并策略、分支命名)存在歧义——询问用户这些是个人规则还是团队规则
  • 不确定时,询问用户而非猜测
成功标准:每个条目都有建议的目标位置,或被标记为歧义条目。

3. Identify cleanup opportunities

3. 识别清理机会

Scan across all layers for:
  • Duplicates: Auto-memory entries already captured in CLAUDE.md or CLAUDE.local.md → propose removing from auto-memory
  • Outdated: CLAUDE.md or CLAUDE.local.md entries contradicted by newer auto-memory entries → propose updating the older layer
  • Conflicts: Contradictions between any two layers → propose resolution, noting which is more recent
Success criteria: All cross-layer issues identified.
扫描所有内存层,查找:
  • 重复条目:已在CLAUDE.md或CLAUDE.local.md中存在的自动内存条目 → 建议从自动内存中移除
  • 过时条目:被较新的自动内存条目否定的CLAUDE.md或CLAUDE.local.md条目 → 建议更新旧内存层
  • 冲突条目:任意两个内存层之间的矛盾内容 → 建议解决冲突,并注明哪个内容更新
成功标准:所有跨层问题均已识别。

4. Present the report

4. 生成报告

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 where you need the user's input on destination
  4. No action needed - brief note on entries that should stay put
If auto-memory is empty, say so and offer to review CLAUDE.md for cleanup.
Success criteria: User can review and approve/reject each proposal individually.
按操作类型分组输出结构化报告:
  1. 提升建议 - 需移动的条目,包含目标位置和理由
  2. 清理建议 - 需处理的重复条目、过时条目和冲突内容
  3. 歧义条目 - 需要用户确认目标位置的条目
  4. 无需操作 - 简要说明应保留在原位置的条目
若自动内存为空,请告知用户并主动提出审核CLAUDE.md以进行清理。
成功标准:用户可逐一查看并批准/拒绝每个建议。

Rules

规则

  • Present ALL proposals before making any changes
  • Do NOT modify files without explicit user approval
  • Do NOT create new files unless the target doesn't exist yet
  • Ask about ambiguous entries - don't guess
  • 在进行任何修改前,先提交所有建议
  • 未经用户明确批准,请勿修改文件
  • 除非目标文件不存在,否则请勿创建新文件
  • 对模糊条目进行询问——不要猜测