PRD Quality Review: {prd_name}

PRD Quality Review: {prd_name}【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHODOverall verdict[2–3 sentences. What holds up, whats at risk. Earned by the dimension judgments below.]Decision-readiness: [strong | adequate | thin | broken][1–3 paragraphs of judgment with specific PRD locations.]Findings[critical|high|medium|low][Title] (§ location); [Note].Fix:[suggested fix].Substance over theater: [verdict]...(repeat for each dimension)Mechanical notes[Glossary drift, ID continuity, broken cross-refs, Assumptions Index roundtrip. Lighter weight; these matter for downstream but dont drive the overall verdict.]格式上有三个值得注意的设计 - 每个维度标题后直接跟判断档位four 档之一正文是 1–3 段带具体 PRD 位置的判断文字 - 每条 finding 采用 [严重度] 标题§ 位置; 说明。*Fix:* 建议修复 的固定句式方便下游按严重度聚合 - 尾部单独设 **Mechanical notes**机械性备注权重更轻——它们对下游流程重要但不主导PRD 好不好的总评。 ## 七个维度详解 ### 1. Decision-readiness决策就绪度 核心问题**决策者能否直接依据这份 PRD 行动** 权衡是否被诚实呈现还是被抹平成了四平八稳的中性表述反对者提出的异议会被承认还是被回避 Look for - 以决定口吻写出的决定而不是被埋在考虑事项considerations里 - 权衡必须写明放弃了什么而不只是选了什么 - Open Questions 必须是真的开放问题而不是下一句就自答的修辞性提问 - [NOTE FOR PM] 标注应出现在真正的张力点而不是安全的检查点。 Red flag一份 PRD 里每个选择都平衡了一切、每个 NFR 都重要、每个人群都重视该产品。 ### 2. Substance over theater实质优于表演 核心问题**内容是挣来的还是家具furniture** 原文给出四类典型剧场 - **Persona theater人设剧场**一个决策都驱动不了的人设超过四个人设人设存在的唯一作用是让 PRD 显得周全。 - **Innovation theater创新剧场**声称的新颖性其实并不新颖因为模板里有这一节就写了差异化而不是 Discovery 阶段真的发现了什么。 - **NFR theaterNFR 剧场**复制粘贴的样板句系统必须可扩展/安全/可靠没有产品特有的阈值。 - **Vision theater愿景剧场**一段可以原封不动搬进同品类任何 PRD 的 Vision。 原文要求读起来像家具的内容要全部标出**哪怕是很漂亮的家具**。 ### 3. Strategic coherence战略一致性 核心问题**PRD 有没有论点thesis** 各功能是服务于一条统一的主线还是某个人想要的功能列表 Look for - PRD 明确押注的论点问题框架、用户洞察、市场动作 - 功能优先级由论点推导而来而不是先做容易的 - Success Metrics 验证的是论点而不是只衡量活跃度的指标——论点关于参与质量指标却是 DAU/MAU这就是典型信号 - 存在 SM 时必须命名反指标counter-metrics - MVP scope 类型problem-solving / experience / platform / revenue自洽且范围逻辑与之匹配。 Red flag读起来像带章节标题的 backlog待办清单的 PRD。 ### 4. Done-ness clarity完成的定义清晰度 核心问题**工程师读完能否知道每个 FR 的完成长什么样** Look for - 每个 FR 至少有一个可测试的后果testable consequence可验证的条件、可度量的结果 - 系统优雅地处理 X合理的性能用户友好这类措辞出现一处就标记一处 - 验收标准可以隐含由 FR 的后果承载或显式PRD 确实需要一个 Acceptance 章节 - 非功能部分UX、性能、安全要有边界值bounds而不是形容词。 原文特别强调这是下游故事story生成最依赖的维度评审时应当不留情面Be unforgiving here。 ### 5. Scope honesty范围诚实度 核心问题**省略是被明确写出的还是让读者自行脑补** Look for - 在真正有用的地方有 Non-Goals 章节在省略可能被默默想当然的地方有 [NON-GOAL for MVP] 标注 - 对用户没有直接确认的推断打 [ASSUMPTION: …] 标签并在文末建索引 - [NOTE FOR PM] 标注出现在被推迟的决定和未解决的张力上 - 降范围de-scoping是坦率提出的而不是悄悄发生的。 另有一条量化视角**open-items 密度**——数一下 Open Questions [ASSUMPTION] [NOTE FOR PM] 的总量相对于风险等级来评估。低风险 PRD 数量偏高没问题但一份绿灯放行去开发的 PRD 上数量偏高就是阻塞项blocker。 ### 6. Downstream usability下游可用性 核心问题**如果这份 PRD 要喂给 UX、架构或故事创建流程那些工作流能否干净地从中抽取素材source-extract** Look for - Glossary 存在所有领域名词在 FR、UJ、SM 定义中拼写完全一致 - FR / UJ / SM 的 ID 连续、唯一交叉引用可解析 - 每个章节单独抽出都能自洽交叉引用走 Glossary 术语而不是见上文see above - 每个 UJ 都有具名主角named protagonist不允许漂浮的 UJ。 原文补充对独立 PRD没有下游流程这个维度权重更低评审时应明说。 ### 7. Shape fit形态匹配度 核心问题**PRD 是否被硬塞进了一个不匹配产品的形状** 原文给出六种形态对照 - 消费级产品 / 多利益相关方 B2B / 有实质 UX → 具名主角的 UJ 是承重结构load-bearing - 内部工具、单一操作者角色 → 能力规格capability spec形态更合适UJ 可能是冗余SM 可以是运营指标而非用户向指标 - 监管或合规更新 → 约束可追溯性不可妥协UJ 可能完全无关 - 业余 / 单人项目 → 严格度可以降档但实质性底线不变 - 棕地brownfield已有代码库→ 对既有代码的引用必须准确新增 UJ 与既有 UJ 必须区分 - 链条顶端chain-top即 PRD 会依次喂给 UX → 架构 → 故事→ 下游可用性权重更高独立 PRD 的可追溯性要求可以更轻。 评审要点既要点出**过度形式化**单操作工具却铺满 UJ也要点出**形式化不足**消费级产品却没有 UJ。 ## 机械性备注Mechanical notes 原文规定这些项作为尾部小节处理不作为主维度They matter for downstream but dont drive the verdict on whether the PRD is good. 共五类 - **Glossary drift**跨 PRD 的大小写、单复数、同义词漂移 - **ID continuity**ID 断号、重复、无法解析的交叉引用 - **Assumptions Index roundtrip**每个内联 [ASSUMPTION] 都在索引里索引里的条目也都真实出现在正文中双向核对 - **UJ protagonist naming**每个 UJ 都有具名主角且上下文内联携带 - **Required sections**按约定的风险等级和产品类型必备章节齐全。 这些检查项与被评审对象的结构规范一一对应。对照 [prd-template.md](https://link.gitcode.com/i/bc9ba28e6471cdbcf49ca049b5b078ff) 的 Essential Spine 可以看到UJ 全局编号 UJ-1…N、FR 全局编号 FR-1…N、SM-1…N 加反指标 SM-C1…N、术语一次定义且全文逐字复用、[ASSUMPTION] 内联加文末索引、[NON-GOAL for MVP] 与 [NOTE FOR PM] 标注——正是模板PRD Discipline部分定义的纪律而标尺的维度 6 与 Mechanical notes 就是对这些纪律的验收侧。 ## 标尺在 BMAD 工作流中的调用位置源码佐证 标尺文档本身只定义怎么评何时评、由谁评、结果去哪由两侧的运行协议定义。 ### IDE 侧bmad-prd 的 Reviewer Gate [skills/bmad-prd/SKILL.md](https://link.gitcode.com/i/cc5c09cf8d35b0291f24020062b6d60d) 中定义了 Reviewer Gate 机制它被 **Validate 意图**和 **Finalize 第 3 步**两处复用 Assemble the menu: rubric walker against {workflow.validation_checklist_template} (the PRD quality rubric) each entry in {workflow.finalize_reviewers} any ad-hoc reviewers the artifact warrants. Stakes-calibrated — hobby/solo may run quietly or skip; higher stakes get the explicit all/subset/skip menu. 即评审席由按标尺走查的 rubric walker 配置的额外评审者 临时评审者组成且按 stakes 校准——低 stakes 可以静默跑或跳过高 stakes 给出全量/子集/跳过的显式菜单。各评审者以并行子代理运行每个把完整评审写入 {doc_workspace}/review-{slug}.md只回传紧凑摘要结论、Top 2–5 findings、文件路径父代理不持有全文。 rubric walker 的具体子代理提示词在 [references/validate.md](https://link.gitcode.com/i/a2f6286e4c693ae729f26429359f92a0) 中给出与标尺文档的规则严格一致 You are validating a PRD against the quality rubric at {workflow.validation_checklist_template}. Read the full rubric first, then read prd.md (and addendum.md if present). Form a judgment per dimension — strong / adequate / thin / broken — and write findings only where they add information. Cite specific PRD locations and quote phrases. Severity ranks impact on the PRDs usefulness, not how easy the fix is. Write your review to {doc_workspace}/review-rubric.md in the format the rubric specifies. Return ONLY a compact summary (overall verdict, dimension verdicts, finding counts by severity, file path). Validate 意图还额外运行**综合流水线synthesis pipeline**父代理读取所有 review-*.md填充 HTML 骨架生成 validation-report.html并写出按严重度分组的 markdown 孪生文件 validation-report.md作为下游重读的规范形式最后用平台打开器macOS open、Linux xdg-open、Windows start打开 HTML。评级规则也在该文件中明确定义 | 评级 | 条件 | | --- | --- | | Excellent | 所有维度 strong/adequate且无 high/critical finding | | Good | ≤1 个 thin 维度且无 critical finding | | Fair | 多个 thin 维度或存在任一 high finding | | Poor | 存在任一 broken 维度或任一 critical finding | findings 的呈现方式同样有约定Surface findings tiered, never dumped——先给一句 gate 结论再走 critical highmedium/low 收进一条尾巴plus N more in {file}只有用户追问某条时才读完整文件。 ### Web 侧PRD Coach bundle 的 Validate 模式 [web-bundles/prd-coach/SKILL.md](https://link.gitcode.com/i/fbf917f0c59a9bd6be01f2774fb8b84a) 定义了三种意图模式Validate 模式对这份标尺的消费方式略有不同 - 先读完整 PRD 与 Addendum再走七个维度顺序与标尺一致Decision-readiness → Substance over theater → Strategic coherence → Done-ness clarity → Scope honesty → Downstream usability → Shape fit - **只批评、不改写**返回 findings 后不重写文档除非用户要求结束时询问是否把 findings 滚成一次 Update - 结果渲染到 Canvas 上的 Validation Report总体结论2–3 句、维度判定 HTML 表维度、判定、一行理由、按 Critical / High / Medium-Low 分层的 findings以及 Mechanical notesglossary drift、ID continuity、Assumptions Index roundtrip。 Web bundle 的安装方式见 [INSTRUCTIONS.md](https://link.gitcode.com/i/220cd90b44ed03b7b95a0dcbc9e744d6)SKILL.md、prd-template.md 与 prd-validation-checklist.md 三个文件都要作为知识文件上传Gemini Gem 或 ChatGPT Custom GPT本标尺是三者中与 Validate 模式直接绑定的那一个ChatGPT 侧还需开启 Web Browsing因为协议会在 Discovery 阶段联网核实时效性事实。 ## 可配置点如何替换成组织自有标尺 从 [customize.toml](https://link.gitcode.com/i/61143bcd99bd3fecfbc67ff55d1d77c6) 可以看到标尺路径是一个可覆盖的配置项 toml # PRD quality rubric used at the Validate intent and at Finalize step 3. # A subagent walks the rubric against prd.md and writes a substantive review # organized by quality dimensions (decision-readiness, substance, strategic # coherence, etc.). Override the path in team/user TOML to enforce an # org-specific rubric (regulated-industry compliance, investor-pitch standards, # etc.). validation_checklist_template assets/prd-validation-checklist.md【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考