| name | forsion-prd |
| description | Forsion-PRD structured product requirement workflow. Guides PMs through dialogue-based requirement gathering, PRD drafting, HTML prototype creation with Tailwind CSS, Mermaid flowcharts, and final PRD with iframe sandbox slices. Use when creating PRD, writing requirement documents, designing prototypes, or when the user says /forsion-prd. Triggers: 产品需求文档, 写PRD, 产品需求, 需求梳理, 需求文档, 原型设计, user journey, requirement gathering. |
Forsion-PRD 产品需求产出工作流
快速入口：项目状态检测
在开始前，先检查用户工作区是否已有 Forsion-PRD 项目结构（存在 prd/、prototype/、docs/ 目录）。
- 全新项目（无已有结构）：从步骤一开始完整执行。
- 已有需求文档但无原型（存在
prd/ 但无 prototype/ 内容）：确认需求后跳转步骤四。
- 已有原型需迭代（存在
prototype/ 文件）：确认迭代范围后跳转步骤七的版本管理流程。
- 仅更新 PRD / 流程图：定位到对应步骤（五/六）直接执行，遵守下方「持久规则」同步更新。
无论从哪个步骤进入，均须遵守「持久规则」。
触发方式
当用户提供初步想法或需求描述时，严格按照以下七个步骤逐步引导。
强制执行规则：必须一步一步执行，绝不允许一次性输出所有步骤的结果。每个标注【等待用户确认】的步骤结束后，必须停止输出，等待用户回复。
持久规则：开发期实时文档同步（全程最高优先级）
此规则贯穿所有步骤，优先级高于其他所有指令。
每当执行以下任意操作时，必须在同一轮响应中完成所有关联文档更新，不得拖延：
| 触发操作 | 必须更新的位置 |
|---|
| 新增或修改任何功能实现 | PRD §四 + §五 |
| 修复影响用户行为的 bug | PRD §七 或 §五 + Bug Review + Bug Index |
| 修改数据结构 / 接口字段 | PRD §十 或 §五 数据流描述 |
| 发现遗漏的边界或异常情况 | PRD §七 新增条目 + Bug Review（若有解决方案） |
| 完成某个功能模块（用户满意） | PRD 版本记录表 + docs/index.html + Log 增量更新 + Function Review + Function Index |
| 版本交付（步骤六/七完成） | 以上所有 + 版本汇总文档（Document/vX.X.md） |
文档记录联动（Document/）—— 全部自动，无需提醒
Document/ 是项目的开发知识库，Log、Bug Reviews、Function Reviews 均由 AI 自动写入：
- Log：每完成一个阶段性开发（步骤三/四/六/七），在
Document/Log/ 中增量追加当前版本日志，记录做了什么、实现方式、是否否定了前期方案。
- Bug Reviews：发现并修复了交互问题、或 PRD §七 新增异常条目时，自动在
Document/Bugs/ 中写 Bug Review，更新 Bug Index.md。
- Function Reviews：某功能模块达到用户满意、或步骤六 §五 完成某详细方案模块时，自动在
Document/Function/ 中写 Function Review，更新 Function Index.md。
- 版本汇总文档：每个版本交付时（步骤六/七），在
Document/ 根目录创建 vX.X.md，关联该版本所有 Log、Bug Reviews、Function Reviews，列出交付物清单和遗留问题。
命名格式、触发细则和所有模板详见 document-conventions.md。
版本记录与文档库索引的更新格式详见 prd-html-conventions.md。
步骤一：对话式需求采集与确认
新手往往难以一次性说清需求。采用灵活对话式引导，主动评估、温和追问、总结确认。在需求未明确前，不要创建文件或文件夹。
可选增强：如果用户提供了 PDF 格式的需求文档或竞品报告，使用 pdf-reader MCP 工具提取文本内容作为需求输入源。
1.1 接收需求
- 接受用户的任意形式输入（一句话、截图、草图、大白话、PDF 文件）。
- 不要要求用户填写复杂的固定模板，降低认知门槛。
1.2 核心维度评估与反馈
接收到用户的初步需求后，必须展示以下 7 个关键维度的评估结果：
- 背景/痛点：为什么要做？现状有什么问题？（必须）
- 业务目标：做完后想达到什么效果？（必须）
- 用户与场景：谁在什么具体情况下使用？（必须）
- 核心用户旅程：用户从接触到完成目标的关键路径，包含触点和痛点。（必须）
- 现有方案：现在他们是怎么解决这个问题的？（重要）
- 业务规则：有哪些必须遵守的限制或特定流程？（重要）
- 参考/竞品：有没有喜欢的对标产品？（加分项）
1.3 深度追问与多轮确认 【等待用户确认】
关键规则：不要急于总结，必须进行至少 3 轮深度的启发式追问。
- 采用开放式、启发式提问，每次 3~5 个问题。
- 基于用户上一次回答挖掘新盲点，至少 3 轮对话。
- 只有当用户明确表示"没有补充了，可以开始写了"时，才进入下一步。
- 强制暂停：每一轮提问后必须停止输出。
步骤二：项目初始化与目录架构搭建
2.1 建立标准目录树
创建以项目名称命名的根文件夹，包含以下子目录：
docs/：文档库入口（index.html）prd/：产品需求文档prototype/：高保真 HTML 原型flowcharts/：Mermaid 流程图annex/：附件（数据字典、需求原始文稿等）templates/：工作流模板或参考文件Document/：开发知识库（与全局文档记录原则对齐）
Document/Log/：版本开发日志（每阶段自动更新）Document/Bugs/：Bug 记录与分析报告Document/Function/：功能实现方案记录
2.2 初始化 Document/ 索引
在 Document/Bugs/ 下创建 Bug Index.md（含表头的空表格），在 Document/Function/ 下创建 Function Index.md（含表头的空表格）。索引模板见 document-conventions.md。
同时在 Document/ 根目录创建本版本的汇总文档 v1.0.md，状态标记为「进行中」，交付物清单、Log/Bug/Function 关联区留空待后续自动填入。
2.3 初始化文档库
读取本 skill 目录下的 docs_hub_template.html 模板，将其内容复制为 docs/index.html，并替换以下占位符：
[PROJECT_NAME] → 当前项目名称#project-desc → 项目一句话目标描述#project-version → v1.0#last-updated → 今天日期
2.4 确认架构
向用户展示目录结构，说明 docs/index.html 是文档入口，Document/ 是开发知识库。
步骤三：输出"详细的第一版初步 PRD"
关键规则：初步 PRD 也必须非常详细，不能只是空框架。
3.1 产出内容
生成详细的初步 HTML 格式 PRD（存放在 prd/），结构参考 prd_template.md 和 prd-html-conventions.md 中的标准 10 章目录。深度填充：
- 项目基本信息
- 需求背景与目标（含四列表格）
- 用户使用场景与旅程图（User Journey Map 表格）
- 详细功能清单与基础逻辑
后续章节（详细方案、流程图）注明"待原型确认后补充"。
3.2 更新开发日志 & 版本汇总
- 在
Document/Log/ 中创建当前版本的 Log 文件（如 v1.0-初版PRD.md），记录需求采集结论和 PRD 骨架结构。
- 在
Document/v1.0.md 的「关联开发日志」中添加该 Log 文件的链接。
3.3 用户确认 【等待用户确认】
询问用户确认方向和基础逻辑，说明下一步将进入原型设计阶段。
步骤四：产出高保真 HTML 原型（核心验证阶段）
4.1 原型规范
- 单文件 HTML 原型，包含完整 CSS。
- 强制使用 Tailwind CSS，现代简洁设计风格。
- 必须包含关键交互状态，通过 JavaScript 或 URL Hash 实现页面切换。
- Focus Mode：必须实现 URL 参数解析（
?focus=feature_id），锁定无关区域。详细规范见 iframe-sandbox-spec.md。
可选增强：如果用户的 IDE 环境支持 Pencil MCP（.pen 文件编辑器），可以先用 Pencil 工具产出设计稿再转为 HTML 原型。
推荐搭配：如果用户安装了 Impeccable 前端设计指令集，调用其规范（如 /typeset、/arrange）提升原型视觉品质。
4.2 原型审查与迭代循环 【等待用户反馈】
- 呈现 HTML 原型，引导用户思考交互边界。
- 强制暂停：等待用户反馈修改意见。
- 每次修改原型后，按「持久规则」同步更新 PRD、文档库索引和
Document/Log/。
- 自动触发 Bug Review：审查中修复了交互问题 → 在
Document/Bugs/ 写 Bug Review，更新 Bug Index，在版本汇总文档「关联 Bug Reviews」中添加链接。
- 自动触发 Function Review：某功能模块用户表示满意 → 在
Document/Function/ 写 Function Review，更新 Function Index，在版本汇总文档「关联 Function Reviews」中添加链接。
- 用户对原型完全满意后，进入步骤五。
步骤五：输出流程图（Mermaid）
原型跑通后，输出核心业务流程图。语法规范与示例见 mermaid-guidelines.md。
- 使用 Mermaid 语法（
flowchart TD 或 sequenceDiagram）。
- 重点描绘核心操作主线与异常分支。
- 确保无渲染错误（特殊字符需转义）。
步骤六：产出最终版 PRD（内嵌原型与切片）
综合前五步成果，输出最终的详细产品需求文档。
6.1 格式与结构
HTML 格式，Tailwind CSS，独立可运行。完整的排版规范和 10 章标准结构详见 prd-html-conventions.md。
6.2 详细方案设计
PRD §五 必须采用模块化分块布局（流程图 + 规则 + 沙盒原型），具体规范和 HTML 模板见 iframe-sandbox-spec.md，完整示例见 feature-module-example.html。
6.3 版本交付：完结 Document/ 记录
步骤六完成即版本交付，必须同步完成以下文档收尾：
- Log：在
Document/Log/ 当前版本 Log 文件末尾追加「最终交付」记录（交付物清单、各模块状态）。
- Function Reviews：步骤六 §五 中每个完成的详细方案模块，若尚未写 Function Review，此处补齐；更新 Function Index。
- 版本汇总文档：将
Document/vX.X.md 状态改为「已交付」，填入完整的交付物清单，补全所有 Log/Bug/Function 关联链接，填写遗留问题。
交付检查清单：
步骤七：版本迭代与管理
7.1 文件物理隔离
绝对不要直接覆盖历史版本。迭代时将 prd_v1.0.html 和 prototype_v1.0.html 各复制一份并重命名为新版本号。所有修改仅在新版本文件中进行。
7.2 PRD 版本切换器
PRD HTML 右上角必须有版本切换下拉菜单。历史版本页面顶部显示警告横幅并引导跳转最新版。
7.3 变更日志与双向联动
- 在新版 PRD 的版本记录表中详细记录变更。
- 所有 iframe 嵌入路径必须统一指向对应版本的原型文件（如
../prototype/prototype_v1.1.html）。
- 在
Document/Log/ 中新建当前版本 Log 文件（如 v1.1-迭代.md），记录迭代范围、与上一版本差异、是否否定了前期方案。
- 在
Document/ 根目录创建新版本汇总文档（v1.1.md），状态为「进行中」，在「版本变更摘要」中引用上一版本汇总文档，迭代过程中持续关联新产生的 Bug/Function Reviews，版本交付时按 6.3 完结。
参考资料索引
