用途：在技术设计或实现之前，由产品角色主导定义产品“做什么”（What），标准化 PRD 的发现与起草流程，覆盖产品范围、用户成果、需求 ID 与验收标准。
主要能力： 发现阶段（迭代式）：请求关联的 BRD 目标与业务成功指标；进行差距分析，识别缺失信息（问题、画像/JTBD、用例、指标、平台、流程、约束、优先级、分析、上线、开放问题）；分批提出 3-5 个澄清问题，并提供 a/b/c 选项以降低摩擦，直至达到可执行状态。 起草阶段：确保 docs/prd/ 目录存在，读取 references/prd-template.md；沿用来源 docs/brd/brd-[slug].md 的同一 [slug] 以保持文件名级可追溯；将发现答案映射到模板，未知项标记为 TBD；分配稳定的 REQ-* 与 AC-* 编号并映射到 BRD 目标；用户故事需含具体画像、明确业务价值并通过 INVEST 自检；验收标准对易误解行为使用 Given/When/Then，覆盖正常、边缘与异常路径。
使用方式：输出写入 docs/prd/prd-[slug].md。设置实现门禁：每个切片须标明 REQ-、AC-、负责人、状态、优先级与验证通道后方可交付工程。输出结果报告包含 feature_status、需求追踪、已完成/缺失证据、待决策项与建议的下一工作流，并维护含分析、风险、上线、决策与变更日志的活文档。
适用场景：创建 PRD、梳理产品需求、定义产品范围与验收标准、需要需求可追溯性与交付就绪度评估时。
限制与反模式：不得猜测业务逻辑，需主动询问；避免模糊表述（如“快”应写为“加载 < 200ms”）；PRD 只写“做什么”，实现计划写“怎么做”；缺少验收标准、负责人或 RACI 时不得进入编码；离岸交付需明确 PM/BA/工程/QA 的 RACI 并指定验证负责人；禁止孤立需求，每条需求须有负责人、状态与关联目标；不得混同 BRD/SRS；不得使用泛化角色（如“用户”），应替换为具体角色或画像。资料未提供具体价格、收费与平台信息。