需要给工程交付功能/史诗/产品计划写规格说明时，用 PRD…

在问题与方案已对齐、工程开工之前，产出可交付、可测试、范围清晰的产品需求文档（PRD）。

适用场景

解决思路

1. 先复述问题：简要重述要解决的问题，若已有问题陈述则链接过去，确保读者在进入「做什么」之前先理解「为什么做这件事」。
2. 定义目标与成功指标：说明成功长什么样，给出具体、可衡量的指标并附基线与目标值，这些指标要直接对应所解决的问题。
3. 概述解决方案：高层描述拟采用的方案，聚焦面向用户的功能与关键能力；细节要足够让干系人评估方案，但不要过度指定实现。
4. 细化功能需求：拆解系统必须做什么，使用用户故事或需求陈述；每条需求都要可测试——有人能验证它是否被满足。
5. 仅当功能输出由模型产生时，把 AI 行为关联到证据：为本次发布要求的行为逐条列出如何证明其成立以及阈值；拒绝（refusal）与弃答（abstention）单独成行，因为模型对二者没有可靠默认，功能在不该回答时的表现是需求而不是实现细节；多步功能按组件分别打分，因为端到端通过率会掩盖是哪一步失败；评测集规模要说明其确定方法，绝不直接借用别人的数字。确定性功能完全跳过此步。
6. 明确范围边界：显式写清 in scope、out of scope、以及推迟到后续迭代的内容，防止范围蔓延并设定合理预期。
7. 处理技术考量：记录技术约束、架构决策与集成需求；不要做系统设计，但要把工程需要知道的考量暴露出来。
8. 仅当执行者将在没有写作上下文的情况下实现时，编写 Agent Execution Contract（实现者当时在场则完全跳过）：声明哪些来源是权威的、两者冲突时以谁为准；什么绝不能改动以及原因；每条 FR-n 如何验证、由谁验证；以及执行者必须停下来升级而不是自行决策的条件；每个升级条件都要指定负责人，没有收件人的升级最终会变成猜测。没有验证方式的需求不满足交付条件，因为无法区分「完成」和「执行者自认为完成」。
9. 识别依赖与风险：列出外部依赖、假设以及可能影响交付的风险，尽可能附上缓解策略与负责人。
10. 提出时间线与里程碑：列出关键阶段与检查点，让干系人理解交付计划，同时避免过早承诺具体日期。
11. 项目记忆契约（仅当 .claude/pm-skills.local.md 存在时启用，没有该文件则完全忽略本节、按上述流程正常执行）：读取 active_initiative 以及记录 personas 或研究发现的所有 interpretation 工件，已有内容直接使用，不要再向用户索要；若确实没有，正常询问，绝不凭空编造 persona 填补空缺。写入时把 PRD 写成 decision 工件，并把其确定的范围边界与成功指标写入 ## Decisions 章节。姿态上先提出条目并等待确认后再写入，除非 memory_auto_append: true，此时直接追加并回显写入内容。
12. 写入纪律：写之前立即重新读取该文件，不要用生成提案时的那份副本；若文件在此期间已变化，把自己的条目合并进当前状态并重新提案，而不是覆盖；只添加自己的条目，其他字段与章节保持逐字节不变。该文件被 gitignore，运行时没有任何保护，一次粗心的整文件写入会不可恢复地丢失另一个会话的工作。
13. 按 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。后三个章节按条件存在：省略功能不需要的章节才算完整，留一个空章节则不算完整。
14. 定稿前用质量清单逐项自查：问题与「为什么是现在」表述清楚；成功指标具体可衡量；范围边界显式（in/out/future）；需求可测试且无歧义；技术考量已暴露而未过度指定；依赖与风险已记录且有负责人；文档能在 15 分钟内读完；若输出来自模型，每条行为需求都有评测与阈值且其中包含拒绝与弃答；若为评测集定了规模，每个切片的 floor 要说明它承诺的覆盖范围及该切片凭什么是这个值，且任何切片结果都不得报告为失败率或失败率的界；若由执行者实现，每条 FR-n 都有验证方式与验证人，每个升级条件都有负责人。
15. 完成的示例见 references/EXAMPLE.md。

适用边界 · 注意事项

• 问题尚未界定或仍有争议时——PRD 假设问题已达成一致，应先用 define-problem-statement。
• 只需要一页纸的方案简报来对齐干系人时，应先用 develop-solution-brief，PRD 在那之后；只需要把工作拆成冲刺 ticket 时用 deliver-user-stories。
• 用于记录技术或架构决策时——改用 develop-adr。