| name | yy-memory |
| description | 管理项目的分层记忆系统,包括 work-log 更新、新记忆生成、容量检查和归档。 由用户手动执行本技能后触发记忆更新,不用于普通查询或非提交场景。
|
yy-memory
描述
分层记忆管理系统的项目私有技能,负责在代码提交后自动更新和维护项目记忆。
记忆库位置:.memory/(项目根目录,个人私有)
容量限制:
- MEMORY.md ≤ 8KB(硬限制)
- 单个 hub ≤ 50KB(建议)
- 单个 leaf ≤ 5KB(建议)
使用场景
- 用户手动执行本技能(
yy-memory)更新记忆
- 用户明确提到"更新记忆"、"记录这次提交"
不应触发:
- 用户只是查询项目信息
- 用户要求修改或删除代码
- 用户进行非提交操作(如只读查询、配置查看)
指令
步骤 0. 初始化记忆库
检查 .memory/ 目录是否存在:
- 存在:跳过初始化,继续步骤 1
- 不存在:自动创建完整记忆库结构
- 创建目录:
.memory/、.memory/hubs/、.memory/leaf/
- 创建核心文件:
MEMORY.md、CATALOG.md、ARCHIVE.md、work-log.md(空白模板)
- 创建 5 个 hub 文件(
hub-1-project-knowledge.md ~ hub-5-tool-usage.md,空白模板)
- 初始文件内容为占位符模板,不含具体记忆数据
步骤 1. 获取提交信息
执行 git 命令获取最近一次提交的信息:
git log -1 --pretty=format:"%H|%s|%an|%ad" --date=iso 获取提交哈希、消息、作者、日期
git diff --stat HEAD~1..HEAD 获取变更统计
步骤 2. 分析变更内容
根据 git diff 结果,判断变更类型:
- 功能新增:新增了功能模块或文件
- Bug 修复:修改了 bug 或错误
- 文档更新:只修改了文档文件
- 重构优化:修改了代码结构但功能不变
- 配置变更:修改了配置文件
步骤 3. 更新 work-log
在 .memory/work-log.md 中追加新条目:
## {YYYY-MM-DD}
- [{提交类型}] {提交消息摘要}
- 文件变更:{变更文件数} 个
- 提交哈希:{短哈希}
如 work-log.md 不存在,从模板生成。
步骤 4. 评估是否生成新记忆
决策分支:
- 变更类型为"功能新增"或"架构决策":评估是否值得记录为长期记忆
- 其他类型:跳过长期记忆生成
值得记录为长期记忆的内容:
- 新增了重要的项目约定或规范
- 修改了核心架构或设计模式
- 引入了新的技术栈或工具
- 发现了重要的 bug 并修复
- 发布了新的版本或里程碑
评估流程:
- 分析变更涉及的核心文件
- 判断是否符合长期记忆标准
- 如符合,在对应 hub 下创建新的 leaf 记忆
步骤 5. 生成新叶子记忆(可选)
如步骤 4 评估认为值得记录:
- 确定应归属的 hub
- 在
.memory/hubs/ 下找到对应 hub 文件
- 在
.memory/leaf/ 创建新的 leaf 文件
- 更新 hub 文件中的 leaf 引用
- 更新
.memory/CATALOG.md
Leaf 文件命名:leaf-{主题}-{日期}.md
步骤 6. 运行容量检查
执行 scripts/src/main.ts 脚本,检查各层容量:
- MEMORY.md 是否超过 8KB
- 各 hub 和 leaf 的大小分布
- 长期未访问的记忆(超过 30 天未修改)
决策分支:
- MEMORY.md 超限:提醒用户"MEMORY.md 超过 8KB,建议整理索引"
- 存在可归档记忆:建议用户将长期未访问的记忆移入 ARCHIVE.md
- 容量正常:输出正常状态
步骤 7. 输出结果
必须输出:
- 提交摘要:提交类型、消息、作者、日期
- 更新的记忆文件:work-log 及可能的 leaf/hub
- 容量检查结果:是否正常、是否有警告
- 人工处理建议:如有需要用户关注的事项
安全边界
- 只读取 git 信息,不修改任何 git 历史
- 只追加 work-log,不删除已有内容
- 生成新记忆需要用户确认,不自动创建
- 容量检查只报告,不自动删除或归档
相关资源
.memory/MEMORY.md:核心路由
.memory/CATALOG.md:完整目录
.memory/ARCHIVE.md:归档库
.memory/hubs/:主题枢纽目录
.memory/leaf/:叶子记忆目录
scripts/src/main.ts:容量检查脚本