用途：创建或完善 PRODUCT.md 产品契约，在用户授权下区分证据与愿景。核心要求是每条论断都必须要么有可解析引用（README、release、测试或证据来源），要么明确标注为未证实的假设；读者无法分辨真伪即视为文档失败。
主要能力：检查现有产品资料、README、目标、发布与证据来源；只就无法安全推断的事项询问用户决策；陈述使命、用户、痛点、价值、差异化与非目标。文档须分两个标题：## Proven 放有引用依据的论断；## Assumptions 放未证实的愿望、证据缺口和尚未衡量的成功信号。无法引用来源的论断只能归入 Assumptions。
使用方式：触发词包括“product”“create PRODUCT.md”“product boundary”。对仓库自身产品面，须从 docs/contracts/ubiquitous-language.md 中的规范类别出发（AgentOps 是 agentic engineering 的操作层），并保留很小的所有权边界，不得把 AgentOps 重新表述为执行编排器、工厂或循环。除非用户授权替换，否则保留现有 PRODUCT.md。文档返回给调用方，Plan 可将其作为意图上下文。
限制与失败模式：命名失败模式为“aspiration laundering”，即把未证实的愿望写进 ## Proven，导致下游计划继承错误前提；检测器为 ## Proven 中任何无可解析引用的论断都应移至 ## Assumptions 或补上引用。反模式是仅因会话有了新看法就整体重写健康的 PRODUCT.md，纠正做法是只改用户要求修改的章节，其余逐字节保留。Product 不选择工作、不调用循环、不自修复、不自验证、不决定交付。