prd
SuperBot PRD — 产品需求文档编写技能
背景：
进入2025年8月，随着公司鼓励我们全员拥抱AI提升生产力之后，产品经理已经完全可以通过 Coding Agent 实现端到端的简易产品需求交付，但是研发流程不允许产品经理触碰线上代码，以致于产品经理交付产品给用户前，依然需要研发进行实现，产品经理向研发交付的标准交付物就是PRD；而当产品经理通过多次和Coding Agent交互聊天已经完成产品实现后，再回过头来写一份完整的PRD，看起来变得多余和费时，因此，本skill通过已实现的产品来输出PRD。
支持文件
- PRD 模板：
templates/prd-template.md（位于本 skill 目录下）
命令：/superbot:prd update
将已实现的功能 Demo 转化为标准 PRD 文档，供研发团队据此实现该功能。
这是产品经理与研发之间的正式交付物，务必遵守以下原则：
- 功能描述必须基于代码，不得臆造未在代码中体现的功能
- 无法从代码直接推导的内容（如背景、目标、用户故事等），你必须先根据上下文和已有信息给出合理推荐值，让用户确认或修正，不得直接将空白项抛给用户让其自行填写
- 表达简洁，不在 PRD 内容之外输出任何冗余话术
执行流程
第一步：确认功能模块
询问用户：本次 PRD 针对哪个功能模块？
用户会以下列两种格式之一提供：
- URL 格式：
http://localhost:8080/home/feature.htm - 文件路径格式：
src/pages/home/feature.htm
无论哪种格式，目的都是定位当前工程中的具体功能模块代码。
URL 格式的处理逻辑：
- 提取 URL 路径部分（如
/home/feature.htm），在当前工程的常见前端目录下查找对应文件（src/pages/、src/views/、pages/、app/等） - 若无法匹配，直接告知用户：「无法通过该 URL 定位到对应文件，请提供源码路径」，不要继续推测
文件路径格式的处理逻辑：
- 检查该文件是否存在
- 若不存在，告知用户并请其重新确认路径
定位成功的标准：你能找到对应的源码文件，并能读取其内容进行分析。
若用户提供了多个功能模块，逐一确认每个模块是否均能定位。有任何一个无法定位，都需先解决再继续。
第二步：读取并分析功能模块
定位到源码后，深度阅读该功能模块的相关代码，包括：
- 页面/组件结构
- 交互逻辑与状态管理
- 数据流与接口调用
- 边界处理与异常情况
- 路由配置
分析目标：形成对该功能的完整、准确理解，作为 PRD 编写的唯一依据。
第三步：确认 PRD 输出路径
询问用户：PRD 文件输出到哪里？
路径校验规则：
| 用户输入 | 处理方式 |
|---|---|
| 目录路径（无文件名） | 报错：「请提供具体的 .md 文件路径，例如：docs/prd/feature.md」 |
| 单个 .md 文件路径 | 若文件已存在 → 执行更新；若不存在 → 递归创建目录后新建文件 |
| 多个 .md 文件路径 | 执行拆分写入（见下方「多文件拆分」规则） |
第四步：重新读取 PRD 与代码
进入 PRD 编写前，必须先执行以下两项操作：
- 重新读取 PRD 文件：如果目标 PRD 文件已存在，立即重新读取其全文。用户可能在 Agent 之外手动编辑过 PRD，你必须基于最新内容进行操作，保持信息一致。
- 重新分析工程代码：重新阅读并分析该功能模块的最新源码。代码是 PRD 的唯一事实来源，PRD 中已有内容仅供参考，若 PRD 描述与代码实现不一致，以代码为准。你的任务是使用最新代码实现来更新 PRD，而不是被 PRD 已有内容带着跑。
第五步：生成或更新 PRD
新建 PRD
- 读取本 skill 目录下的
templates/prd-template.md作为结构基准 - 基于第四步的代码分析，填写所有可从代码推导的模板内容（功能需求、交互流程、数据字段、接口需求等）
- 对于无法从代码直接推导的内容（如背景、目标、Non-Goals、用户故事等），先预留，在第六步逐一与用户确认，不得留空抛给用户
更新现有 PRD
核心原则：全面检查，精细修改。
- 全面检查：逐节对比现有 PRD 与当前代码实现，找出所有不一致之处：
- PRD 描述的功能，代码中未实现
- 代码实现的功能，PRD 中未描述或描述有误
- 交互逻辑、状态、边界处理与实际不符
- 精细修改：只改必须改的部分，不重写整个文档：
- 新增遗漏的功能点
- 修正与实现不符的描述
- 删除代码中已不存在的功能
- 保留与实现一致的已有内容
- 更新完成后，同步更新文档信息中的「最后更新」和「变更记录」
多文件拆分写入
若用户提供多个输出文件：
- 根据功能模块的自然边界，判断哪部分功能属于哪个文件
- 若拆分方式不明确，必须与用户确认拆分方案，不得自行决定
- 确认后，按各文件对应的功能范围独立执行生成或更新流程
第六步：逐一确认待推导内容
PRD 正文（可从代码直接推导的部分）写入完成后，在进入第七步的完成确认之前，必须对无法从代码直接推导的内容进行逐一推荐和确认。
核心要求：
- 每次只确认一个最小确认单元，不得一次性抛出多个字段或一个表格
- 每项确认时，你必须先给出推荐值，不得直接问用户"你有什么想法"或"需要我提供推荐值吗"
- 用户确认或修改后，立即写入 PRD，再继续下一项
最小确认单元定义
以下每一项都是独立的确认单元，必须逐一确认：
- 功能名称
- 所属模块
- 作者（默认取当前系统用户名，通过
whoami或$USER获取） - 1.1 背景
- 1.2 目标
- 1.3 Non-Goals
- 每条用户故事（如有 8 条故事，就是 8 个独立的确认单元，每条单独确认）
- 6. 非功能性要求（即使没有明确信息，也要基于项目类型给出合理推荐值，如"性能：页面首屏加载 < 2s"等）
- 8. 待确认问题（如有发现则推荐填写，如无则推荐"暂不记录"）
交互格式
每个确认单元统一使用以下格式：
接下来确认【字段名】：
我推荐的值是：[推荐内容]
是否采纳？如需修改请直接告诉我，或回复"暂不填写"。
- 用户确认或给出修改值后，立即将该值写入 PRD
- 如果用户回复"暂不填写"，则该项保持留空，继续下一项
- 全部确认完成后进入第七步
第七步：完成确认
PRD 写入完成后，简短输出：
- 已操作的文件路径
- 本次新增 / 修改 / 删除的主要内容（一句话摘要）
- 如有用户选择「暂不填写」的项，列出清单提醒用户后续补充
待确认问题处理规则
第 8 节「待确认问题」默认保持空白。
如果你认为存在需要确认的问题：
- 以对话形式向用户提出，说明具体问题和可能的影响
- 用户明确表示「写入 PRD」或类似确认后，才将条目填入表格
- 不得自行填充任何未经用户明确确认的条目
内容质量标准
每一条 PRD 内容，必须同时满足：
| 维度 | 标准 |
|---|---|
| 可实现 | 研发能明确知道要做什么，不需要猜测 |
| 可验证 | 测试能据此写出验收用例 |
| 有来源 | 每条描述都能在代码中找到对应依据 |
| 无歧义 | 不使用「可能」「一般来说」「通常」等模糊措辞 |