Product Management
维护从需求收集到验收收口的单一产品事实链。产品文档说明为什么做、做什么和如何验收，不冒充技术实现或发布完成证据。
产品初始化模板由本 Skill 唯一持有：需要建立需求池、PRD、路线图或迭代计划时，使用 product-governance assets，不要在项目管理目录建立第二套产品模板。
写入项目产物前，先读项目入口并复用现有语义 owner。BuildOS 默认模板只用于新初始化实例；成熟项目须先映射并获授权，禁止创建默认目录或平行事实源。
工作方式
- 收集原始需求并保留来源、目标用户、问题、期望结果、类型和 owner。 对投入较大、证据薄弱、方向不确定或可能有现成替代的想法，先做按需机会评估：区分事实与假设，查支持和反对证据，比较不做、复用／购买和最小方案，再决定继续澄清、进入需求、暂缓或拒绝。低成本、可逆的小改动不强制走完整发现流程。
- 澄清范围、非目标、业务规则、约束、依赖、风险、成功指标和验收标准。
从自然语言需求开始时，在现有 REQ／PRD 和关联编号任务计划中完成需求加工、关键歧义澄清和按需价值切片，不建立平行
specs/目录或第二个当前需求指针。 - 区分需求生命周期、优先级、路线图阶段、迭代承诺和真实发布状态。
- 为进入决策和实现的需求建立稳定 ID，以及 PRD、Task、实现、测试、验收和发布证据关联。
- 临时插入、延期、拒绝、取消和范围变化必须更新对应产品事实及影响。
- 收口时分别核对实现证据、产品验收和发布事实，不把
implemented、accepted与released混为一谈。 - 普通需求一致性检查由本 Skill 自查需求、PRD、验收标准、迭代与 Task 是否一致；只有明确要求独立结论、存在跨域争议或进入 G3-G4 正式审查时才交给 Assurance。
读取 需求与产品迭代管理规范 处理需求池、路线图、迭代和交接。
协作与交接
- 需求可以进入实现时，向
senmu-build-engineering交接需求 ID、目标、范围／非目标、业务规则、约束、验收标准和未决问题；技术路线和实现由 Engineering 主责。 - 产品验收完成并需要形成版本或真实发布时，向
senmu-build-delivery交接需求／版本范围、验收状态和证据链接；版本、部署和生产事实由 Delivery 主责。 - 发现项目目录、权威入口或跨阶段状态存在冲突时，向
senmu-build-project交接冲突位置、受影响 owner 和期望治理结果；Project 不接管产品事实正文。 - 原始客户、用户和市场反馈仍由本 Skill 进入需求体系；只有已经验证且会改变后续执行方式的经验才交给
senmu-build-learning。 - 需要多个阶段或跨会话执行的产品工作使用项目声明的 Durable Task State Owner；采用 BuildOS 新项目默认实例时才写入
governance/tasks/TASK-<NNNN>-<slug>.md。需求池、PRD、路线图和迭代计划仍是产品事实 owner。 - 没有持续产品演进的脚本、一次性交付或 POC 不强制建立完整产品体系；仍需保留最小范围、验收或证据目标。