requirement-doc

name	requirement-doc
description	需求文档（PRD）生成 Skill（产品经理角色）。将产品灵感或需求分析结果转化为结构化的 PRD 文档，并生成低保真 HTML 原型图（wireframe），用于快速验证信息架构和交互逻辑。高保真原型由 `prototype-design` Skill（设计师角色）负责。参考 references 目录中的标准模板生成。触发条件：(1) 生成需求文档/PRD，(2) 将灵感转化为需求，(3) 需要产品需求文档模板，(4) 整理需求为正式文档，(5) 撰写产品方案，(6) 需求规格说明书，(7) 生成原型图/wireframe/线框图。

需求文档生成 Skill（产品经理角色）

将产品灵感或需求分析结果转化为结构化的 PRD（产品需求文档），并生成配套的低保真 HTML 原型图（wireframe），基于标准模板生成完整的需求文档。低保真原型为灰度线框图，重点是信息架构和功能布局的清晰表达，用于快速验证交互逻辑。

分工说明：高保真原型（Hi-Fi Prototype）由 prototype-design Skill（设计师角色）负责，基于本 Skill 产出的 PRD + wireframe 升级生成。当用户要求「高保真」「hifi」「高保真原型」时，应引导使用 prototype-design Skill 或 designer Agent。

参考文件

按需加载 references/ 目录下的模板文件：

文件	内容	何时加载
prd-template.md	主 PRD 标准文档模板（11 个章节，§4 为模块导航层）	所有需求文档生成任务
module-prd-template.md	模块 PRD 模板（7 个章节：模块概述、功能需求、用户故事、测试要点、交互设计、依赖/风险、变更记录）	模块化 PRD 生成模式
generation-prompt.md	模块化 PRD 生成流程（4 步：提取模块→主 PRD→模块 PRD→导航索引）	模块化 PRD 生成模式
wireframe-guide.md	低保真原型图生成规范（灰度线框图）	生成低保真原型图时

工作流

manifest 接入：本 Skill 写入 stages.prd。启动前必须执行 node scripts/workflow-manifest.js check {项目} prd 校验上游 intake；产出后调用 set {项目} prd 回写。详见 docs/workflow-manifest-spec.md。

步骤 1：收集输入

确定输入来源并提取关键信息：

迭代检测（优先执行）：检查目标路径 projects/prd-{项目名}/prd-{项目名}.md 是否已存在 PRD 文档。

• 若已存在：进入「迭代更新模式」，读取现有文档头的版本号、状态、变更记录，作为基线进行增量修改（版本管理规则见下方「版本管理」章节）
• 若不存在：进入「首次创建模式」，按下方步骤完整生成

来源 A：直接灵感描述

• 用户直接描述产品灵感或需求想法
• 提取核心功能点、目标用户、解决的痛点

来源 B：requirement_analyst 分析报告

• 若已通过 requirement_analyst Agent 生成分析报告，直接解析报告中的：
  • 需求概述（核心功能点、目标用户、痛点）
  • 竞品分析（市场空白、差异化机会）
  • 价值评估（综合评分、建议）
• 附录处理：将 requirement_analyst 分析报告全文收录为 PRD 「附录 A：需求分析报告」（参照 prd-template.md 附录 A 模板），并在 PRD §1.1 项目背景中添加引用：「立项验证详情见附录 A」

来源 C：飞书文档

• 使用 feishu-docs Skill 读取飞书上已有的需求草稿或讨论记录

如果输入信息不足，列出缺失的关键信息项并主动向用户追问，不要凭空编造内容。

步骤 1.5：变更影响分析与审批（迭代更新模式专有）

仅在步骤 1 检测到已有 PRD 并进入「迭代更新模式」时执行。首次创建模式跳过此步骤。

1.5.1 变更来源登记

记录本次变更的来源信息，用于后续追溯：

