memory-tidy

Memory 整理技能

整理 MCP [memory_mcp] 中的项目记忆数据，包括功能记录、修复记录、笔记和标签。

前置准备

1. 获取项目列表: 使用 project_list 查看所有项目
2. 选择目标项目: 让用户确认要整理的项目
3. 获取项目详情: 使用 project_get 获取完整数据

整理流程

步骤 1: 整理 Feature 功能记录

1. 识别重复功能: 查找描述相似或功能相同的记录
2. 合并重复项:
   • 重要：只有状态一致的条目支持合并（pending 只能和 pending 合并，completed 只能和 completed 合并）
   • 选择保留的主要记录（通常是描述更完整或更新的）
   • 合并前必须向用户确认，说明合并原因
   • 将其他重复记录的标签合并到主记录
   • 如有关联笔记，选择保留最完整的
   • 删除被合并的重复记录
3. 清理标签: 移除无意义或重复的标签

合并确认格式：

即将合并以下功能记录：

保留: [ID] 描述内容...
删除: [ID] 描述内容...

合并原因: [说明为什么这两个记录重复/相似]

是否确认合并？(y/n)

操作示例:

# 1. 查看功能列表
project_get(project_id="xxx", group_name="features")

# 2. 合并标签到主记录
project_item_tag_manage(project_id="xxx", group_name="features", item_id="主记录ID", operation="add", tag="被合并记录的标签")

# 3. 删除重复记录
project_delete(project_id="xxx", group="features", item_id="重复记录ID")

步骤 2: 整理 Fix 修复记录

1. 识别重复修复: 查找相同问题的多次记录
2. 合并重复项:
   • 重要：只有状态一致的条目支持合并（pending 只能和 pending 合并，completed 只能和 completed 合并）
   • 合并前必须向用户确认，说明合并原因（同 Feature 格式）
   • 其余逻辑同 Feature 合并
3. 检查关联: 确保修复记录正确关联到相关 Feature

步骤 3: Feature → Fix 迁移

有些 Feature 记录实际上描述的是 Bug 修复，需要迁移：

判断标准:

• 描述中包含 "修复"、"fix"、"bug"、"问题" 等关键词
• 内容主要是解决某个问题而非新增功能

迁移操作:

# 场景A: 全部内容都是修复
# 1. 在 fix 分组创建新记录
project_add(project_id="xxx", group="fixes", content="修复描述", severity="medium", tags="原标签")

# 2. 删除原 feature 记录
project_delete(project_id="xxx", group="features", item_id="原ID")

# 场景B: 部分是修复
# 1. 为修复部分创建 fix 记录
project_add(project_id="xxx", group="fixes", content="修复部分内容", related_feature="原featureID")

# 2. 更新原 feature，移除修复部分
project_update(project_id="xxx", group="features", item_id="原ID", content="仅保留功能部分")

步骤 4: 整理 Note 笔记

前置：理解 Note 关联的意义

Note 是 Feature 或 Fix 的细节补充，它们之间存在语义关联：

• 关联了 feature 的 note → 是该功能的技术细节/实现说明
• 关联了 fix 的 note → 是该修复的原因分析/解决方案细节
• 无关联的 note → 独立的开发笔记/临时记录

---

4.1 删除 Note 的判断

核心原则：有关联的 note 是 feature/fix 的补充，不应轻易删除

删除前检查流程：
1. 查询 feature 和 fix 列表，检查 note_id 是否指向该 note
2. 如果有关联 → 保留该 note，它是补充说明
3. 如果无关联 → 可以删除（独立的临时笔记）