PRD for Agents — PRD for 代理s

用于Agent的PRD 产生符合行业标准、针对Agent优化的产品需求文档（PRD）。旨在将愿景或想法转化为AI Agent可以直接构建的规范 —— 结构化、完整、可执行，无需Agent询问澄清问题。

何时使用此技能 为任何项目或功能编写新的PRD 审查或升级现有的PRD以确保完整性 准备从架构师到开发Agent的交接文档 将PRD发布到GitHub用于社区或开源项目

输出结构 每个由此技能产生的PRD都遵循此确切的章节顺序。加载references/prd-sections.md以获取每个章节的详细指南。加载references/prd-examples.md以获取每个章节的注释示例。

• 标题块
• 问题陈述
• 目标用户和任务
• 用户故事
• 功能列表（MVP + Post-MVP）
• 接受标准
• 定量成功指标
• 数据模式/ API契约
• 文件和文件夹结构
• Agent构建顺序（序列化）
• 阶段映射（用于具有>5个功能的项目）
• 假设
• 未解问题
• 依赖
• 风险
• 范围外

快速参考：大多数PRD缺失的差距 这些八个章节存在于行业标准的PRD中，但缺失于大多数Agent生成的PRD中。始终包含所有八个。

• 用户故事格式：作为[用户类型]，我希望[操作]，这样[结果]。每个故事必须是独立可测试的。将每个功能（F1、F2...）与至少一个用户故事配对。请参阅references/prd-sections.md#user-stories。
• 定量成功指标

每个指标必须有一个数字、一个单位和一个日期。 ❌ “仪表板很快” ✅ “仪表板在10个项目的工作空间中加载时间< 2s，截止日期2026-06-01” 请参阅references/prd-sections.md#success-metrics。

• 依赖

列出此项目所需但不拥有的内容： 外部API或服务 其他必须先发布的项目或功能 基础设施（运行时、数据库、身份验证） 人员或审批 格式：| 依赖 | 类型 | 所有者 | 所需日期 | 延迟风险 |

• 未解问题

未解决的可能改变范围或设计的决策。每个问题需要： 问题本身 谁拥有答案 截止日期（或“开发人员开始之前”） 如果未解决的影响 格式：| # | 问题 | 所有者 | 截止日期 | 如果未解决的影响 | 路由规则：任何截止日期为“开发人员开始之前”的未解问题必须在此PRD获得批准之前由主要负责人解决。标记PRD提交#CLARIFY，如果存在此类未解问题。不要将其路由到开发人员，直到所有问题都得到解决。

• 风险

对交付、质量或采用构成威胁的因素。每个风险需要一个可能性、影响和缓解措施。 格式：| 风险 | 可能性 | 影响 | 缓解措施 |

• Agent构建顺序

开发Agent应执行的任务的编号序列。这是Agent交接中最关键的章节 —— 没有它，开发Agent将以错误的顺序拾取任务并创建集成故障。 格式：| 步骤 | 任务 | 功能 | 复杂度 | 依赖于 |

• 假设

架构师认为是正确的，但尚未被主要负责人明确确认的信念。不同于未解问题 —— 假设有一个可行的答案，但需要在下游工作之前确认。 格式：| # | 假设 | 自信度 | 确认与 | 如果错误的影响 | 路由规则：任何自信度<高或任何假设的“如果错误的影响”将改变架构或范围的假设必须在PRD批准之前由主要负责人确认。标记PRD提交#CLARIFY，如果存在此类假设。

• 阶段映射

对于具有>5个MVP功能的项目所需。将构建分解为阶段，以便开发Agent仅处理第1阶段，同时主要负责人可以在提交第1阶段架构之前验证整个序列是否有意义。 格式：| 阶段 | 范围摘要 | 依赖于 | 目标 | 状态 | 路由规则：主要负责人必须在开发Agent开始第1阶段之前验证阶段映射。主要负责人必须回答的关键问题： “第1阶段是否提供独立价值，第2阶段+的要求是否会改变第1阶段的架构？”如果是 —— 修订之前构建。

PRD完整性检查清单 在将PRD标记为准备好交付给开发Agent之前运行此检查清单。任何缺少✅项的PRD都应返回给架构师。 结构 标题块包括：项目、版本、状态、作者、批准者、日期 问题陈述有证据或数据支持，而不仅仅是断言 目标用户定义为具有任务的角色，而不仅仅是名称 每个MVP功能至少有一个用户故事 每个用户故事都有一个对应的接受标准 Post-MVP项目明确列出（而不仅仅是“未来工作”） 指标 每个成功指标都有一个数字目标 每个成功指标都有一个单位（秒、%、计数等） 每个成功指标都有一个目标日期或里程碑 北极星指标被识别（最重要的指标） 交接准备就绪（Agent特定） 数据模式或API契约被定义