| name | prd-review |
| description | PRD 评审 / 需求评审：当用户已有 PRD 初稿、handoff、需求文档或产品方案，需要从 PM、研发、测试视角找缺口、 冲突、不可实现点和不可测试点时使用。可用中文唤起：“帮我审 PRD”“从研发和测试视角挑问题” “这个需求文档能不能交付开发”“帮我给 PRD 出修改草案”“检查 PRD 图示是否缺失或不可编辑”。 不用于凭空生成 PRD 初稿、直接写代码，或对 PRD 背后的成熟方案做一问一答压力测试；方案压测用 grill-me。
|
PRD 评审（prd-review）
中文速查
- 中文名：PRD 评审 / 需求评审
- 英文稳定名：
prd-review
- 你可以这样叫我：
帮我审 PRD、从研发测试视角挑问题、这个需求文档能不能交付开发、帮我补一版修订草案、检查 PRD 图示是否可编辑
- 适合：已经有 PRD/handoff，需要发现阻断项、重要缺口、验收不可测、工程无法落地的地方
- 不适合：从零写 PRD，改用
prd-architect；PRD 背后的方案可行性压测改用 grill-me；只做语言润色时不需要触发
Overview
这个 Skill 评审的是 PRD / handoff artifact 是否能支撑交付。默认输出结构化 review report、按严重程度排序的 findings、可回填的 revision draft，以及 Implementation-Plan Readiness verdict。
它不是 PRD 生成器，也不是一问一答方案压力测试器：
- 没有 PRD 或只有模糊想法：转
prd-architect 或 ai-collaboration-calibration。
- 关心“这个方案本身会不会失败”：转
grill-me。
- 要把 ready PRD 拆 GitHub issues：转
prd-to-issues。
- 要文件级开发计划：转 Superpowers
writing-plans。
Loop Extension
当用户明确需要“多轮评审”“关闭阻断项”“继续上一轮 review”“判断是否能进 writing-plans”“跟踪修订状态”或“把 PRD 收敛到可交付开发计划”时，读取 references/prd-readiness-loop-contract.md。
不要因为用户只是要求一次普通 PRD review 就创建状态文件；只有需要多轮收敛、可恢复状态或 readiness tracking 时才启用 Loop contract。
Inputs
优先读取：
handoff 文档：功能背景、目标用户、范围、风险与已确认事实。PRD 初稿：当前结构、已写事实、隐含假设、缺口和冲突。
可选补充：
- 本轮关注视角或维度。
- 用户明确担心的问题。
- 相关 UI、架构图、历史评审意见。
docs/templates-local/ override；如存在，应按 local override 理解正文结构。
如果输入不完整：
- 明确哪些结论来自 handoff，哪些来自 PRD 当前写法，哪些是 review 推断。
- 无法下结论的地方输出待确认问题，不强行补脑。
- 输入还不足以 review 时，建议先回到
prd-architect。
Workflow
-
Establish scope
- 记录 PRD / handoff 来源、本轮 review 目标、事实与假设边界。
- 判断是否应转
prd-architect、grill-me、prd-to-issues 或 writing-plans。
-
Load review assets
- 默认读取
references/review-lenses.md 和 references/severity-rules.md。
- 当需要输出完整 report 或 revision draft 时读取
references/output-contract.md。
- 当用户问“能不能交付开发 / 能不能进 writing-plans”时读取
references/implementation-plan-readiness.md。
- 当 PRD 包含或应包含流程图、架构图、系统关系图、AI 协作链路图时读取
references/diagram-review.md。
- 当 PRD 看起来过重、过技术化或模板章节误激活时读取
references/prd-shape-gates.md。
-
Review the PRD
- 至少从 PM、研发、测试三个视角 review。
- 合并重复问题，不要按角色输出三份重复报告。
- findings 必须包含：严重程度、视角、位置、问题、影响、建议改法。
- 图示相关结论必须区分：文本要求缺失、文件实际校验失败、未能验证。
-
Run deterministic checks when possible
python3 scripts/check_prd_shape.py <prd.md> --type <lite|standard|ai-native>
- PRD 明确是开发 handoff 时加
--allow-handoff。
- 有
.drawio 源文件时运行：
python3 scripts/validate_drawio.py <path>
- 脚本 warning 是 review 证据，不自动等同于阻断；结合 PRD 阶段和用户目标判断。
- Produce repair-ready output
- Findings 按严重程度排序。
- 必须给 revision draft：最小可替换章节、段落、验收/边界/异常清单三者至少一种。
- 必须列 open questions。
- 必须给
Implementation-Plan Readiness verdict：Ready for writing-plans、Ready with assumptions 或 Not ready。
Writing Rules
- Findings 先于 summary。
- 同一个问题合并成一条，再标注受影响视角。
- 修订草案优先最小可替换块，不默认重写整篇。
- 不把缺失业务判断伪装成已确认需求。
- 不为了显得完整而强行添加与当前阶段无关的大段章节。
- 不声称图文件合格，除非已经运行相应验证或明确说明验证限制。
Resource Guide
references/review-lenses.md：PM / 研发 / 测试 / 可选角色视角。references/severity-rules.md：阻断、重要、优化的判定规则。references/output-contract.md：默认 review report 结构、revision draft 和 writing rules。references/implementation-plan-readiness.md：进入 writing-plans 前的 readiness verdict。references/diagram-review.md：Draw.io / SVG / PNG / Mermaid 图示评审。references/drawio-templates.md：需要判断图示布局、节点数、颜色或 XML 模板时读取。references/prd-shape-gates.md：阶段混淆、过早技术化、模板章节误激活。references/prd-readiness-loop-contract.md：多轮 review / revision / re-review 状态化合约。scripts/check_prd_shape.py：PRD 形状和过技术化 warning。scripts/validate_drawio.py：Draw.io XML 基础结构验证。
Definition of Done
- handoff 和 PRD 的边界已经分开。
- findings 有严重程度排序，且证据来源清楚。
- 修订草案可直接回填。
- 推断和事实没有混写。
- 图示和 PRD shape 的验证状态已说明。
- 已明确
Implementation-Plan Readiness。
Evaluation
Smoke prompts:
帮我审这份 PRD，从 PM、研发、测试视角找阻断项。这个需求文档能不能交付开发？给我 readiness verdict。帮我 review 这份 AI-native PRD，重点看人工确认和失败回退。检查这份 PRD 图示是否缺失或不可编辑。
Non-trigger prompts:
帮我写一个 PRD。拷问这个方案会不会失败。把这个 ready PRD 拆成 GitHub issues。只润色这段 PRD 文案。
Capability checks:
- 输出 findings、revision draft、open questions 和 readiness verdict。
- 结论区分 handoff facts、PRD text 和 reviewer inference。
- 图示检查区分正式
*.drawio.svg、src/*.drawio、普通 .svg、PNG 和 Mermaid。
- 过技术化产品稿会建议把 schema / metadata / adapter 移到开发 handoff 附录。
