需求整理为可验收任务

先把需求从“角色”拉回“情境”

需求评审里常见的问题是：$FEATURE 被写成角色权限或页面清单，$CONTEXT 被隐去，验收标准变成“页面可点击”。结果是开发按菜单实现，测试按感觉验收，用户真正想完成的事没有稳定锚点。这个技能把需求收敛为 When... I want... so I can... 的 job stories，并强制补出用户情境、动机和可观察结果。

技能如何工作

它接收 $PRODUCT、$FEATURE、$DESIGN、$CONTEXT，按以下步骤生成可验收任务：

1. 识别触发情境：写清用户在什么时刻产生需求，而不是先堆角色。
2. 定义动机：说明用户为什么想做这件事，避免只描述按钮。
3. 明确结果：把价值写成用户可感知的结果，如预算不超支、决策前看到进度。
4. 应用 JTBD 框架：关注“要完成的任务”，不把角色当目标。
5. 生成验收标准：通常输出 6～8 条，要求可观察、可度量。
6. 关联设计稿：$DESIGN 只作为视觉和交互参考，链接到 Figma、Miro 等页面。

每条 story 的模板包含 Title、Description、Design 和 Acceptance Criteria。示例效果类似：当用户准备每周零食预算时，想快速查看已花金额，以便保证周末前不超支；验收标准会包括消费摘要、实时更新、进度条、剩余预算高亮、分类明细和阈值通知。

适用边界与注意点

适合用于需求澄清、JTBD backlog、验收标准编写，或需要从用户情境推导功能的场景。不要把它当作测试用例生成器、接口契约或完整技术方案；涉及发送、发布、删除、付款、部署等外部写入时，仍需先确认目标和影响。凭据只应用于指定官方服务，不回显、不记录、不转发；命令和代码默认只作参考，明确要求且范围清楚时才运行。