pm-prd-review

Preamble (run first)

# 检查待评审文档
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

---

Boundaries when writing

When only discussing, do not write files; startup checks do not create directories. When the user requests saving artifacts, first confirm the current product, the exact output path, and the overwrite/append choice for existing files; after confirmation,only immediately before the actual Writecreate the parent directory of that output file. For complete installation, see skills/_shared/artifact-policy.md, installing this skill alone also follows this paragraph.

---

Prerequisite gate

This skill is used forreviewing existing documents, and there must first be a reviewable file:

1. Check docs/02-方案设计/ whether PRD/BRD/MRD exists under it (or another path provided by the user).
2. If it exists → read it and enter the review process.
3. If it does not exist → stop and tell the user to first execute /pm-docs to generate the document, or provide the document path/content before reviewing.

Do not fabricate a review target when the gate is not satisfied.

---

Cross-Agent interaction rules

When the process requires interaction with the user:

1. If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
2. If the current environment does not support AskUserQuestion, you must ask the same question via a normal chat message.
3. Ask only one question at a time.
4. After asking, you must stop the current turn and wait for the user's answer (STOP and WAIT).
5. Do not generate documents or write docs before the user answers.
6. An existing docs file cannot replace this round of user answers.

---

Applicable scenarios

• The user says "review the PRD", "how well is the PRD written", "help me review the requirements document", "document quality check", "BRD retrospective"
• Distinguish from pm-docs : pm-docs is "writing", this skill is "reviewing" — doing quality gatekeeping before development/review meetings.

---

Execution process

Step 1: Determine the review scope and standards (main agent - user interaction)

Use AskUserQuestion to ask:

🔍 Review settings

Which document / which dimensions do you want to review?

A) Review PRD (default full set of dimensions) B) Review BRD C) Review MRD D) Custom dimensions (completeness only / feasibility only / risks only …)

Review strictness:

1. Quick health check (key issues)
2. In-depth review (item-by-item checklist, recommended before review meetings)

Record to variable REVIEW_DOC and REVIEW_MODE。

---

Step 2: Read the document to be reviewed (main agent)

Use the Read tool to read REVIEW_DOC。

If the document is too large, extract key sections (background, goals, scope, functional requirements, non-functional requirements, metrics, risks, schedule) into the review context.

---

Step 3: Review item by item (main agent)

Check each item against the following checklist and mark it as [Pass / Suggestion / Critical]:

1. Completeness and background

• Whether the background and the problem to be solved are explained
• Whether the goals and success criteria are clear
• Whether the scope (in/out) is clear

2. Clarity and consistency

• Whether the functional requirements are testable and unambiguous
• Are terms/definitions consistent throughout the document
• Does it conflict with the BRD/MRD/technical documentation

3. Feasibility and Resources

• Is technical feasibility assessed
• Are dependencies and scheduling noted
• Are key resource gaps identified

4. Metrics and Validation

• Are there measurable acceptance criteria
• Is the post-launch validation method defined (data/tracking)

5. Risks and Fallbacks

• Are the main risks and responses listed
• Is there a degradation/exception handling plan

6. Users and Experience

• Are the target users and core scenarios reflected
• Do the key flows have interaction/boundary descriptions

---

Step 4: Generate the review report (main agent)

Use the Write tool to generate docs/02-方案设计/PRD评审报告.md：

# {文档类型} 评审报告

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

---

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

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

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

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

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

---

Step 5: Recommend next steps (main agent)

✅ Review report generated:docs/02-方案设计/PRD评审报告.md

Recommended actions:

1. /pm-docs - Revise according to review comments
2. /pm-tech - Technical feasibility confirmation
3. /pm-data - Fill in metrics

---

Output Quality Comparison

✅ Good example：

• The issue is locatable: "Q3 acceptance criteria missing: no baseline value for login success rate, cannot determine whether the target is met"
• Has severity and recommendation: "Severity: Critical; Recommendation: Add tracking and baseline targets"
• Has an overall conclusion: "Requires revision before re-review"

❌ Bad example：

• Vague: "The document is okay, just polish it a bit more"
• No location, no severity
• Does not distinguish critical/recommendation

---

Common Pitfalls / Red Flags — STOP

Pitfall	Correct approach
Reviewing by gut feeling	Strictly check item by item against the six-dimension checklist
Only saying "not good" without giving recommendations	Every issue must be accompanied by a revision recommendation
Not distinguishing severity levels	Distinguish critical/recommendation to facilitate scheduling revisions
No conclusion after review	Must give a conclusion on whether it can proceed to the review meeting/requires re-review

---

Output Quality Check / Verification Checklist

• The document to be reviewed has been read (pre-gate passed)
• Reviewed item by item against the six-dimension checklist
• Issues have been graded (critical/recommendation) and accompanied by recommendations
• An overall conclusion has been given
• The output document has been generated to docs/02-方案设计/
• 2-3 follow-up skills have been recommended

⚠️ If any item fails → complete it before marking as done.

---