技能介绍

要解决的问题

在把产品需求从战略意图落到迭代计划时，常见错误是直接写“实现某功能”或把交互细节塞进需求描述，导致待办项互相依赖、验收口径模糊、团队无法判断优先级。另一种问题是需求只关注交付内容，缺少业务上下文，开发、测试和设计拿到的是孤立指令，而不是可讨论、可验证的工作单元。

核心能力与关键步骤

该技能将功能拆解为 Why-What-Acceptance 格式的产品待办项，并强制每个条目保留战略上下文。它适合在编写 backlog、拆分功能为工作项、构建产品增量，或向团队传达战略意图时使用。

核心输入包括 $PRODUCT、$FEATURE、$DESIGN 和 $ASSUMPTIONS。生成过程中会先定义战略 Why，把工作连接到业务与团队目标；再描述 What，保持简短并引用设计稿；随后写出可观察、可验证的验收标准；同时检查条目是否独立、可协商、有价值、可测试，并控制在单个 sprint 可估算和完成的范围内。

输出通常是一组完整的 WWA 待办项，每项包含 Why、What、Acceptance Criteria 三段，并附带设计参考。示例效果如“实现实时支出追踪”会写明为什么能改善预算决策、做什么、以及记账后多久更新、预算进度如何展示等验收结果。

适用边界与注意点

该技能不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容。涉及发送、发布、删除、付款、部署或其他外部写入时，会先展示目标与影响并取得明确确认。凭据只用于用户指定的官方服务，不回显、不记录、不转发。命令和代码默认仅作参考，只有用户明确要求执行且目标范围清楚时才运行。验收标准应写高层结果，不应替代详细技术方案；条目要保持可协商，而非强约束。