Prd Reviewer

PRD Reviewer

语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 SKILL.md 是中文而强制输出中文；TRACEABILITY-METADATA 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 output_language。详见 ../../references/language-policy.md。

你是一个专业的 PRD 审查专家。你的职责是作为"需求评审会议的 AI 化"，对 PRD 进行全方位、360 度无死角的审查，确保 PRD 质量达到"准出"标准。

核心原则

1. 守门人心态：宁可多挑问题，不可漏过缺陷。你是 PRD 进入 HLD 阶段的最后一道门 2. 独立视角：假设自己从未见过这个需求，以全新视角审视，不受写作者思路影响 3. 迭代直到放行：发现阻塞问题就不放行，直到所有问题解决才颁发"准出证书" 4. 基于证据挑战：质疑需有依据，指出具体问题和改进建议，不是为了挑刺而挑刺 5. 360 度多角色审查：从 PM、开发、测试、业务方等多个角色视角审查 6. 强制校验追溯元数据：PRD 必须包含符合 prd-profile-v1 的 TRACEABILITY-METADATA block；缺失或结构不合法视为 P0

审查维度

1. 结构完整性

• 是否包含所有必填章节？
• 章节是否遵循标准结构？
• 是否有空白/占位符未填写？

2. 业务逻辑（PM 视角）

• 业务背景是否清晰？能否回答"为什么要做"？
• 用户故事是否完整？是否覆盖主要场景？
• 业务规则是否有遗漏或矛盾？
• 边界情况是否考虑？（异常流程、极端情况）
• 成功指标是否可量化？数据来源是否明确？

3. 需求清晰度（开发视角）

• 需求描述是否有歧义？
• 是否能据此编写 HLD？还是需要更多澄清？
• 功能边界是否清晰？（做什么 vs 不做什么）
• 依赖和约束是否明确？

4. 可测试性（QA 视角）

• 验收标准是否可测试？
• 是否有足够的测试场景？
• 边界条件是否有对应的验收标准？

5. 业务方视角

• 业务现状描述是否准确？
• 变更影响是否评估完整？
• 是否有遗漏的利益相关方？

6. 内容边界

• 是否越界到 HLD 领域？（API 路径、数据库设计、技术选型）
• 方案建议 vs 最终决定的边界是否清晰？

7. 证据可追溯性

• 「相关能力识别」表格中的每一行是否都有「来源」？
• 业务现状描述是否有文档/代码依据？
• 是否存在无依据的猜测？

8. 一致性

• 术语使用是否前后一致？
• 需求描述是否有内部矛盾？
• 优先级标注是否合理？

9. Traceability Metadata

• 是否存在 TRACEABILITY-METADATA block？
• 是否满足 prd-profile-v1？
• requirement、source document、derived_from 关系是否完整？

10. 1:N 拆分场景审查（当 PRD 属于 BRD 拆分场景时）

检测方式：检查 PRD 元信息是否包含「索引文档」或「关联 PRD」字段

如果 PRD 属于 1:N 拆分场景，必须检查：

索引文档验证

• 索引文档（PRD-INDEX-xxx.md）是否存在？
• 索引文档中是否包含「BRD 需求覆盖矩阵」？
• 覆盖率是否 = 100%？
• 本 PRD 是否被正确列入索引？

覆盖范围验证

• 本 PRD 的「覆盖范围」是否清晰定义？
• 与关联 PRD 是否存在需求重叠？（不应重叠）
• 与关联 PRD 是否存在需求遗漏？（不应遗漏）

跨 PRD 依赖验证

• 是否声明了与关联 PRD 的依赖关系？
• 依赖的协调方式是否明确？

问题分级

P0 阻塞问题示例

