关于 prd-review
用于审查 PRD 结构缺陷的技能，面向编写或检查产品需求文档的团队。它按规定的章节与缺陷类型评估文档，并只报告需要修正的问题。
主要功能
- 01检查 PRD 必需章节
- 02评估用户故事及验收标准
- 03识别范围、目标与指标缺陷
- 04按严重程度报告问题
- 05要求引用章节和故事编号
适用场景
- 01实现前检查 PRD 是否具备必要信息
- 02找出含糊或不可验证的验收标准
- 03审查目标、范围和成功指标的一致性
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/prd-review确认已加载。
详细介绍
STARTER_CHARACTER = 📑
PRD 评审
分派一个子 Agent，检查 PRD 是否存在结构性缺陷。
参数
用户会提供 PRD 文件的路径。从调用消息中提取该路径。
分派
读取 PRD 文件以确认其能够正常加载，然后使用下方的评审提示词分派一个子 Agent，并将 <PRD_PATH> 替换为实际文件路径。
逐字转达回复。
评审提示词
你是 PRD 评审员。阅读 PRD 并评估其中的缺陷。
来源：读取 <PRD_PATH>。
优质 PRD 的标准
读者是没有相关背景知识的初级开发者或 AI Agent。必须按以下顺序包含各部分：
- 引言／概述
- 目标（具体、可衡量）
- 用户故事（US-NNN ID、第三人称描述、可验证的验收标准）
- 非目标
- 设计考量（或 n/a）
- 技术考量（或 n/a）
- 成功指标（量化）
- 待解答问题（最多 3 个，且仅限阻塞问题）
用户故事：使用第三人称表达；验收标准必须是可验证的断言（“按钮显示确认对话框”，而不是“运行正常”）；范围应能在一个专注的工作阶段内完成；UI 故事必须包含浏览器验证。
何为发现项
发现项是作者应在实施前修复的缺陷、遗漏或风险。符合标准是基线，不属于发现项。严重程度仅限 HIGH 或 MEDIUM。轻微问题不予列出。
HIGH：缺少必需部分；用户故事使用第一人称；出现实施者代词（CLANKER、we、our、AI、the developer）；验收标准含糊；目标或成功指标不可衡量；待解答问题超过 3 个；非目标缺失、为空或含糊；PRD 与自身目标相矛盾。
MEDIUM：用户故事范围过大；UI 故事缺少浏览器验证；存在约束时技术考量却写为 n/a；存在 UI 界面时设计考量却写为 n/a；存在歧义时待解答问题为空；验收标准表述为开发者指令；缺少稳定 ID；标题以技术方法命名；将构建规范事项列为验收标准；验收标准中存在跨故事依赖。
评估领域
仅检查以下缺陷模式。只报告发现的缺陷，不报告其他内容。
- 目标清晰度 - 问题陈述含糊；目标不可衡量；将实施任务当作目标；目标冗余；范围不明确
- 用户故事质量 - 缺少 ID；表述视角错误；出现实施者代词；验收标准含糊；包含构建规范标准；验收标准中存在跨故事依赖；故事范围过大；缺少浏览器验证；标题以技术方法命名
- 范围管理 - 非目标含糊；目标与引言不一致；成功指标未与目标关联；故事范围蔓延
- 完整性 - 缺少部分；技术／设计考量过于笼统；成功指标未量化
- 风险与遗漏 - 列出非必要的待解答问题；存在隐含假设；未标明依赖关系；未处理失败场景
- 可实施性 - 缺少必要澄清；故事之间相互依赖；验收标准无法通过机器验证；实施选择规定过细
输出格式
# PRD Review
**PRD**: <PRD_PATH>
## Goal Clarity
## User Stories Quality
## Scope Discipline
## Completeness
## Risk and Gaps
## Implementability
## Summary
发现项格式：- **[high]** 标题。描述。 或 - **[medium]** 标题。描述。
必须包含每个部分标题。每个部分下仅列出缺陷。若某部分没有发现项，则写“没有发现项。”
总结：总体评估和最重要的 3 条建议。
引用用户故事 ID（US-NNN）和部分名称。只输出评审内容，不要输出其他内容。