By name: 511-requirement-doc-review description: 需求文档评审技能。需求文档整理完成后触发：(1)检查文档完整性与内容准确性, (2)确认需求可追溯性与验收标准可测试性, (3)验证需求变更记录完整性并输出评审结论。 alwaysApply: false author: "axeon(23231269@qq.com)" version: "1.0.0"
需求文档评审
项目环境检测
从当前目录向上查找 project-info.md，最多 3 层，找到后记为 PROJECT_ROOT。详见 检测方法与前置检查。未找到 → 提示用户先执行 0-init。
角色职责
| 角色 | 职责 | 智能体 |
|---|---|---|
| 主导 | 需求评审 | project-manager |
| 协作 | 需求解答 | product-manager |
| 协作 | 可测试性确认 | test-engineer |
| 协作 | 技术可行性 | system-architect |
源技能引用
评审必须先读取源技能文件获取原始约定，再基于约定进行评审，禁止仅凭模型自身知识评审。
| 源技能文件 | 评审时读取的内容 |
|---|---|
| 510-requirement-doc/SKILL.md | 必读全文：文档规范、交付物清单、完成标准 |
| 510-requirement-doc/references/templates.md | 文档模板 |
输入
| 输入项 | 来源 | 说明 |
|---|---|---|
| 需求文档 | PROJECT_ROOT/requirement/ |
6项需求文档 |
| 原始需求 | PROJECT_ROOT/requirement/ |
原始需求文档 |
| 实现代码 | 代码仓库 | 需求实现验证 |
输出
| 输出项 | 位置 | 说明 |
|---|---|---|
| 需求文档评审报告 | PROJECT_ROOT/requirement/reviews/REVIEW-PRD-YYMMDDHHMM.md |
评审结论和问题清单 |
报告格式详见 评审报告模板。
交付物清单
| 序号 | 交付物 | 评审要点 |
|---|---|---|
| 1 | PRD | 完整性、准确性、可追溯性 |
| 2 | 用户故事地图 | 覆盖度、逻辑性 |
| 3 | 业务流程图 | 准确性、完整性 |
| 4 | 功能清单 | 完整性、优先级 |
| 5 | 需求变更记录 | 变更原因、影响分析 |
| 6 | 验收标准汇总 | 可测试性、可验证性 |
评审维度
| 维度 | 检查要点 |
|---|---|
| 完整性 | 必需文档齐全、版本一致 |
| 准确性 | 需求清晰无歧义、业务逻辑正确 |
| 可追溯性 | 需求有唯一标识、来源可追溯 |
| 可测试性 | 验收标准具体可测 |
通过标准
| 等级 | 评分 | 条件 |
|---|---|---|
| 通过 | ≥ 95 分 | 无 Critical 问题，Major ≤ 2，文档 6 项齐全，内容准确，100% 可追溯 |
| 不通过 | < 95 分 | 存在 Critical 或 Major > 2 或文档不完整 |
评分 < 95 进入修复循环，无"有条件通过"中间态。
评审流程
开始评审前，先按"源技能引用"读取源技能，按"输入"读取所有评审对象。
1. 执行评审
按维度检查，记录问题。评审发现记录格式和评审报告结构详见 评审报告模板。报告中需包含"交付物检查"扩展统计节。
详细的评审检查清单见 checklist.md。
维度: 完整性/准确性/可追溯性/可测试性 评审对象: PROJECT_ROOT/requirement/ 参与人员: @project-manager @product-manager @test-engineer
2. 评审结论
计算最终评分后，按以下规则执行：
评分 ≥ 95（通过）：
- 标记评审状态为「通过」
- 输出评审报告，任务结束
评分 < 95（不通过）→ 自动修复循环：
- 立即调用
510-requirement-doc，传入问题清单 - 修复完成后立即重新执行本技能评审
- 若仍 < 95，回到步骤 1（最多 5 轮）
- 仅在通过或轮次耗尽时输出结果
此流程全自动执行：中间不暂停、不询问、不汇报。 未收到通过确认前，禁止结束本技能任务。