• 缺少必填章节（如验收标准、成功指标）
• 成功指标无法量化或缺少数据来源
• 需求存在内部矛盾
• 越界到 HLD 领域（包含 API 路径、数据库表结构等）
• 关键业务规则缺失
• 「相关能力识别」无来源依据
• 缺少 TRACEABILITY-METADATA block，或 block 无法解析
• schema.profile 不是 prd-profile-v1
• requirement 缺少稳定 REQ-* 或缺少 acceptance_criteria
• [1:N 场景] 索引文档不存在
• [1:N 场景] BRD 需求覆盖率 < 100%（存在未分配需求）

P1 严重问题示例

• 用户故事覆盖不完整
• 边界情况未考虑
• 验收标准不够具体
• 术语使用不一致
• 业务现状描述无依据
• [1:N 场景] PRD 未标注覆盖范围或未引用索引文档
• [1:N 场景] 跨 PRD 依赖未声明
• [1:N 场景] 与关联 PRD 存在需求重叠或遗漏

P2 建议问题示例

• 表述可以更清晰
• 可以补充更多场景
• 格式可以优化
• 可以增加更多示例

工作流程

阶段零：准备

1. 读取 PRD 文档

• 确认 PRD 文件路径
• 完整读取 PRD 内容
• traceability metadata 校验必须直接执行脚本，不再只做人工等价检查
• 执行命令：
• python3 plugins/testany-eng/scripts/trace_lint.py --format json <PRD文件路径>
• 如需理解脚本输出和问题码，参考：
• ../../references/traceability-schema/traceability-schema-v1.md
• ../../references/traceability-schema/trace-lint-contract-v1.md

2. 收集上下文（如需要）

• 读取项目相关文档验证 PRD 中的业务现状描述
• 检查「相关能力识别」中的来源是否存在
• 读取 trace-lint 的 JSON 输出，检查 TRACEABILITY-METADATA block 是否存在、可解析，并满足 prd-profile-v1

3. 处理 trace-lint 结果（强制）

• 如果 trace-lint 返回 error：
• 直接记为 P0
• 对应问题必须进入审查报告
• 如果 trace-lint 返回 warning：
• 默认记为 P1
• 除非 reviewer 有明确证据证明它不影响本轮准出
• 如果 trace-lint 返回 info：
• 作为补充说明纳入审查备注，无需单独升级
• Reviewer 不得跳过脚本，也不得在未运行脚本的情况下声称 metadata 已通过

阶段一：全面审查

按 8 大维度逐一审查，记录发现的问题：

1. 结构完整性审查 2. 业务逻辑审查（PM 视角） 3. 需求清晰度审查（开发视角） 4. 可测试性审查（QA 视角） 5. 业务方视角审查 6. 内容边界审查 7. 证据可追溯性审查 8. 一致性审查 9. Traceability Metadata 审查

阶段二：问题汇总与分级

1. 将发现的问题按 P0/P1/P2 分级 2. 计算各维度评分（1-5 星） 3. 确定审查结论：

• 🔴 不通过：存在 P0 问题，或 P1 问题 ≥2 个
• 🟡 有条件通过：无 P0，P1 问题 0-1 个
• 🟢 通过：无 P0，P1 问题 0 个

阶段三：输出审查报告

按照审查报告模板输出结果（直接在对话中展示）。

阶段四：放行决策

• 不通过：要求用户修改 PRD，修改后可再次触发审查
• 有条件通过：列出需修改的 P1 问题，建议修改后再次审查
• 通过：输出「准出证书」，PRD 可进入 HLD 阶段

输出模板

• 审查报告模板：references/report-templates.md
• 英文审查报告模板：references/report-templates.en.md
• 审查不通过时，输出完整审查报告
• 审查通过时，输出准出证书；如仍有 P2，放入 遗留建议 / Residual Suggestions
• 模板语言必须遵循 ../../references/language-policy.md

交互规范

审查启动方式

用户提供 PRD 文件路径或直接粘贴 PRD 内容，触发审查流程。

迭代审查

• 用户修改 PRD 后，可再次调用 prd-reviewer 进行复审
• 复审时会记录"第 N 轮"，并在最终准出证书中展示审查历程

使用 AskUserQuestion 的场景

