| 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/ 目录下的模板文件：
工作流
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 和模块结构，分析本次变更的影响范围：
-
模块影响扫描（模块化模式下必做）：
- 列出本次变更直接修改的模块（Module PRD）
- 根据各模块 §1.3 相关模块表，识别间接影响的关联模块（上游依赖 / 下游消费 / 双向协作）
- 评估关联模块是否需要同步修改
-
功能点影响矩阵：
| 变更项 | 变更类型 | 直接影响模块 | 间接影响模块 | 影响的用户故事 | 影响的原型页面 |
|---|
| {变更描述} | 新增/修改/删除 | {module_en_slug} | {module_en_slug} | US-xxx-NNN | {page}.html |
-
非功能需求影响评估：检查变更是否影响 §5 中的性能、安全、兼容性等指标
-
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：信息整理与追问
- 加载 prd-template.md，了解 11 个章节的结构要求
- 将步骤 1 收集到的信息逐一映射到模板的各章节
- 识别缺失的关键信息，重点关注：
- 功能优先级（P0/P1/P2）是否明确
- 是否有非功能需求（性能、安全指标）及其验证方法
- 验收测试策略是否明确（UAT 执行者、通过标准）
- 里程碑和时间节点是否确定
- 技术选型方向是否有偏好
- 将缺失项汇总，向用户追问以补全
- 如果用户表示某些信息暂时无法提供，在对应章节标注「待补充」
步骤 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 列表：
- 从步骤 2 整理的功能信息中，按业务能力聚合出模块列表
- 为每个模块生成中英文混合标识：
module_en_slug：小写英文、以 - 连接（如 task-management、time-management）module_zh_name：中文显示名称（如 任务管理、时间管理）
- 统计每个模块的功能点数量、最高优先级、模块间依赖关系
- 输出模块清单（JSON 格式），供后续步骤使用
Step 2 — 生成主 PRD：
- 加载 prd-template.md 模板
- 填写 §1-3（背景/用户画像/用户故事）和 §5-11（非功能需求以后的章节）
- §4 填写为导航层：
- §4.1 模块导航表：列出所有模块的 slug、中文名、功能点数、最高优先级，以及指向
modules/prd-{module_en_slug}.md 的链接
- §4.2 功能概览：全局功能汇总表（含 RICE 评分），但不写功能详细描述
- 输出到
projects/prd-{项目名}/prd-{项目名}.md
Step 3 — 生成各模块 PRD：
- 加载 module-prd-template.md 模板
- 遍历模块清单，为每个模块生成独立的 Module PRD：
- 填充模块元信息（slug、中文名、反向链接到主 PRD、相关模块）
- 填充功能需求（§2）：功能概览表 + 功能详细描述（输入/输出/逻辑/异常）
- 填充用户故事（§3）：从全局用户故事中筛选该模块相关的故事，编号格式
US-{module_en_slug}-NNN
- 填充验收标准汇总表，按测试类型标注（
[UI]/[API]/[Unit]/[Integration]）
- 填充测试要点（§4）：从验收标准推导核心测试场景、边界条件、测试数据需求、测试类型分布
- 填充交互设计（§5）：关联 wireframe 页面（以
{module_en_slug}- 为前缀的文件）
- 填充依赖/风险/技术参考占位符（§6）
- 输出到
projects/prd-{项目名}/modules/prd-{module_en_slug}.md
Step 4 — 生成导航索引：
- 在
projects/prd-{项目名}/modules/ 目录下生成 README.md
- 列出所有模块的 PRD 链接、架构文档链接（待生成）、原型图链接
- 标注下游消费关系（architect → requirement-to-issues → gate_review）
3b. 单文件生成模式（向后兼容）
当模块数 < 3 或用户明确要求单文件模式时：
- 加载 prd-template.md 模板
- 按模板的 11 个章节逐一填写：
- 替换所有
{xxx} 占位符为实际内容
- 保留模板中的表格结构和格式
- 确保每个章节都有实质内容或明确标注「待补充」
- 遵循以下格式规范：
- 用户故事使用 "作为{角色}，我想{操作}，以便{价值}" 格式
- 功能需求标注优先级：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）。
- 加载 wireframe-guide.md 低保真原型生成规范
- 识别核心页面：从 PRD 的「功能需求」和「交互设计」章节中提取需要原型化的页面列表，优先覆盖：
- P0（必须）功能涉及的所有页面
- 核心用户操作流程的关键页面
- 建议 3-8 个页面为宜
- 生成 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 作为原型导航首页，列出所有页面及其功能说明，按模块分组展示
- 文件输出位置：
projects/prd-{项目名}/wireframes/（保持扁平结构，不按模块建子文件夹）
- 在文档中引用：
- 主 PRD「交互设计」章节（6.1）：添加所有原型图文件链接
- 各 Module PRD「交互设计」章节（§4.2）：关联以该模块
module_en_slug 为前缀的原型页面
注意：低保真原型为灰度线框图，重点是信息架构和功能布局的清晰表达，不追求美观。如需高保真原型（品牌配色、图标、动效），请使用 prototype-design Skill 或 designer Agent 在此基础上升级。
步骤 5：输出与交付
版本管理规则（迭代更新模式必遵）
当步骤 1 检测到已有 PRD 时，在修改文档内容后必须执行以下版本管理操作：
-
判断版本号递增类型：
- Patch（v1.0.X）：措辞修正、错别字、格式调整、补充说明
- Minor（v1.X.0）：新增/修改功能需求、调整优先级、新增用户故事
- Major（vX.0.0）：产品方向重大调整、核心范围变更、目标重新定义
-
更新文档头：递增版本号、更新「最后更新」日期、将状态设为「草稿」
-
追加变更记录：在 §11 变更记录表格顶部插入新行（版本、日期、作者、变更类型、变更摘要、来源标识、审批人）
-
检查关联架构文档：若为 Minor/Major 变更，提醒用户检查架构文档是否需要同步更新
-
下游产物同步检查：根据变更级别，逐项检查并提醒用户同步更新受影响的下游产物：
| 下游产物 | 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、测试用例。
-
生成下游同步清单：在完成 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：
- 基于
main 分支创建特性分支（建议命名 projects/prd-{项目名}）
- 将 PRD 文件（
projects/prd-{项目名}/prd-{项目名}.md）提交到该分支
- 创建 Pull Request，标题格式：
docs: 添加 {项目名} 产品需求文档（PRD）
- 在 PR 描述中简要说明需求背景和文档结构，并指定相关团队成员进行 Review
可选：导出到墨刀
- 使用
prototype-publish Skill 将核心页面原型发布到墨刀或 Figma，用于产品评审和团队协作展示：
- 从 PRD 功能需求中提取 P0 核心页面列表
- 按功能链路分组（每组 3-5 页），逐组生成 HTML 原型并导入墨刀
- 导入完成后汇总结果，便于在墨刀中进行评审
建议：执行 PRD 评审
- PRD 完成后，建议使用
gate_review Agent 执行 Gate 1（PRD 评审），确保需求完整性、商业合理性、可行性和原型质量达标后再进入架构设计阶段。
质量检查清单
生成 PRD 后，逐项自检：
通用检查项（所有模式）：
模块化模式额外检查项：
