需求构建技能 (product-spec-builder)

Purpose

从用户文字中拆出真实目的、用户、场景、边界和成功条件，形成可验收的产品契约；不要把一句话包装成完整需求。

Trigger

• 0→1：产品目标、用户、核心场景或首版范围尚未形成。
• 产品变更：新增或改变外部行为，但变更目的、范围、兼容性或验收记录仍缺失/不充分。
• “Bug 修复”实际需要重新定义正确行为。

有效决定已确认目的、外部行为和验收标准时，单一小改直接进入 dev-builder，需要阶段计划才进入 dev-planner；仅恢复既定行为、内部重构、测试、CI 或文档时不触发。

Required context

• 用户原始想法、痛点或变更请求。
• 已有 Product Spec、仓库事实、接口和设计材料（如果存在）。
• 已确认约束、参考案例、截图、反例和不可接受结果。
• 当前已知事实、推断和未知项。

Workflow

1. 先判断 0→1、产品变更或维护执行，不按用户使用的“优化/修复”字眼机械分类。
2. 抽取已知目的、目标用户、核心场景、外部行为、范围和非目标。
3. 只追问必要且未决的体验边界：用户能力、交互/默认行为、兼容性、显著成本、隐私/知识作用范围或缺失授权。已有决定不重问；工程实现与可自行核查的事实直接处理，每轮最多 2 个问题。
4. 信息足够时停止追问，把未知项写成临时假设或明确阻塞。
5. 0→1 生成 Product Spec；产品变更原位修订条款，标明待实现和旧决定替代关系。历史明细按需移出当前正文，不只追加相反声明。
6. 明确且可复用的项目准则交给 project-knowledge 原位沉淀；一次性例外与助手推断不能自动变成长期用户偏好。未决问题只暂停其依赖部分。

Output

• 路线与依据。
• 已确认事实、临时假设和待确认问题。
• 编号需求 REQ-* 与可观察验收标准 AC-*。
• docs/Product-Spec.md 或项目约定文件；产品变更包含变更 ID、兼容性、迁移、回滚和非目标。

Stop or escalate

• 无法判断是恢复行为还是重新定义行为：最多追问 2 个关键问题。
• 目标用户、核心场景或成功条件缺失且会改变方案：停止等待确认。
• 依赖未确认的外部接口或业务规则：记录阻塞，不编造答案。
• 产品契约已充分且请求只是维护：转交 bug-fixer 或 dev-builder。

References

执行前读取 stage-contract.md。