---
name: senmu-build-product
description: Govern product facts from intake through prioritization, iteration, acceptance, and closure. Use when the result is clarified scope, a requirement or backlog decision, PRD, roadmap, acceptance criteria, or correction of product drift; not for technical design, code review, or deployment.
---

# Product Management

维护从需求收集到验收收口的单一产品事实链。产品文档说明为什么做、做什么和如何验收，不冒充技术实现或发布完成证据。

产品初始化模板由本 Skill 唯一持有：需要建立需求池、PRD、路线图或迭代计划时，使用 [product-governance assets](assets/product-governance/)，不要在项目管理目录建立第二套产品模板。

写入项目产物前，先读项目入口并复用现有语义 owner。BuildOS 默认模板只用于新初始化实例；成熟项目须先映射并获授权，禁止创建默认目录或平行事实源。

## 工作方式

1. 收集原始需求并保留来源、目标用户、问题、期望结果、类型和 owner。
   对投入较大、证据薄弱、方向不确定或可能有现成替代的想法，先做按需机会评估：区分事实与假设，查支持和反对证据，比较不做、复用／购买和最小方案，再决定继续澄清、进入需求、暂缓或拒绝。低成本、可逆的小改动不强制走完整发现流程。
2. 澄清范围、非目标、业务规则、约束、依赖、风险、成功指标和验收标准。
   从自然语言需求开始时，在现有 REQ／PRD 和关联编号任务计划中完成需求加工、关键歧义澄清和按需价值切片，不建立平行 `specs/` 目录或第二个当前需求指针。
3. 区分需求生命周期、优先级、路线图阶段、迭代承诺和真实发布状态。
4. 为进入决策和实现的需求建立稳定 ID，以及 PRD、Task、实现、测试、验收和发布证据关联。
5. 临时插入、延期、拒绝、取消和范围变化必须更新对应产品事实及影响。
6. 收口时分别核对实现证据、产品验收和发布事实，不把 `implemented`、`accepted` 与 `released` 混为一谈。
7. 普通需求一致性检查由本 Skill 自查需求、PRD、验收标准、迭代与 Task 是否一致；只有明确要求独立结论、存在跨域争议或进入 G3-G4 正式审查时才交给 Assurance。

读取 [需求与产品迭代管理规范](references/需求与产品迭代管理规范.md) 处理需求池、路线图、迭代和交接。

## 协作与交接

- 需求可以进入实现时，向 `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 不强制建立完整产品体系；仍需保留最小范围、验收或证据目标。