/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

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

---