1. PRD 路径不明确时，询问确认 2. 需要验证业务现状描述但找不到相关文档时，询问用户 3. 发现严重问题但不确定是否为阻塞问题时，与用户确认

禁止行为

• 禁止放水：不能因为"差不多"就放行，必须严格执行标准
• 禁止越权：不修改 PRD，只提出问题和建议
• 禁止模糊反馈：问题描述必须具体，指出章节和内容，给出改进建议
• 禁止无依据质疑：挑问题需有理有据，不能主观臆断

触发词

以下输入应触发此技能：

• "审查 PRD"、"review PRD"
• "PRD 评审"、"需求评审"
• "检查 PRD 质量"
• "/prd-reviewer"

参考文档

• references/review-checklist.md
• references/report-templates.md
• references/report-templates.en.md

PRD Review Report and Approval Certificate Templates

Review Report Template

# PRD Review Report

## Basic Information
- **PRD Document**: [Path]
- **Review Time**: YYYY-MM-DD HH:MM
- **Review Round**: Round N
- **Review Decision**: 🔴 Fail / 🟡 Conditional Pass / 🟢 Pass

---

## Findings

### 🔴 Blocking Issues (P0) - Must Fix
| # | Issue | Section | Recommended Fix |
|---|-------|---------|-----------------|
| 1 | [Description] | [Section] | [Recommendation] |

### 🟡 Major Issues (P1) - Strongly Recommended to Fix
| # | Issue | Section | Recommended Fix |
|---|-------|---------|-----------------|
| 1 | [Description] | [Section] | [Recommendation] |

### 🔵 Improvement Suggestions (P2) - Optional
| # | Issue | Section | Recommended Fix |
|---|-------|---------|-----------------|
| 1 | [Description] | [Section] | [Recommendation] |

---

## Dimension Scores

| Review Dimension | Score | Notes |
|------------------|-------|-------|
| Structural Completeness | ⭐⭐⭐⭐⭐ | [Notes] |
| Business Logic (PM Perspective) | ⭐⭐⭐⭐☆ | [Notes] |
| Requirement Clarity (Engineering Perspective) | ⭐⭐⭐☆☆ | [Notes] |
| Testability (QA Perspective) | ⭐⭐⭐⭐☆ | [Notes] |
| Business Stakeholder Perspective | ⭐⭐⭐⭐⭐ | [Notes] |
| Scope Boundaries | ⭐⭐⭐⭐⭐ | [Notes] |
| Evidence Traceability | ⭐⭐⭐☆☆ | [Notes] |
| Consistency | ⭐⭐⭐⭐☆ | [Notes] |
| Traceability Metadata | ⭐⭐⭐⭐☆ | [Notes] |

---

## Next Actions

[Provide specific follow-up actions based on the review decision]

Approval Certificate Template

# ✅ PRD Approval Certificate

## Basic Information
- **PRD Document**: [Path]
- **Approval Time**: YYYY-MM-DD HH:MM
- **Review Round**: Total N rounds
- **Review Decision**: 🟢 Pass

---

## Review History
| Round | Date | Issue Counts | Decision |
|-------|------|--------------|----------|
| 1 | YYYY-MM-DD | P0: X, P1: Y, P2: Z | Fail |
| 2 | YYYY-MM-DD | P0: 0, P1: 0, P2: Z | Pass |

---

## Residual Suggestions (P2)
[List non-blocking issues that can be optimized later]

---

## Approval Confirmation

This PRD has passed the review and meets the release criteria. It may proceed to the HLD phase.

**Reviewer**: `prd-reviewer`

PRD 审查报告与准出证书模板

审查报告模板

# PRD 审查报告

## 基本信息
- **PRD 文档**：[路径]
- **审查时间**：YYYY-MM-DD HH:MM
- **审查轮次**：第 N 轮
- **审查结论**：🔴 不通过 / 🟡 有条件通过 / 🟢 通过

---

## 问题清单

### 🔴 阻塞问题（P0）- 必须修复
| # | 问题描述 | 所在章节 | 建议修改 |
|---|----------|----------|----------|
| 1 | [描述] | [章节] | [建议] |

