| name | repomind-prd |
| description | 同步历史 PRD/需求文档。先修正旧知识文件格式，再从 PRD 中提取业务概念，对照当前代码确认实际实现，合并更新 .repomind/concepts/ 的业务卡片与元数据；必要时再交给 repomind-summary 补充模块侧知识。 |
| metadata | {"short-description":"从 PRD 提取业务知识"} |
RepoMind PRD 业务知识补充
触发条件
只有当用户明确提供了历史 PRD / 需求文档 / 产品描述，并希望把它沉淀为业务知识时才执行。
不要在普通编码前分析、未来需求讨论、纯业务问答里自动触发。
核心原则
- PRD 代表历史业务意图；当前代码代表当前事实。
- 卡片写“当前代码实际做了什么”，不是照抄 PRD。
- PRD 和当前代码不一致时，以当前代码为准，并记录差异。
- 每次执行前先修正旧知识文件格式，保证后续都按新模板工作。
当前知识文件格式
所有 concept 文档都必须以以下 frontmatter 开头：
---
name: "..."
description: "..."
---
description 必须包含：
- 这个概念是什么
- 它出现在哪些业务场景
- 它与哪个相邻概念容易混淆，或关键边界是什么
步骤 0：先修正旧格式并读取元数据
先执行：
repomind kb-migrate
repomind kb-metadata
规则：
- 如果旧 concept 卡片缺 frontmatter，先修复再继续。
- 后续所有增量更新都必须保持新格式，不得回写旧结构。
步骤 1：获取输入
用户提供 PRD，支持：
- 文件路径
- 直接粘贴
- URL
如果用户给的是文件路径，直接读取内容。
步骤 2：识别业务概念
逐段标记 PRD 中出现的概念，重点找：
- 业务对象
- 角色/身份
- 业务流程
- 业务规则
- 易混淆概念
输出一份内部清单，记录：
步骤 3：先和现有卡片对比
不要一上来就改文档。先用 kb-metadata 输出的 concepts[].name/description 做首轮匹配：
- 已有等价卡片 → 标记“已存在”
- 已有卡片但需要补充 → 标记“待合并”
- 已有卡片但和代码事实冲突 → 标记“冲突修正”
- 没有卡片 → 标记“待新建”
只有在 metadata 级别命中后，才打开对应 concept 正文。
步骤 4：对照当前代码确认事实
按以下顺序核对：
- 相关 concept 卡片
- 相关 module 文档
- graphify / 当前代码
只从代码中提炼这些维度：
- 触发时机
- 用户侧效果
- 数据来源
- 数据加工链路
- 关键边界条件
不要把 if/else、SQL、字段名、函数细节抄进 concept 卡片。
判断规则：
| 情况 | 卡片处理 |
|---|
| PRD 说 X，代码也做 X | 写 X |
| PRD 说 X，代码做 Y | 写 Y，并注明“PRD 说 X，当前实现为 Y” |
| PRD 说 X，代码找不到实现 | 标记“当前代码未找到实现，待核对” |
步骤 5：创建或更新 concept 卡片
概念卡片模板：
---
name: "Pro 角色"
description: "高级用户身份概念。用于判断权益范围、典型触发场景，以及和 VIP 的区别。"
---
# 概念：Pro 角色
## 是什么
（给出一句话业务定义，回答“这个概念本身是什么”）
## 为什么有
（写业务目的、设计背景或产品诉求；证据不足就写“待确认”）
## 用户侧表现
（写用户在哪些流程/页面/操作里能感知到它，以及感知到的效果）
## 系统侧数据流
（写数据来源、加工过程、最终消费位置，回答“系统里它怎么产生、怎么流转、怎么被使用”）
## 核心规则
（写稳定业务规则、边界条件、负向规则；按规则主题归并，不要抄代码分支）
## 易混淆概念
（写“不是谁”“区别于谁”“最容易被误解成什么”）
## 来源
（只记录来源和本次采纳点，例如“历史 PRD 第 2 节 + 当前代码核对结果”，不要贴长原文）
更新要求：
- 只增量合并，不整体覆盖。
name 保持概念规范名。- 如果新增了适用场景、边界或混淆点，必须同步更新
description。
## 来源 只记录“来自哪里 + 本次采纳了什么”，不重复追加相同来源。
去重规则：
- 同义概念合并到一张卡
- 同类规则合并到同一主题
- 语义等价的规则不重复写
- 同一来源不重复追加
步骤 6：输出 PRD 处理摘要
摘要至少包含：
- 输入来源
- 识别到多少概念
- 新建 / 合并 / 已存在 / 冲突修正 / 待核对 / 跳过 的数量
- 需要继续确认的点
步骤 7：自动调用 summary
只要本次新建或更新了 concept 卡片，就写入 .repomind/.query-findings.json 并调用 repomind-summary。
模板：
cat > .repomind/.query-findings.json << 'JSONEOF'
{
"trigger": "PRD 处理",
"intent": "从历史 PRD 提取业务概念并对照当前代码",
"known_modules": [],
"new_findings": [
{
"type": "concept_knowledge",
"module": "",
"file": "concepts/xxx.md",
"content": "从 PRD 提取并经当前代码对照后的业务概念"
}
],
"needs_summary": true
}
JSONEOF
然后调用：
Skill: repomind-summary
这里同样是同步阻塞步骤：
- 不要输出“summary 已经在跑”然后继续回答用户
- 必须等
repomind-summary 真正完成后，再结束 PRD 流程
- 如果当前平台不支持在 skill 内再次显式调用 skill，就在当前流程中直接执行
repomind-summary 的步骤，不要只写一句移交说明
这里的 summary 负责：
- 判断是否还需要同步模块文档
- 判断 concept / module 的 frontmatter
description 是否需要更新
- 保持知识库格式为当前版本
