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
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`：

```markdown
# {文档类型} 评审报告

## 文档信息
- 被评审文档: {路径}
- 评审模式: {快速/深度}
- 评审日期: {当前时间}
- 生成工具: 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

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

---