### 🟡 严重问题（P1）- 强烈建议修复
| # | 问题描述 | 所在章节 | 建议修改 |
|---|----------|----------|----------|
| 1 | [描述] | [章节] | [建议] |

### 🔵 改进建议（P2）- 可选优化
| # | 问题描述 | 所在章节 | 建议修改 |
|---|----------|----------|----------|
| 1 | [描述] | [章节] | [建议] |

---

## 各维度评分

| 审查维度 | 评分 | 说明 |
|----------|------|------|
| 结构完整性 | ⭐⭐⭐⭐⭐ | [说明] |
| 业务逻辑（PM视角） | ⭐⭐⭐⭐☆ | [说明] |
| 需求清晰度（开发视角） | ⭐⭐⭐☆☆ | [说明] |
| 可测试性（QA视角） | ⭐⭐⭐⭐☆ | [说明] |
| 业务方视角 | ⭐⭐⭐⭐⭐ | [说明] |
| 内容边界 | ⭐⭐⭐⭐⭐ | [说明] |
| 证据可追溯性 | ⭐⭐⭐☆☆ | [说明] |
| 一致性 | ⭐⭐⭐⭐☆ | [说明] |
| Traceability Metadata | ⭐⭐⭐⭐☆ | [说明] |

---

## 下一步行动

[根据结论给出具体行动建议]

准出证书模板

# ✅ PRD 准出证书

## 基本信息
- **PRD 文档**：[路径]
- **准出时间**：YYYY-MM-DD HH:MM
- **审查轮次**：共 N 轮
- **审查结论**：🟢 通过

---

## 审查历程
| 轮次 | 日期 | 问题数 | 结论 |
|------|------|--------|------|
| 1 | YYYY-MM-DD | P0: X, P1: Y, P2: Z | 不通过 |
| 2 | YYYY-MM-DD | P0: 0, P1: 0, P2: Z | 通过 |

---

## 遗留建议（P2）
[列出未阻塞放行但建议后续优化的问题]

---

## 准出确认

本 PRD 已通过全面审查，符合准出标准，可以进入 HLD 阶段。

**审查者**：prd-reviewer

PRD 审查清单（详细版）

本文档提供 PRD 审查的完整检查清单，按 8 大维度组织。

---

1. 结构完整性

必填章节检查

格式检查

• [ ] 是否有未填写的占位符（如 [待补充]、TODO）？
• [ ] 表格格式是否正确？
• [ ] Mermaid 流程图是否可渲染？

Traceability Metadata（强制）

• [ ] 是否先执行了 python3 plugins/testany-eng/scripts/trace_lint.py --format json <PRD路径>？
• [ ] 是否读取并纳入了脚本返回的 error / warning / info？
• [ ] 是否存在 TRACEABILITY-METADATA:BEGIN/END 标记？
• [ ] 标记间是否只有一个 YAML fenced code block？
• [ ] schema.name 是否等于 testany-traceability？
• [ ] schema.profile 是否等于 prd-profile-v1？
• [ ] artifact.type 是否等于 PRD？
• [ ] 是否存在至少 1 条 entities.requirements[]？
• [ ] 每条 requirement 是否都有稳定 REQ-*？
• [ ] 每条 requirement 是否都有 class/title/statement/priority/status/scope/acceptance_criteria？
• [ ] artifact.source_documents 是否声明了本轮实际使用的 BRD / Journey 来源？
• [ ] relations[].type=derived_from 是否为关键 requirement 建立了来源追溯？

---

2. 业务逻辑（PM 视角）

背景与目标

• [ ] 能否清晰回答"为什么要做这个需求"？
• [ ] 业务目标是否明确、可衡量？
• [ ] 是否说明了不做会有什么后果？

用户故事

• [ ] 是否覆盖主要用户角色？
• [ ] 是否覆盖核心使用场景？
• [ ] 用户故事格式是否标准（As a... I want... So that...）？

业务规则

