pm-prd-review

name	pm-prd-review
description	Use when: 需要评审 PRD/BRD/MRD 等需求文档的质量、检查完整性/清晰度/可行性/指标/风险/一致性、在开发前做文档把关 Do NOT use when: 文档尚未产出（应先 /pm-docs 生成）；仅需口头讨论无需书面评审
allowed-tools	["Read","Write","AskUserQuestion","Bash"]

Preamble (run first)

bash "$(dirname "${BASH_SOURCE[0]}")/../../check-update.sh" 2>/dev/null || true
# 创建方案设计目录
mkdir -p docs/02-方案设计

# 检查待评审文档
echo "📋 查找待评审文档..."
for f in "docs/02-方案设计/PRD产品需求文档.md" "docs/02-方案设计/BRD商业需求文档.md" "docs/02-方案设计/MRD市场需求文档.md" "docs/02-方案设计/PRD.md"; do
  if [ -f "$f" ]; then echo "✅ 找到: $f"; fi
done

---

前置门禁

本技能用于评审已有文档，必须先有可评审文件：

1. 检查 docs/02-方案设计/ 下是否存在 PRD/BRD/MRD（或用户提供的其他路径）。
2. 若存在 → 读取并进入评审流程。
3. 若不存在 → 停止，告知用户先执行 /pm-docs 生成文档，或提供文档路径/内容后再评审。

不得在门禁不满足时编造评审对象。

---

跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。

---

适用场景

• 用户说"评审 PRD""PRD 写得怎么样""帮我审一下需求文档""文档质量检查""BRD 复盘"
• 与 pm-docs 区分：pm-docs 是"写"，本技能是"审"——在开发/评审会前做质量把关。

---

执行流程

步骤 1: 确定评审范围与标准（主 agent - 用户交互）

使用 AskUserQuestion 询问：

🔍 评审设置

你要评审哪个文档 / 哪些维度？

A) 评审 PRD（默认全套维度） B) 评审 BRD C) 评审 MRD D) 自定义维度（仅完整性 / 仅可行性 / 仅风险 …）

评审严格度：

1. 快速体检（关键问题）
2. 深度评审（逐条清单，推荐用于评审会前）

记录到变量 REVIEW_DOC 与 REVIEW_MODE。

---

步骤 2: 读取待评审文档（主 agent）

使用 Read 工具读取 REVIEW_DOC。

若文档过大，提取关键章节（背景、目标、范围、功能需求、非功能需求、指标、风险、排期）进入评审上下文。

---

步骤 3: 逐项评审（主 agent）

按以下清单逐项核对，标注【通过 / 建议 / 严重】：

1. 完整性与背景

• 是否说明背景与要解决的问题
• 目标与成功标准是否明确
• 范围（in/out）是否清晰

2. 清晰度与一致性

• 功能需求是否可测试、无歧义
• 术语/口径是否全文一致
• 与 BRD/MRD/技术文档是否冲突

3. 可行性与资源

• 是否评估技术可行性
• 是否标注依赖与排期
• 是否识别关键资源缺口

4. 指标与验证

• 是否有可度量的验收标准
• 是否定义上线后验证方式（数据/埋点）

5. 风险与兜底

• 是否列出主要风险与应对
• 是否有降级/异常处理方案

6. 用户与体验

• 是否体现目标用户与核心场景
• 关键流程是否有交互/边界说明

---

步骤 4: 生成评审报告（主 agent）

使用 Write 工具生成 docs/02-方案设计/PRD评审报告.md：

# {文档类型} 评审报告

## 文档信息
- 被评审文档: {路径}
- 评审模式: {快速/深度}
- 评审日期: {当前时间}
- 生成工具: super-pm / pm-prd-review

---

## 一、总体结论
- 评审结果: 【可进入评审会 / 需修改后复审 / 重大缺陷】
- 严重问题数: {n} ｜ 建议数: {m}

## 二、问题清单
| 编号 | 维度 | 级别 | 问题描述 | 修改建议 |
|------|------|------|---------|---------|
| Q1 | 完整性 | 严重 | {问题} | {建议} |
| Q2 | 可行性 | 建议 | {问题} | {建议} |

## 三、亮点
- {文档做得好的地方}

## 四、修改优先级
- P0（必须改）: {列表}
- P1（建议改）: {列表}

## 五、下一步建议
1. /pm-docs - 按评审意见修订文档
2. /pm-tech - 确认技术可行性
3. /pm-data - 补数据指标体系

---

步骤 5: 推荐下一步（主 agent）

✅ 评审报告已生成：docs/02-方案设计/PRD评审报告.md

建议执行：

1. /pm-docs - 按评审意见修订
2. /pm-tech - 技术可行性确认
3. /pm-data - 补齐指标

---

输出质量对比

✅ Good 示例：

• 问题可定位：「Q3 验收标准缺失：登录成功率无基线值，无法判定是否达标」
• 有级别与建议：「级别：严重；建议：补充埋点与基线目标」
• 有总体结论：「需修改后复审」

❌ Bad 示例：

• 泛泛：「文档还可以，再完善下」
• 无定位、无级别
• 不区分严重/建议

---

常见误区 / Red Flags — STOP

误区	正确做法
凭感觉评审	严格按六维清单逐项核对
只说"不好"不给建议	每条问题必须附修改建议
不分严重级别	区分严重/建议，便于排期修改
评审后无结论	必须给出可进入评审会/需复审的结论

---

产出质量检查 / Verification Checklist

• 已读取待评审文档（前置门禁通过）
• 已按六维清单逐项评审
• 问题已分级（严重/建议）并附建议
• 已给出总体结论
• 输出文档已生成到 docs/02-方案设计/
• 已推荐 2-3 个后续 skill

⚠️ 任何一项未通过 → 补全后再标记完成。

---