字段	说明	示例
变更来源类型	用户反馈 / Bug 修复 / 数据驱动 / 业务方需求 / 技术债务 / 竞品跟进	用户反馈
来源标识	关联的外部标识（飞书反馈单号、GitHub Issue ID、Bug ID、OKR 编号等）	#issue-42 / 飞书反馈单 FBK-2024-0315
变更发起人	提出变更请求的人	张三（产品经理）
变更原因	为什么需要这次变更（一句话）	用户调研显示 60% 用户需要批量导出功能

变更来源信息将记录到 §11 变更记录表的「来源标识」列中，确保每次变更可追溯。

1.5.2 变更影响分析

对照已有 PRD 和模块结构，分析本次变更的影响范围：

1. 模块影响扫描（模块化模式下必做）：

   • 列出本次变更直接修改的模块（Module PRD）
   • 根据各模块 §1.3 相关模块表，识别间接影响的关联模块（上游依赖 / 下游消费 / 双向协作）
   • 评估关联模块是否需要同步修改

2. 功能点影响矩阵：

   变更项	变更类型	直接影响模块	间接影响模块	影响的用户故事	影响的原型页面
   {变更描述}	新增/修改/删除	{module_en_slug}	{module_en_slug}	US-xxx-NNN	{page}.html

3. 非功能需求影响评估：检查变更是否影响 §5 中的性能、安全、兼容性等指标

4. RICE 评分复核：若为功能新增/修改，重新计算受影响功能点的 RICE 分，检查优先级排序是否需要调整

1.5.3 变更审批流程

根据步骤 5 版本管理规则中的变更级别，执行对应的审批流程：

变更级别	审批要求	审批人	审批方式
Patch（v1.0.X）	无需审批	—	直接修改，记录变更日志即可
Minor（v1.X.0）	产品负责人确认	产品经理 / 产品负责人	将变更影响矩阵发给审批人确认后再修改；可通过飞书消息或 GitHub PR Review 确认
Major（vX.0.0）	产品委员会 / 多方评审	产品负责人 + 技术负责人 + 业务方	必须召开变更评审会或在飞书文档中发起正式审批；需附变更影响分析报告

审批记录：审批结果记录到 §11 变更记录表的「审批人」列。Major 变更的评审记录建议以飞书文档链接形式附在变更摘要中。

1.5.4 输出变更影响摘要

在正式修改 PRD 前，向用户输出一份简要的变更影响摘要，包含：

• 变更级别判定（Patch / Minor / Major）
• 影响模块列表
• 需要同步更新的下游产物清单（见步骤 5 下游同步）
• 审批要求提示

确认用户认可后，再进入步骤 2 执行实际修改。

步骤 2：信息整理与追问

1. 加载 prd-template.md，了解 11 个章节的结构要求
2. 将步骤 1 收集到的信息逐一映射到模板的各章节
3. 识别缺失的关键信息，重点关注：
   • 功能优先级（P0/P1/P2）是否明确
   • 是否有非功能需求（性能、安全指标）及其验证方法
   • 验收测试策略是否明确（UAT 执行者、通过标准）
   • 里程碑和时间节点是否确定
   • 技术选型方向是否有偏好
4. 将缺失项汇总，向用户追问以补全
5. 如果用户表示某些信息暂时无法提供，在对应章节标注「待补充」

步骤 3：生成需求文档

模式选择（多维判定，v2 规则）：替代「机械的 ≥3 模块」单一阈值，启用模块化需满足以下信号 ≥2 个：

信号	触发条件
模块数	功能模块数 ≥ 3
UI 复杂度	pm_assistant §5.1 UI 评分 ≥ 13
团队规模	协作开发团队 ≥ 3 人或多团队
迭代周期	计划迭代 ≥ 2 个 Sprint
用户显式要求	用户明确要求「模块化 PRD」「按模块拆分」

