repomind-prd

name	repomind-prd
description	同步历史 PRD/需求文档。先修正旧知识文件格式，再从 PRD 中提取业务概念，对照当前代码确认实际实现，合并更新 .repomind/concepts/ 的业务卡片与元数据；必要时再交给 repomind-summary 补充模块侧知识。
metadata	{"short-description":"从 PRD 提取业务知识"}

RepoMind PRD 业务知识补充

触发条件

只有当用户明确提供了历史 PRD / 需求文档 / 产品描述，并希望把它沉淀为业务知识时才执行。

不要在普通编码前分析、未来需求讨论、纯业务问答里自动触发。

核心原则

1. PRD 代表历史业务意图；当前代码代表当前事实。
2. 卡片写“当前代码实际做了什么”，不是照抄 PRD。
3. PRD 和当前代码不一致时，以当前代码为准，并记录差异。
4. 每次执行前先修正旧知识文件格式，保证后续都按新模板工作。

当前知识文件格式

所有 concept 文档都必须以以下 frontmatter 开头：

---

name: "..."
description: "..."
---

description 必须包含：

• 这个概念是什么
• 它出现在哪些业务场景
• 它与哪个相邻概念容易混淆，或关键边界是什么

步骤 0：先修正旧格式并读取元数据

先执行：

repomind kb-migrate
repomind kb-metadata

规则：

• 如果旧 concept 卡片缺 frontmatter，先修复再继续。
• 后续所有增量更新都必须保持新格式，不得回写旧结构。

步骤 1：获取输入

用户提供 PRD，支持：

1. 文件路径
2. 直接粘贴
3. URL

如果用户给的是文件路径，直接读取内容。

步骤 2：识别业务概念

逐段标记 PRD 中出现的概念，重点找：

• 业务对象
• 角色/身份
• 业务流程
• 业务规则
• 易混淆概念

输出一份内部清单，记录：

• 概念名
• 类型
• PRD 来源章节
• 一句话说明

步骤 3：先和现有卡片对比

不要一上来就改文档。先用 kb-metadata 输出的 concepts[].name/description 做首轮匹配：

• 已有等价卡片 → 标记“已存在”
• 已有卡片但需要补充 → 标记“待合并”
• 已有卡片但和代码事实冲突 → 标记“冲突修正”
• 没有卡片 → 标记“待新建”

只有在 metadata 级别命中后，才打开对应 concept 正文。

步骤 4：对照当前代码确认事实

按以下顺序核对：

1. 相关 concept 卡片
2. 相关 module 文档
3. 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。
• ## 来源 只记录“来自哪里 + 本次采纳了什么”，不重复追加相同来源。

去重规则：

1. 同义概念合并到一张卡
2. 同类规则合并到同一主题
3. 语义等价的规则不重复写
4. 同一来源不重复追加

步骤 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 是否需要更新
• 保持知识库格式为当前版本