菜单
每次 AI 完成代码修改、问答或排查结论后，且最终答复前，必须同步做轻量 summary gate 判断；代码写完后也要自动进入 gate。只有发现可复用的新业务知识、用户纠错、手动要求记忆的经验、模块边界、排查经验或知识文档元数据变化时，才执行写入。按类型更新 concepts、modules、troubles 及每个文档自己的 name/description，避免回到集中式索引。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
初始化 RepoMind 业务知识库。全量重建 graphify 图谱，保守生成高置信 concepts/modules 文档，并为每个知识文件写入 name/description 元数据。执行前会自动修正旧格式；初始化结束后会询问是否继续导入 PRD 业务知识。
同步历史 PRD/需求文档。先修正旧知识文件格式，再从 PRD 中提取业务概念，对照当前代码确认实际实现，合并更新 .repomind/concepts/ 的业务卡片与元数据；必要时再交给 repomind-summary 补充模块侧知识。
查阅业务逻辑、定位代码、排查问题，需求分析，方案设计时优先自动触发。先用每个 knowledge 文档的 name/description 元数据做 skill-style 路由，再按需打开 concepts、modules、troubles 和最小代码证据；代码定位优先使用模块文档入口和平台代码搜索小上下文，只有调用链、影响面或跨模块关系不足时才补查 graphify query/explain/path，回答前自动进入 repomind-summary gate；有新发现或用户纠错时写回 RepoMind。
| name | repomind-summary |
| description | 每次 AI 完成代码修改、问答或排查结论后，且最终答复前，必须同步做轻量 summary gate 判断；代码写完后也要自动进入 gate。只有发现可复用的新业务知识、用户纠错、手动要求记忆的经验、模块边界、排查经验或知识文档元数据变化时，才执行写入。按类型更新 concepts、modules、troubles 及每个文档自己的 name/description，避免回到集中式索引。 |
| metadata | {"short-description":"把可复用知识写回 RepoMind"} |
执行语义：本 skill 必须同步完成。
.query-findings.json + 输出 summary 摘要index.json；路由元数据写在各知识文档自己的 frontmatter。description 是首要检索摘要，modules 的 keywords 是辅助定位词。每次进入 summary 前先执行：
repomind kb-migrate
如果历史文件还是旧格式，这一步先修复，然后再继续更新。
先回答四个问题：
| 问题 | 判断 |
|---|---|
| 是否有新知识 | ✅/❌ |
| 是否可复用 | ✅/❌ |
| 是否有证据 | 用户确认 / 当前代码 / 排查结果 / 现有知识库 |
| 推荐写入目标 | concepts / modules / troubles / discard |
gate 不通过时，直接输出“无需更新”，不要写文件。
这里的“新知识”不只包括业务规则，还包括：
也就是说：只要本轮代码查找暴露出 RepoMind 路由缺口，这本身就是需要 summary 的新知识。
但是以下场景默认 gate 通过，必须进入完整 summary 流程：
modules 文档，转而直接查 graphify/source/rgkeywords优先读取：
cat .repomind/.query-findings.json 2>/dev/null || echo '{"needs_summary": false}'
如果没有这个文件，但本轮问答/排查确实形成了新知识，就按同样格式自行生成一个临时发现文件再继续。
如果没有这个文件，但用户在本轮明确纠正了旧说法，就按同样格式自行生成临时发现文件，并至少记录：
如果没有这个文件，但用户明确要求“记一下 / 总结到知识库 / 以后遇到这个要注意 / 这个经验要沉淀”，就按同样格式自行生成临时发现文件，并至少记录：
如果本轮存在“直接查代码才完成定位”的情况，即使 .query-findings.json 还没写，也必须自行补一份临时发现文件，至少包含一条 module_knowledge。
兼容旧类型时，先做归一化：
new_business_card / new_business_rule → concept_knowledgemodule_update / new_code_location / index_knowledge → module_knowledgetrouble_record → trouble_knowledge执行：
repomind kb-metadata
然后按 name / description 决定要打开哪些知识文档；对 modules 还要同时看 keywords。
不要直接全量打开所有 concepts/*.md、modules/*.md、troubles/*.md。
进入正文合并前，先单独判断：
写：
不写：
frontmatter description 必须覆盖：
写：
不写：
frontmatter description 必须覆盖：
frontmatter keywords 必须覆盖：
写：
frontmatter description 必须覆盖：
把发现分成三类：
| 类型 | 写入目标 |
|---|---|
concept_knowledge | .repomind/concepts/*.md |
module_knowledge | .repomind/modules/*.md |
trouble_knowledge | .repomind/troubles/*.md |
如果只是一次性上下文、纯代码显式信息或证据不足，归为 discard。
在分拣完成后，先做一次“元数据总结”：
description 应该重写或收紧keywords 应该新增、删除或去重模板：
---
name: "Pro 角色"
description: "高级用户身份概念。用于判断权益范围、典型触发场景，以及和 VIP 的区别。"
---
# 概念：Pro 角色
## 是什么
（一句话业务定义，回答“这个概念本身是什么”）
## 为什么有
（业务目的、产品背景、历史原因；没有证据就写“待确认”）
## 用户侧表现
（用户在哪些页面/流程/操作里能感知到它，表现为什么）
## 系统侧数据流
（数据从哪里来，经过什么处理，最终在哪里消费）
## 核心规则
（稳定规则、边界条件、负向规则；按主题合并，不抄实现分支）
## 易混淆概念
（它不是什么、和谁容易混、边界差异是什么）
规则：
descriptiondescription 是否仍能让模型在首轮路由时命中这张卡；如果不能，先改 description模板：
---
name: "支付模块"
description: "支付与退款相关模块。用于定位下单、回调、补偿入口和改动影响面。"
keywords:
- "支付"
- "payment"
- "退款"
- "refund"
- "回调"
---
# 支付模块
## 业务描述
（1-3 句话描述模块在业务上负责什么，不要变成目录树说明）
## 关键代码
（列真正该看的入口文件/函数，并说明为什么从这里开始）
## 常见修改场景
（列未来最常见需求的下手点，例如“改退款规则先看哪里”）
## AI 注意事项
（写隐性约束、跨模块联动、业务坑点、容易误改的地方）
规则：
AI 注意事项description 必须同步更新keywords 必须同步更新关键代码、常见修改场景 或 keywordsdescription 写不下的检索词，不要硬塞进句子，放进 keywordskeywords 以命中率为目标，不以完整性为目标；去掉噪音词，保留最能区分该模块的词keywordsdescription模板：
---
name: "VIP 延迟生效"
description: "处理 VIP 购买后权益未及时生效时查看。包含首查方向和常见根因。"
---
# 排查：VIP 延迟生效
## 当前状态
（写这条排查记录当前是否仍有效，例如“有效 / 已修正 / 已过期 / 待验证”）
## 问题
（用用户可感知的语言描述现象，回答“到底出了什么问题”）
## 排查路径
（按顺序写排查步骤，回答“第一次接手时应该先查什么、后查什么”）
## 根因
（写当前有效根因；如果旧结论被推翻，这里放最新结论）
## 验证方式
（写如何确认问题是否存在、修复是否生效，例如日志、数据对比、接口观察点）
## 涉及模块
（列相关业务模块，帮助后续从 trouble 跳到 module）
## AI 注意事项
（写最容易漏掉的判断条件、版本差异、历史坑点）
## 修订记录
（按时间记录什么时候新增、修正、失效，为什么改）
规则：
description 也要更新写完后执行：
repomind kb-metadata
rm -f .repomind/.query-findings.json
目的是确认：
name / descriptionkeywords摘要必须包含：
建议格式：
## RepoMind 更新摘要
### Summary Gate
- 是否有新知识：...
- 是否可复用：...
- 写入目标：...
### 知识写入路由
- 概念 A → concepts/xxx.md
- 模块 B → modules/xxx.md
- 排查 C → troubles/xxx.md
- 丢弃 D → 原因
### 元数据同步
- concepts/xxx.md：更新 description，补充适用场景
- modules/yyy.md：更新 description，补充影响面
- modules/yyy.md：更新 keywords，补充新的搜索词 / 别称 / 入口词