命中 ≥2 → 进入模块化生成模式；命中 0–1 → 使用单文件模式。判定结果与命中信号必须写入 PRD §1.1「文档结构决策」段落，便于回溯。

3a. 模块化生成模式（默认推荐）

加载 generation-prompt.md 模块化生成流程，按 4 步执行：

Step 1 — 提取 Module 列表：

1. 从步骤 2 整理的功能信息中，按业务能力聚合出模块列表
2. 为每个模块生成中英文混合标识：
   • module_en_slug：小写英文、以 - 连接（如 task-management、time-management）
   • module_zh_name：中文显示名称（如 任务管理、时间管理）
3. 统计每个模块的功能点数量、最高优先级、模块间依赖关系
4. 输出模块清单（JSON 格式），供后续步骤使用

Step 2 — 生成主 PRD：

1. 加载 prd-template.md 模板
2. 填写 §1-3（背景/用户画像/用户故事）和 §5-11（非功能需求以后的章节）
3. §4 填写为导航层：
   • §4.1 模块导航表：列出所有模块的 slug、中文名、功能点数、最高优先级，以及指向 modules/prd-{module_en_slug}.md 的链接
   • §4.2 功能概览：全局功能汇总表（含 RICE 评分），但不写功能详细描述
4. 输出到 projects/prd-{项目名}/prd-{项目名}.md

Step 3 — 生成各模块 PRD：

1. 加载 module-prd-template.md 模板
2. 遍历模块清单，为每个模块生成独立的 Module PRD：
   • 填充模块元信息（slug、中文名、反向链接到主 PRD、相关模块）
   • 填充功能需求（§2）：功能概览表 + 功能详细描述（输入/输出/逻辑/异常）
   • 填充用户故事（§3）：从全局用户故事中筛选该模块相关的故事，编号格式 US-{module_en_slug}-NNN
   • 填充验收标准汇总表，按测试类型标注（[UI]/[API]/[Unit]/[Integration]）
   • 填充测试要点（§4）：从验收标准推导核心测试场景、边界条件、测试数据需求、测试类型分布
   • 填充交互设计（§5）：关联 wireframe 页面（以 {module_en_slug}- 为前缀的文件）
   • 填充依赖/风险/技术参考占位符（§6）
3. 输出到 projects/prd-{项目名}/modules/prd-{module_en_slug}.md

Step 4 — 生成导航索引：

1. 在 projects/prd-{项目名}/modules/ 目录下生成 README.md
2. 列出所有模块的 PRD 链接、架构文档链接（待生成）、原型图链接
3. 标注下游消费关系（architect → requirement-to-issues → gate_review）

3b. 单文件生成模式（向后兼容）

当模块数 < 3 或用户明确要求单文件模式时：

1. 加载 prd-template.md 模板
2. 按模板的 11 个章节逐一填写：
   • 替换所有 {xxx} 占位符为实际内容
   • 保留模板中的表格结构和格式
   • 确保每个章节都有实质内容或明确标注「待补充」
3. 遵循以下格式规范：
   • 用户故事使用 "作为{角色}，我想{操作}，以便{价值}" 格式
   • 功能需求标注优先级：P0（必须）、P1（重要）、P2（期望）
   • 功能需求使用 RICE 评分辅助排序（见下方说明）
   • 非功能需求包含可量化的指标
   • 风险项附带应对措施

RICE 评分框架（在功能概览表中为每个功能点增加 R/I/C/E/RICE 分 五列）：

• Reach（影响面）：该功能在一个周期内影响多少用户？（1-10）
• Impact（影响度）：对单个用户的影响程度？（3=巨大 / 2=高 / 1=中 / 0.5=低 / 0.25=极低）
• Confidence（信心度）：对以上估算的信心？（100%=高 / 80%=中 / 50%=低）
• Effort（工作量）：需要多少人月？（数值越大越费力）
• RICE 分 = (R × I × C) / E

RICE 数据来源标注要求（每个 RICE 因子必须注明数据来源和置信度）：

