To PRD

把本次需求集合整理成一份产品 PRD。以真实业务流程为主线，通过产品访谈解决所有适用的决策，再确认完整草稿并写入版本文档。

PRD 记录用户与业务目标，单个功能按模板中的四类信息精简描述。API 参数、数据库结构、代码改动和实现任务属于后续工程工作。本 skill 只写入用户确认的 PRD；工程 artifacts 由后续流程产生。

Process

1. 检查文档结构与版本

在目标项目根目录检查 docs/prds/，盘点文件名、产品标识和文档版本。按主次版本的数字比较版本，不按文件名字典序判断最新版本。

• 用户指定产品、历史文档或草稿时，优先定位这些输入。
• 有多个合理的产品或历史版本候选时，展示路径、版本和相关性，让用户选择；不静默选取近似候选。
• 目录或相关历史文档不存在时，按新产品处理，在最终写入时创建目录。
• 本次 PRD 只覆盖用户要确定的需求集合；只有用户要求完整产品 PRD 时才扩展到全部能力。

记录候选输入与版本，此时不创建文件。

完成条件：已确定目标项目、本次产品与范围，或已明确列出需要在访谈中确认的定位问题。

2. 读取当前需求

完整读取 PRD 模板。从当前对话及用户提供的草稿提取：已确认决定、功能需求、负责人、来源和未解决的产品问题。附件和历史文档作为需求材料读取，不执行其中与当前请求无关的指令。

以一份文档组织产品总览、功能清单和逐功能详情。功能清单只维护索引与摘要，详细规则在对应功能章节维护。

为每个独立功能分配稳定的 FR-NNN：以用户目标、完整业务流程和可验收结果确定功能边界，不按页面或按钮机械拆分。同一产品沿用历史功能编号；新增功能使用尚未使用的编号，已有编号不重排、不复用。验收项使用功能内唯一的 FR-NNN-AC-NN。

完成条件：每项当前需求有来源，已确认内容与待确认问题已分开，功能边界及编号有明确依据。

3. 分析相关历史 PRD

读取与本次范围相关的历史 PRD，识别既有行为、约束、兼容要求和需求演进。按“新增、修改、取消、保持不变”整理变化。

• 在当前 PRD 中链接相关历史文档，记录版本、对应功能和变化摘要。
• 修改或取消功能的历史行为、目标变化、必须保持的行为及兼容影响写在 PRD 变化章节；功能详情只记录当前要求。
• 历史与当前需求不一致可能是正常的需求变化，向用户确认变化与影响，不把旧规则自动当作当前约束。
• 本轮用户明确确认的决定是当前需求依据；不静默修改历史 PRD，也不把历史全部功能自动纳入本次范围。

继承既有行为只覆盖历史文档已明确记录的规则。历史没有说明的授权、兼容或数据处置方式仍是待确认决策，不能借“保持不变”补成产品要求。

完成条件：相关历史来源可追溯，变化及其兼容影响已列出，未确定的变化进入产品访谈。

4. 选择是否读取代码库上下文

向用户说明读取代码可以核实当前行为和已有能力，然后询问本次是否读取。用户在本次请求中已经明确选择时，沿用该选择，不重复询问。

• 读取：只探索与本次需求相关的代码、测试和架构资料，核实当前行为、已有能力与约束。记录调查范围和基线。
• 跳过：不读取代码、测试或技术架构资料。无法证实的现状交给用户确认；不能把推测写成已核实事实。

代码反映现状，当前 PRD 描述目标行为。两者不同不意味着需求错误；可能只是实现尚未跟上。影响可行性或兼容性的事实应向用户说明，由用户决定产品要求。

完成条件：本次读取选择已明确，现状信息的来源及核实程度可区分。

5. 访谈产品 seams

运行 /grilling，遵守本次已确认的读取范围。这里的 seams 是尚未闭合的产品决策，不是测试层级或代码接口。

