菜单
查阅业务逻辑、定位代码、排查问题，需求分析，方案设计时优先自动触发。先用每个 knowledge 文档的 name/description 元数据做 skill-style 路由，再按需打开 concepts、modules、troubles 和最小代码证据；代码定位优先使用模块文档入口和平台代码搜索小上下文，只有调用链、影响面或跨模块关系不足时才补查 graphify query/explain/path，回答前自动进入 repomind-summary gate；有新发现或用户纠错时写回 RepoMind。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
初始化 RepoMind 业务知识库。全量重建 graphify 图谱，保守生成高置信 concepts/modules 文档，并为每个知识文件写入 name/description 元数据。执行前会自动修正旧格式；初始化结束后会询问是否继续导入 PRD 业务知识。
同步历史 PRD/需求文档。先修正旧知识文件格式，再从 PRD 中提取业务概念，对照当前代码确认实际实现，合并更新 .repomind/concepts/ 的业务卡片与元数据；必要时再交给 repomind-summary 补充模块侧知识。
每次 AI 完成代码修改、问答或排查结论后，且最终答复前，必须同步做轻量 summary gate 判断；代码写完后也要自动进入 gate。只有发现可复用的新业务知识、用户纠错、手动要求记忆的经验、模块边界、排查经验或知识文档元数据变化时，才执行写入。按类型更新 concepts、modules、troubles 及每个文档自己的 name/description，避免回到集中式索引。
| name | repomind-query |
| description | 查阅业务逻辑、定位代码、排查问题，需求分析，方案设计时优先自动触发。先用每个 knowledge 文档的 name/description 元数据做 skill-style 路由，再按需打开 concepts、modules、troubles 和最小代码证据；代码定位优先使用模块文档入口和平台代码搜索小上下文，只有调用链、影响面或跨模块关系不足时才补查 graphify query/explain/path，回答前自动进入 repomind-summary gate；有新发现或用户纠错时写回 RepoMind。 |
| metadata | {"short-description":"先查 RepoMind 再回答"} |
任何涉及业务逻辑、代码修改、代码定位、项目结构、异常排查的提问，都必须先执行本流程。
纯技术问题可以跳过，例如依赖安装、语言语法、编译器通用报错。
index.json 或 README；优先依赖各知识文档自己的 name / description，其中 modules 还要额外使用 keywords。.repomind/.query-findings.json。repomind-summary 的 summary gate；gate 可以判定无需更新，但不能省略。needs_summary = true。负责回答：
frontmatter description 必须能回答：
负责回答：
frontmatter description 必须能回答：
frontmatter keywords 必须承担：
负责回答：
frontmatter description 必须能回答：
负责提供当前代码事实，不承担业务解释，也不让 AI 自行推断完整调用图：
查询阶段的主入口是 RepoMind 文档；平台代码搜索工具是代码定位主力，graphify 是关系补充，不是业务解释入口：
rg -n -C 3。.repomind/graph/summary.json 是初始化阶段的模块候选摘要，不作为 query 阶段的默认检索入口；除非当前流程已经打开了它，否则不要为回答用户问题专门读取它。在任何查询前，先执行：
repomind kb-migrate
如果仓库里还残留旧格式，这一步会先修复，再继续查询。
先执行：
repomind kb-metadata
读取 JSON 中三类信息：
concepts[].name/descriptionmodules[].name/keywords/descriptiontroubles[].name/description这一阶段只做 skill-style 首轮匹配，不打开全部 markdown 正文。
用户的问题可能同时包含多个维度：
回答前先做内部判断：
| 维度 | 是否激活 | 依据 |
|---|---|---|
| 业务概念 | ✅/❌ | 命中的业务词、预期、边界问题 |
| 代码模块 | ✅/❌ | 改哪里、入口、调用链、影响范围 |
| 异常排查 | ✅/❌ | 没生效、数据不一致、报错、异常 |
| 业务纠错 | ✅/❌ | 用户明确修正事实、边界、模块归属、入口、根因或历史结论 |
当业务概念维度激活时：
concepts[].name/description 做语义匹配。当代码模块维度激活时：
modules[].name/keywords/description 匹配。当异常排查维度激活时：
troubles[].name/description 匹配。只有以下场景才补查代码证据、图谱或结构化查询：
优先顺序：
graphify query / graphify explain / graphify path代码搜索方法：
先从模块文档入口、函数名、接口名、业务关键词中选 1-3 个最强关键词。
Claude Code：使用 Grep 定位匹配文件/行，再用 Read 只读取命中行附近的最小片段；不要为了看上下文直接全文件 Read。
Codex/终端：使用 rg -n -C 3 获取小上下文：
rg -n -C 3 "<入口名|函数名|接口名|业务关键词>"
如果命中太多，先加路径范围或更精确关键词，不要扩大到全量阅读：
rg -n -C 3 "<更精确关键词>" <模块文档给出的目录或文件>
代码搜索小上下文已经能确认入口、签名、关键分支、副作用或修改点时，停止读取更多源码。
只有小上下文不足以判断局部行为时，才打开对应文件的最小片段。
graphify 查询方法：
只有需要调用链、影响面、跨模块关系，或代码搜索定位不到可靠入口时，才做小预算定位：
graphify query "定位与 <业务词/接口/函数/模块> 相关的代码入口、调用关系或影响路径，返回最可能的文件、函数、模块和直接依据，不要展开无关背景。" --budget 800
如果 query 命中具体节点，再解释该节点：
graphify explain "<命中的文件/函数/模块/节点名>"
如果用户要求 A 到 B 的关系、调用链或影响路径，使用 path：
graphify path "<入口函数/模块/文件>" "<目标函数/模块/文件>"
如果 graphify CLI 不可用，不要改读 graphify-out/graph.json 或 GRAPH_REPORT.md；继续用平台代码搜索和最小源码片段兜底。
如果 graphify 输出只给出候选文件，没有给出明确调用边，则只能把它当作定位线索，再读取候选入口的最小源码片段确认当前事实。
调用关系约束：
graphify path 结果，或当前打开文件中的直接调用，才能作为 callers / callees 证据。强制总结规则：
modules 文档命中入口，而是依赖代码搜索、graphify 或源码片段继续找出来的，那么本轮结束前必须触发一次 repomind-summarymodule_knowledge，说明：
| 激活维度 | 推荐顺序 |
|---|---|
| 仅业务概念 | concepts → 必要时 modules/code |
| 仅代码模块 | modules → 代码搜索小上下文 → 必要时 graphify → 最小源码片段 |
| 仅异常排查 | troubles → concepts → modules → 代码搜索小上下文 → 必要时 graphify → 最小源码片段 |
| 业务概念 + 代码模块 | concepts → modules → 代码搜索小上下文 → 必要时 graphify → 最小源码片段 |
| 业务概念 + 异常排查 | concepts → troubles → modules |
| 代码模块 + 异常排查 | troubles → modules → 代码搜索小上下文 → 必要时 graphify → 最小源码片段 |
| 三者都有 | concepts → troubles → modules → 代码搜索小上下文 → 必要时 graphify → 最小源码片段 |
| 业务纠错 | 先定位被纠错的 concept/module/trouble → 当前代码或用户确认补证 → 保存修订发现 |
不要为了覆盖率把整个知识库都读一遍。
回答前必须明确：
回答要求：
如果本次查询发现了超出已有知识库的新知识，写入 .repomind/.query-findings.json。
只记录三类：
concept_knowledgemodule_knowledgetrouble_knowledge兼容旧类型时：
index_knowledge 视为 module_knowledgenew_business_card / new_business_rule 视为 concept_knowledgemodule_update / new_code_location 视为 module_knowledgetrouble_record 视为 trouble_knowledge模板：
cat > .repomind/.query-findings.json << 'JSONEOF'
{
"trigger": "问答",
"intent": "用户意图简述",
"known_modules": ["已命中模块"],
"new_findings": [
{
"type": "concept_knowledge|module_knowledge|trouble_knowledge",
"module": "主模块名",
"file": "concepts/xxx.md 或 modules/xxx.md",
"content": "新发现描述"
}
],
"needs_summary": true
}
JSONEOF
规则：
new_findings 为空时，needs_summary 必须为 falseneeds_summary 就必须为 trueneeds_summary = trueneeds_summary = true每次执行本流程后，最终答复前都必须自动调用：
Skill: repomind-summary
这是一个同步阻塞步骤，不是后台任务。
repomind-summary 完成前就回到主回答needs_summary == true 时，summary 必须处理 .repomind/.query-findings.jsonneeds_summary == false 或没有新发现时，也必须进入 summary gate，并等它明确判定“无需更新”后，才能给用户最终回复repomind-summary 的完整步骤，而不是口头移交对话过程中如果又出现了新的业务语义、模块边界或排查经验：
.repomind/.query-findings.jsonrepomind-summary不需要重新跑 query。
如果持续发现的是：
keywords也同样要按类型写入 concept_knowledge / module_knowledge / trouble_knowledge，然后触发 repomind-summary。