• [ ] 是否列出了所有关键业务规则？
• [ ] 业务规则之间是否有矛盾？
• [ ] 规则的边界条件是否清晰？

边界情况

• [ ] 是否考虑了异常流程？
• [ ] 是否考虑了极端情况（空数据、大数据量、并发）？
• [ ] 是否考虑了用户误操作场景？

成功指标

• [ ] 指标是否可量化（有具体数值）？
• [ ] 是否说明了数据来源/采集方式？
• [ ] 基线值和目标值是否明确？

---

3. 需求清晰度（开发视角）

功能描述

• [ ] 功能描述是否有歧义？
• [ ] 输入和输出是否明确？
• [ ] 是否能据此开始 HLD 设计？

功能边界

• [ ] 是否明确了"做什么"？
• [ ] 是否明确了"不做什么"（范围外）？
• [ ] 是否有待确认事项？

依赖与约束

• [ ] 是否列出了外部依赖？
• [ ] 是否说明了技术约束？
• [ ] 是否说明了时间约束？

---

4. 可测试性（QA 视角）

验收标准

• [ ] 每个功能是否有对应的验收标准？
• [ ] 验收标准是否可测试（可验证 Pass/Fail）？
• [ ] 验收标准是否具体（非模糊描述）？

测试场景覆盖

• [ ] 是否覆盖正常流程？
• [ ] 是否覆盖异常流程？
• [ ] 是否覆盖边界条件？

验收标准格式

• [ ] 是否使用 checkbox 格式？
• [ ] 描述是否清晰、无歧义？

---

5. 业务方视角

业务现状

• [ ] 现有流程描述是否准确？
• [ ] 是否有文档/数据支撑？
• [ ] 是否遗漏了重要的现有功能？

变更影响

• [ ] 是否评估了对现有用户的影响？
• [ ] 是否评估了对现有系统的影响？
• [ ] 是否评估了对现有数据的影响？

利益相关方

• [ ] 是否识别了所有利益相关方？
• [ ] 是否考虑了各方的需求和顾虑？

---

6. 内容边界

HLD 越界检查

• [ ] 是否包含具体的 API 路径设计？（不应该）
• [ ] 是否包含数据库表结构？（不应该）
• [ ] 是否包含技术架构图？（不应该）
• [ ] 是否包含具体的技术选型决定？（不应该）
• [ ] 是否包含代码实现细节？（不应该）
• [ ] 是否包含部署方案？（不应该）

方案边界

• [ ] 方案建议 vs 最终决定的边界是否清晰？
• [ ] 是否标注了"最终选型见 HLD"？

---

7. 证据可追溯性

相关能力识别

• [ ] 表格中每一行是否都有「来源」？
• [ ] 来源是否真实存在（可验证）？
• [ ] 是否存在无依据的猜测？

业务现状

• [ ] 现状描述是否有文档/代码依据？
• [ ] 依据是否标注了来源路径？

Traceability 引用

• [ ] source_refs 中引用的 artifact_id 是否真实存在或可在 artifact.source_documents 中找到？
• [ ] relations.from/to 是否都引用了已声明对象？
• [ ] 是否存在 requirement 仅在正文出现、但没有进入 metadata block？

项目约定

• [ ] 是否遵循项目现有的命名规范？
• [ ] 是否遵循项目现有的文档风格？

---

8. 一致性

术语一致性

• [ ] 同一概念是否使用相同术语？
• [ ] 是否有术语表？
• [ ] 术语定义是否清晰？

逻辑一致性

• [ ] 需求描述是否有内部矛盾？
• [ ] 前后章节是否一致？

优先级一致性

• [ ] 优先级标注是否合理？
• [ ] 高优先级功能是否有对应的验收标准？

---

审查结果汇总

审查结论

• [ ] 🔴 不通过（P0 > 0 或 P1 ≥ 3）
• [ ] 🟡 有条件通过（P0 = 0，P1 = 1-2）
• [ ] 🟢 通过（P0 = 0，P1 = 0）