在附录 B「RICE 评分计算表」中，每个功能点的每个因子必须包含「数据来源」列和「置信度」列：

功能点	因子	取值	数据来源	置信度
智能推荐	R(Reach)	8	Google Trends 月搜索量 12K + 竞品 DAU 数据	📊 高（有数据支撑）
智能推荐	I(Impact)	2	用户访谈 N=10，80% 表示"非常需要"	📊 中（样本较小）
智能推荐	C(Confidence)	80%	—	⚠️ 中
智能推荐	E(Effort)	2	架构师初步评估	⚠️ 估算（建议验证）

置信度等级：

• 📊 高（有数据支撑）：基于埋点数据、用户调研(N≥10)、行业报告、竞品公开数据
• ⚠️ 中（部分数据）：基于小样本调研(N<10)、类比推断、专家判断
• ❓ 低（纯估算）：基于直觉或假设，无数据支撑，必须标注「估算，建议后续验证」

当某个因子置信度为「❓ 低」时，在功能概览表该功能点的 RICE 分后追加 * 标记（如 RICE: 6.4*），提示评审人该评分可靠性有限。

在 PRD 4.1 功能概览表中增加 R、I、C、E、RICE 分 五列，按 RICE 分从高到低排列，辅助 P0/P1/P2 的分级决策。当主观判断与 RICE 分冲突时，列出理由说明。

同时生成「附录 B：RICE 评分计算表」（参照 prd-template.md 附录 B 模板），展示每个功能点各因子的取值理由和计算过程，便于评审时复核。

步骤 4：生成低保真原型图

基于步骤 3 生成的 PRD 功能需求，为核心页面生成低保真 HTML 原型图（wireframe）。

1. 加载 wireframe-guide.md 低保真原型生成规范
2. 识别核心页面：从 PRD 的「功能需求」和「交互设计」章节中提取需要原型化的页面列表，优先覆盖：
   • P0（必须）功能涉及的所有页面
   • 核心用户操作流程的关键页面
   • 建议 3-8 个页面为宜
3. 生成 HTML 原型文件：
   • 每个页面生成一个独立的 .html 文件
   • 模块化模式下的命名规范：使用 {module_en_slug}-{page-name}.html 格式命名（如 task-management-list.html、reminder-settings.html），便于在 Module PRD 中按前缀关联
   • 使用纯 HTML + 内联 CSS，不依赖外部框架或 CDN
   • 遵循 wireframe-guide.md 的灰度配色、系统字体、占位元素规范
   • 页面之间通过相对链接互相跳转，形成可点击的交互流程
   • 生成一个 index.html 作为原型导航首页，列出所有页面及其功能说明，按模块分组展示
4. 文件输出位置：projects/prd-{项目名}/wireframes/（保持扁平结构，不按模块建子文件夹）
5. 在文档中引用：
   • 主 PRD「交互设计」章节（6.1）：添加所有原型图文件链接
   • 各 Module PRD「交互设计」章节（§4.2）：关联以该模块 module_en_slug 为前缀的原型页面

注意：低保真原型为灰度线框图，重点是信息架构和功能布局的清晰表达，不追求美观。如需高保真原型（品牌配色、图标、动效），请使用 prototype-design Skill 或 designer Agent 在此基础上升级。

步骤 5：输出与交付

版本管理规则（迭代更新模式必遵）

当步骤 1 检测到已有 PRD 时，在修改文档内容后必须执行以下版本管理操作：

1. 判断版本号递增类型：

   • Patch（v1.0.X）：措辞修正、错别字、格式调整、补充说明
   • Minor（v1.X.0）：新增/修改功能需求、调整优先级、新增用户故事
   • Major（vX.0.0）：产品方向重大调整、核心范围变更、目标重新定义

2. 更新文档头：递增版本号、更新「最后更新」日期、将状态设为「草稿」