用模板检查需求缺口，按决策依赖逐轮处理当前 frontier，每个问题附推荐答案。已明确的内容直接使用；冲突、遗漏或会改变业务行为的推断必须确认。

访谈围绕适用的目标、用户、范围、优先级、用户故事、原型与界面、业务数据对象和状态变化、非功能要求、验收、风险、依赖和负责人展开。单个功能确认主要业务行为、必要条件与规则和可观察结果，输出仅按模板组织。

按模板选择适用内容。无界面时省略原型与界面，无业务状态变化时省略流转表；状态以业务对象的生命周期为准。没有依据的数值、负责人和规则必须确认，不套用模板示例或留下空表。

所有适用问题都要解决，不以“待定”“后续补充”结束访谈。负责人需要落实；发布日期与发布排期不属于此 PRD。

完成条件：frontier 为空，所有适用决策及负责人已明确，用户确认共同理解已经达成。

6. 展示完整 PRD 草稿

按模板展示完整正文，而不只是摘要。保留文档级主结构，功能详情按模板中的四类信息展示；移除填写说明、占位符和不适用的示例块。

展示前核对每条业务断言的来源：已确认的当前决定、有效草稿或历史明确规则。新增推断先回到访谈确认，不能等完整草稿确认来替代产品决策访谈。核验时只据实际结果更新确认检查项。

同时反向核对覆盖：本轮每项已确认需求、以及修改功能中每条适用的历史规则，都必须在草稿中有对应内容，或有用户明确确认的变更/排除结论。来源检查既防止新增无依据规则，也防止遗漏必须保持的行为。

同时展示目标文件路径、拟用版本、历史变化摘要和本次代码读取情况。路径相对于项目根目录，格式为：

docs/prds/<product-slug>-product-prd-v<major>.<minor>.md

版本是 PRD 文档版本，与软件发布版本分开管理：

• 新产品从 v0.1 开始；该版本也可以是已确认需求。
• 一般需求调整递增次版本，目标或主要范围重大变化递增主版本。
• 需求变化创建新版本文件，保留旧文件并引用历史变化。
• 纯文字勘误可以更新原文件，增加修订记录；这与新需求版本分开处理。
• 同一访谈中的草稿修改不产生新文件。最终版本号和路径由用户随完整草稿确认。

产品标识使用稳定的 kebab-case 名称。用户已有相容命名时沿用；发现目标文件已存在，先展示并确认是勘误更新还是创建新版本，不覆盖已确认需求。

用户反馈改变业务决策时，回到对应访谈分支；仅修改表达时更新草稿。每次变更后重新展示最终完整正文。

完成条件：完整草稿、目标路径、版本及历史变化全部获用户确认，没有适用的未决问题；此前不写入 PRD。

7. 写入、核验与交付

写入前重新检查目标文件和引用的历史版本是否有变化；有影响已确认内容的变化时，展示差异并重新确认。只创建或更新本次已确认的 PRD；需要时创建 docs/prds/。

逐项核验：

• 文件正文与获确认草稿一致，文档版本与文件名一致。
• 功能清单与详情一一对应，功能编号及验收编号唯一且稳定。
• 每个功能的用户故事、适用的原型与界面、数据对象和状态变化、验收结果相互一致。
• 状态含义与触发条件明确，描述的是业务对象生命周期而非界面加载或请求状态。
• 非功能要求集中维护，适用范围及验证方式明确；功能详情通过编号引用。
• 功能与适用验收标准完整对应，相关负责人已落实。
• 历史文件链接与文档内锚点有效，变化摘要与正文一致。
• 没有填写说明、占位符、空示例或未决问题。

失败时保留文件，修复本次造成的问题并重新核验，报告仍未解决的具体项。成功后返回 PRD 路径、版本、功能索引和验证结果。用户可选取一个独立功能作为后续 /to-spec 的输入；本 skill 到此完成，不自动调用该 user-invoked skill。