用途
Product Requirements Document（PRD，产品需求文档）是传达「要构建什么以及为什么」的主要规格交付物。它在问题理解与工程实现之间架起桥梁，提供清晰的需求、成功标准和范围边界。好的 PRD 能让工程团队构建正确的东西，同时在实现细节上保留灵活性。
deliver-prd 是一个用于创建 PRD 的技能，用于在利益相关方之间对齐要构建的内容、原因以及如何衡量成功。
何时使用
- 问题与方案对齐之后、工程工作开始之前
- 为功能、史诗（epic）或产品计划做交接规格说明时
- 多个团队需要就共同交付物协调时
- 利益相关方需要在投入前批准范围时
- 作为开发与 QA 期间的参考文档时
何时不使用
- 问题尚未框定或仍有争议 → 先用 define-problem-statement；PRD 假定问题已达成共识
- 需要一页纸的方案推介来对齐利益相关方 → 用 develop-solution-brief；PRD 在该对齐之后
- 只需把工作拆分为冲刺（sprint）工单 → 用 deliver-user-stories
- 正在记录技术或架构决策 → 用 develop-adr
使用方式（撰写步骤）
- 总结问题：简要回顾要解决的问题，如有可能链接到问题陈述，让读者在进入「构建什么」前理解这项工作为何重要。
- 定义目标与成功指标：说明成功的样子，包含具体可衡量的指标及其基线与目标，指标应直接关联所解决的问题。
- 概述方案：高层次描述提议的方案，聚焦面向用户的功能与关键能力，为利益相关方提供足够细节以评估方案，但不过度规定实现。
- 详述功能需求：拆解系统必须做什么，可使用用户故事或需求陈述；每条需求应可测试，即有人能验证是否满足。
- 将 AI 行为链接到证据（仅当功能输出来自模型时）：确定性功能可跳过此步。当模型产生输出时，行为会因每次运行而异，「它能工作」这一说法需要附上证据。需指出本版本作为需求的行为，以及每项行为将如何被证明成立及在什么阈值下成立。拒绝与弃权（refusal 与 abstention）应单独成行——模型对这两者没有可靠默认值，因此功能在不应回答时如何表现是一项需求，而非实现细节。多步功能的每个组成部分应单独评分，因为端到端通过率会掩盖是哪一步失败。说明用例集是如何按方法确定规模的，而不是借用某个数字。
- 定义范围边界：明确说明范围内、范围外以及推迟到未来迭代的内容。清晰的范围可防止范围蔓延并设定现实预期。
- 处理技术考量：记录任何技术约束、架构决策或集成需求，不是设计系统，而是提出工程需要知道的考量。
- 撰写代理执行契约（仅当执行者在没有撰写上下文的情况下实现时）：如果实现者当时在场，可完全跳过此步。编码代理、外部承包商或冷启动接手此工作的团队无法推断你已知的内容，因此需要声明：哪些来源是权威的、两者冲突时以谁为准、什么不能改动及原因、每条 FR-n 如何被验证及由谁验证、以及在什么条件下执行者必须停止并升级而非自行决定。每个升级条件都要指定负责人；没有收件人的升级会变成猜测。没有验证的需求不具备交接条件，因为无法区分「已完成」与「执行者认为已完成」。
- 识别依赖与风险：列出可能影响交付的外部依赖、假设与风险，并在适用时包含缓解策略。
- 提出时间线与里程碑：概述关键阶段与检查点，帮助利益相关方理解交付计划，而不必过早承诺具体日期。
项目记忆契约
仅在 .claude/pm-skills.local.md 存在时生效。没有该文件时忽略此部分，完全按上述行为执行。
- 读取：active_initiative，以及任何记录人物画像（personas）或研究发现的解释性产物。使用它们，而不是询问已经产出的上下文。若不存在，按正常方式询问，且绝不凭空捏造人物画像来填补空白。
- 写入：将 PRD 作为决策产物写入，并将其承诺的范围边界与成功指标写入 ## Decisions 部分。
- 姿态：提出条目并等待确认后再写入，除非设置了 memory_auto_append: true，此时追加并回显所写内容。
- 写入纪律：写入前立即重新读取文件，绝不使用产生提案的那份副本。若其间文件已变化，将你的条目合并到当前状态并重新提案，而不是覆盖；只添加你自己的条目，其他所有字段与部分保持逐字节一致。运行时没有任何机制强制这一点，且该文件被 gitignore，因此一次粗心的整文件写入会丢失另一个会话的工作且无法恢复。
这是演示循环的读取端：当 discover-interview-synthesis 已记录人物画像时，不要再要求用户提供。
输出格式
使用 references/TEMPLATE.md 中的模板来组织结构。完整的 PRD 应填满模板的每个部分：Overview；Goals & Success Metrics；User Stories；Scope；Solution Design；Technical Considerations；Dependencies & Risks；Timeline & Milestones；Open Questions；当存在支持材料时填 Appendix；当功能输出来自模型时填 AI Behavior and Evaluation；当执行者将在没有撰写上下文的情况下实现时填 Agent Execution Contract。
最后三个部分是按需设计的：省略功能不需要的部分的 PRD 是完整的；包含空部分的 PRD 则不完整。
质量检查清单
定稿前验证：
- 问题与「为何是现在」表述清晰
- 成功指标具体且可衡量
- 范围边界明确（范围内/外/未来）
- 需求可测试且无歧义
- 技术考量被提出但不过度规定
- 依赖与风险已记录并指定负责人
- 文档可在 15 分钟内读完
- 若输出来自模型：每个行为需求都有评估与阈值，且拒绝与弃权也在其中
- 若评估集是确定规模的：每个切片的底线说明它承诺的覆盖范围及该切片为何值得，且没有任何切片结果被报告为失败率或其边界
- 若执行者将在没有撰写上下文的情况下实现：每条 FR-n 都有验证与验证者，每个升级条件都指定负责人
适用场景
- 产品经理或产品负责人撰写功能、史诗或产品计划的规格说明
- 需要为跨团队协作准备共享交付物的团队
- 需要在投入前批准范围的利益相关方评审
- 开发与 QA 阶段需要参考的规格文档
- 与编码代理、外部承包商或冷启动团队协作时的交接规格
限制
- PRD 假定问题已达成共识，不适用于问题尚未框定的场景
- 不用于记录技术或架构决策（应使用 develop-adr）
- 不用于拆分冲刺工单（应使用 deliver-user-stories）
- 不用于替代一页纸的方案推介（应使用 develop-solution-brief）
- 项目记忆契约仅在 .claude/pm-skills.local.md 存在时生效
- 资料未提供具体价格、收费模式、平台支持范围或效果数据
示例
参见 references/EXAMPLE.md 中的完整示例。