3. 追加变更记录：在 §11 变更记录表格顶部插入新行（版本、日期、作者、变更类型、变更摘要、来源标识、审批人）

4. 检查关联架构文档：若为 Minor/Major 变更，提醒用户检查架构文档是否需要同步更新

5. 下游产物同步检查：根据变更级别，逐项检查并提醒用户同步更新受影响的下游产物：

   下游产物	Patch	Minor	Major	同步方式
   架构文档（architecture-*.md）	—	⚠️ 检查	✅ 必须更新	提醒用户使用 architect-doc Skill 重新评估
   Module PRD（modules/prd-*.md）	—	✅ 同步修改	✅ 重新生成	当前 Skill 直接更新受影响的 Module PRD
   低保真原型（wireframes/*.html）	—	⚠️ 检查	✅ 必须更新	识别受影响页面，更新或新增 wireframe
   高保真原型（hifi-wireframes/*.html）	—	⚠️ 检查	✅ 必须更新	提醒用户使用 designer Agent 同步
   GitHub Issues	—	⚠️ 检查	✅ 必须更新	提醒用户使用 requirement-to-issues Skill 更新/新增 Issue
   测试用例	—	⚠️ 检查	✅ 必须更新	提醒用户通知 QA 更新相关测试用例
   导航索引（modules/README.md）	—	⚠️ 检查	✅ 必须更新	当前 Skill 直接更新

   「⚠️ 检查」= 根据变更影响矩阵判断是否需要更新，输出检查结论；「✅ 必须更新」= 无条件同步。

   PRD 可直接同步的产物（由当前 Skill 执行）：Module PRD、低保真原型、导航索引。 需提醒用户手动触发的产物：架构文档、高保真原型、GitHub Issues、测试用例。

6. 生成下游同步清单：在完成 PRD 修改后，输出一份「下游同步待办清单」，列出每个受影响的下游产物、当前同步状态（已同步 / 待同步 / 不需要）、建议操作和负责人

根据用户需求选择交付方式：

默认：对话输出

• 在对话中直接输出完整的 PRD Markdown 文档

• 模块化模式下：先输出主 PRD，然后逐一输出各 Module PRD

• 输出完成后立即写入 manifest：

  echo '{
    "skill": "requirement-doc",
    "doc": "projects/prd-{项目}/prd-{项目}.md",
    "version": "v{X.Y.Z}",
    "module_count": {N},
    "modular": {true|false},
    "module_signals_hit": {命中的多维信号数}
  }' | node scripts/workflow-manifest.js set {项目} prd
  

可选：写入本地文件

• 主 PRD 写入 projects/prd-{项目名}/prd-{项目名}.md
• Module PRD 写入 projects/prd-{项目名}/modules/prd-{module_en_slug}.md
• 导航索引写入 projects/prd-{项目名}/modules/README.md

可选：发布到飞书

• 使用 feishu-docs Skill 的 create-doc 操作将 PRD 创建为飞书文档

可选：提交到 GitHub 并创建 PR

• 使用 github-publish Skill 将 PRD 文件提交到 GitHub：
  1. 基于 main 分支创建特性分支（建议命名 projects/prd-{项目名}）
  2. 将 PRD 文件（projects/prd-{项目名}/prd-{项目名}.md）提交到该分支
  3. 创建 Pull Request，标题格式：docs: 添加 {项目名} 产品需求文档（PRD）
  4. 在 PR 描述中简要说明需求背景和文档结构，并指定相关团队成员进行 Review

可选：导出到墨刀

• 使用 prototype-publish Skill 将核心页面原型发布到墨刀或 Figma，用于产品评审和团队协作展示：
  1. 从 PRD 功能需求中提取 P0 核心页面列表
  2. 按功能链路分组（每组 3-5 页），逐组生成 HTML 原型并导入墨刀
  3. 导入完成后汇总结果，便于在墨刀中进行评审

建议：执行 PRD 评审

• PRD 完成后，建议使用 gate_review Agent 执行 Gate 1（PRD 评审），确保需求完整性、商业合理性、可行性和原型质量达标后再进入架构设计阶段。

质量检查清单

生成 PRD 后，逐项自检：

通用检查项（所有模式）：

• 功能需求均有优先级标注（P0/P1/P2）
• 功能概览表包含 RICE 评分列，且优先级与 RICE 分基本一致（不一致处有说明）
• 用户故事遵循 "作为…我想…以便…" 标准格式，且包含验收标准
• 非功能需求包含可量化指标（如响应时间 ≤200ms）
• 非功能需求每行包含验证方法（如何验证该指标是否达标）
• §5.1 验收测试策略（UAT）已填写（测试范围、执行者、通过标准等）
• 里程碑有明确的时间节点
• 风险项列出了概率、影响和应对措施
• 术语表覆盖所有领域专业术语
• 文档无自相矛盾的描述
• 原型图覆盖所有 P0 功能的核心页面
• 原型图页面之间可通过链接跳转，形成完整操作流程
• 使用灰度线框风格，无外部框架或 CDN 依赖
• 若有 requirement_analyst 分析报告，已作为附录 A 附加并在 §1.1 中引用
• 功能概览表（§4.2）包含 R/I/C/E 各因子明细列
• 附录 B 包含完整的 RICE 评分计算过程及取值理由
• 【版本管理】文档头版本号与 §11 变更记录最新条目一致
• 【版本管理】状态字段已更新（草稿 / 评审中 / 已批准 / 已替代）
• 【版本管理】若为迭代更新，版本号已按规则递增且变更记录已追加
• 【版本管理】若为 Minor/Major 迭代，已提醒用户检查关联架构文档是否需同步更新
• 【变更追溯】迭代更新时，§11 变更记录中填写了来源标识（Issue ID / 反馈单号等）
• 【变更追溯】迭代更新时，§11 变更记录中填写了审批人（Minor/Major 变更）
• 【影响分析】迭代更新时，已执行变更影响分析并输出影响矩阵
• 【影响分析】模块化模式下，已识别直接影响和间接影响的模块
• 【影响分析】受影响功能点的 RICE 评分已重新复核
• 【审批流程】变更级别对应的审批流程已执行（Patch 无需 / Minor 产品负责人 / Major 多方评审）
• 【下游同步】已输出下游同步待办清单，标注各下游产物的同步状态和建议操作
• 【下游同步】PRD 可直接同步的产物（Module PRD、低保真原型、导航索引）已完成同步

模块化模式额外检查项：

• 主 PRD §4.1 模块导航表已填写所有模块的 module_en_slug、中文名、功能点数、链接
• 主 PRD §4.2 全局功能概览表中每行包含 module_en_slug + 中文名
• 每个模块均已生成独立的 Module PRD（modules/prd-{module_en_slug}.md）
• Module PRD 文档头包含反向链接到主 PRD
• Module PRD 中的用户故事编号格式为 US-{module_en_slug}-NNN
• Module PRD 中的验收标准按测试类型标注（[UI]/[API]/[Unit]/[Integration]）
• Module PRD §4 测试要点已填写：核心测试场景、边界条件、测试数据需求、测试类型分布
• Module PRD §4.1 核心测试场景覆盖所有 P0 验收标准
• modules/README.md 导航索引已生成，链接正确
• module_en_slug 符合命名规范（小写英文、- 连接）
• Wireframe 文件使用 {module_en_slug}-{page}.html 命名，Module PRD §5.2 正确引用
• 所有功能点在主 PRD 全局汇总表和对应 Module PRD 中都有出现（无遗漏）
• Module PRD §6.3 技术参考区域已标注为占位符（待 architect-doc skill 填充）
• （如选择导出到墨刀）P0 核心页面已通过 prototype-publish Skill 导入墨刀并确认可查看