| name | ingest-prd |
| description | 将历史PRD内容录入标准三层文档体系:前置阶段完成需求ID确认、层级判断、内容提取;后置阶段完全复用 /new-prd 的文件创建、内容填充、质检门控和数据飞轮流程。不适用于新需求(用 /new-prd)、仅澄清需求(用 /requirement-clarifier)、更新已有PRD(用 /update-prd) |
| tags | ["prd","ingestion","history","registry"] |
| version | 3.0 |
触发条件(When)
用户提供历史PRD内容(任意格式)并请求录入 prds/ 体系时。
触发方式:/ingest-prd,随后提供原始PRD内容(需求ID可选)。
不适用场景
- 新需求(未上线)→ 改用
/new-prd
- 仅做需求澄清,不创建文件 → 改用
/requirement-clarifier
- 已有 prd.md 需要更新 → 改用
/update-prd
执行逻辑
【前置阶段】ingest 独有步骤
Step 0:读取上下文文件
执行前必须实际读取以下文件(不得使用记忆中的数据):
prds/_registry.md — 确认当前最高 ID 编号(必读,失败则停止执行)
drafts/_draft-registry.md — 确认草稿区已占用 ID(不存在时自动创建含表头的空文件)
context/iteration-requirement-list.md — 匹配需求ID(可选,见下方说明)
context/product-background.md — 辅助推断产品线(可选,缺失时跳过)
关于 iteration-requirement-list.md 缺失的处理:
- 文件存在 → 正常读取,用于 Step 0.5 的需求ID匹配
- 文件不存在或为空模板 → 输出以下提示后继续执行,所有需求按「情况C」处理:
⚠️ 未找到需求列表(context/iteration-requirement-list.md)。
建议先按 README Step 1.5 补充历史需求列表,可提升 ID 匹配准确率。
本次将跳过 ID 自动匹配,所有需求 ID 需手动确认。
Step 0.5:需求ID确认(前置确认,不创建任何文件)
情况A — 用户已提供需求ID:在清单中查找,确认标题是否与PRD内容匹配,输出:
确认:需求 [ID]「[标题]」与本PRD内容匹配,继续执行。
若不匹配,停下来告知用户,请用户确认正确的ID。
情况B — 用户未提供需求ID:从清单中按关键词搜索,列出最多3个候选:
在需求清单中找到以下候选,请确认哪个与本PRD对应,或告知"均不匹配":
· [ID1]「[标题]」— [所属迭代]
· [ID2]「[标题]」— [所属迭代]
情况C — 清单中完全未找到匹配项:标注为「未匹配」,继续执行,req-ids 置空,在录入报告中标记。
情况D — 标题截断或信息不完整:不得提前猜测写入。标注「标题截断,待补全」,待用户补充完整标题后再确认。
情况E — 多版本文档(源文件包含V1/V2/V3等多版本):
- 询问用户:哪个版本是当前生效版本?历史版本有无对应需求ID?
- 确认后方可继续,不得自行判断保留哪个版本
Step 1:确定 PRD 层级
根据以下规则自动判定,可被用户覆盖:
| 情况 | 层级 |
|---|
| 1条需求 + 功能简单(单页面/单场景) | story-card(SC-) |
| 2~6条需求 / 多场景 / 有明确页面结构 / 完整功能模块 | feature-prd(F-) |
| 7条��以上需求 / 跨迭代主题 / 含多子功能 / 架构底座类 | epic-prd(E-) |
判断后将理由记录,在录入报告中展示。
Step 2:提取历史内容,构建填充映射表
从原始PRD中提取内容,映射到标准章节结构:
| 提取内容 | 映射目标 |
|---|
| 需求背景、问题描述 | §3 需求概要 |
| 业务术语、概念定义 | §4 需求对象与概念模型 |
| 功能模块、业务流程 | §5 功能结构 |
| 用户故事、使用场景 | §6 用户故事与用例 |
| 功能点列表 | §7 功能清单 |
| 功能详细说明、规则 | §8 功能需求说明书 |
| 性能、安全、兼容性要求 | §9 非功能性需求 |
| 验收条件、测试用例 | §10 验收检查清单 |
| 不做的内容、排除项 | §11 范围外 |
| 遗留问题、待确认项 | §12 开放问题 |
提取原则:
- 有内容:保留原意,优化表达使其符合模板规范
- 可推断:结合需求名称、产品背景推断,标注
<!-- AI推断,请确认 -->
- 确实缺失:填写占位符
> ⚠️ 待补充:[说明缺少什么],不杜撰
- 多版本文档:只录入最新版本内容,历史版本演进摘要写入 CHANGELOG
多端差异说明:涉及国内站/国际站行为不同时,必须拆分为独立段落或表格,明确标注差异。
构建完映射表后,将以下信息传递给后置阶段:
- PRD 类型(story-card / feature / epic)
- 标题
- 各章节填充内容(映射表)
- 需求ID(req-ids)、上线日期、负责人(从需求清单获取)
- 多版本信息(如有)
Step 2.3:内容充分性判断
评估提取结果是否足以生成有效 PRD,命中以下任意一条则判定为「内容不足」:
| 不足信号 | 说明 |
|---|
| §3 需求概要完全缺失 | 无法判断需求目标和用户 |
| §6 用户故事为空且无任何使用场景描述 | 无法确定功能边界 |
| §8 功能说明全部为占位符 | 核心业务规则无从提取 |
| 可填充章节 ≤ 3 个(共10个) | 内容过于碎片化 |
判定为「内容不足」时,停止执行,输出:
⚠️ 导入内容不足以生成完整 PRD
当前可填充章节:[列表]
缺失关键信息:[具体说明缺什么]
建议先通过需求澄清补全信息,再录入 PRD:
/requirement-clarifier [标题]
澄清完成后重新运行 /ingest-prd,届时可将原始内容与 RDD 合并使用。
判定为「内容充分」时:继续执行,若存在部分章节不足(但未触发阻断条件),在 Step 2.5 摘要中列出,后续走占位符处理。
Step 2.5:输出前置阶段摘要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 前置分析完成
类型:[层级](判断依据:[一句话说明])
标题:[中文标题]
需求ID:[ID列表] | 来源:[用户提供|从清单匹配|未找到]
上线日期:[日期 | 未找到]
负责人:[姓名 | 未找到]
✅ 可填充章节:[列表]
⚠️ 待补全章节:[列表]
即将进入草稿创建流程...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【后置阶段】完全复用 /new-prd 流程
从此处开始,完整执行 /new-prd 命令的 Step 3 至结束,以下为关键适配说明:
Step 3(文件创建)适配:
Step 5(内容填充)适配:
Step 7(移入正式区)适配:
- 质检门控(
rules/prd-quality-gates.md)完整执行,❌ 项阻断移入
- 移入后的 context 文件同步(feature-map、glossary)、页面变更判断、需求池飞轮均完整执行
- 移入后额外更新
context/iteration-requirement-list.md:找到所有关联需求ID对应的行,将「关联PRD」列填入 [ID](../prds/[文件夹]/prd.md);req-ids 为空时跳过
输出语言规范
- 所有输出、问题、说明全部使用中文
- 禁止使用技术英文缩写代替中文表达(如 i18n → 多语言支持)
版本迭代日志(skill 自身)
| 版本 | 日期 | 变更 |
|---|
| 1.0 | 2026-04-05 | 初始版本,建立基础录入流程 |
| 2.0 | 2026-04-07 | 重大更新,修复8个已知问题 |
| 3.0 | 2026-05-12 | 架构重构:后置阶段完全复用 /new-prd 流程,消除重复维护;新增 Step 2 内容映射表、Step 2.5 前置摘要;质检门控、数据飞轮、草稿区流程全部对齐 new-prd |
| 3.1 | 2026-05-12 | 新增 Step 2.3 内容充分性判断(不足时退回 /requirement-clarifier);原始导入内容保存为 archive/original-v0.1.md,CHANGELOG 增加 v0.1 原始记录层 |