用途
用户故事是从用户视角对功能的简洁描述，说明谁需要什么、需要什么以及为什么需要，而不规定如何构建。好的用户故事帮助团队将大型功能拆分为可估算、可交付的增量，同时保持对用户价值的关注。
该技能用于根据产品需求或功能描述生成标准格式的用户故事。
主要能力
- 从 PRD 或功能描述中理解功能上下文、目标用户和范围边界。
- 识别具体用户角色，而非泛化的“用户”。
- 按用户目标将功能拆解为独立、完整、有价值的能力。
- 按“作为[角色]，我希望[操作]，以便[收益]”格式编写故事陈述。
- 使用 Given/When/Then 格式定义具体、可测试的验收标准。
- 按 INVEST 原则验证每个故事：独立、可协商、有价值、可估算、小、可测试。
- 补充设计参考、技术考虑和依赖项等上下文。
使用方式
当被要求创建用户故事时，按以下步骤执行：
- 理解功能上下文：审阅 PRD 或功能描述，理解总体目标、目标用户和范围边界。用户故事应可追溯到已记录的需求。
- 识别用户角色：确定哪些用户与该功能交互。每个故事应针对特定角色编写。不同角色对同一功能可能需要不同的故事。
- 按用户目标拆解：将功能分解为不同的用户目标。每个故事应交付完整、有价值的能力。
- 编写故事陈述：使用“作为[角色]，我希望[操作]，以便[收益]”格式。收益部分至关重要，它解释为什么这很重要并帮助排定优先级。
- 定义验收标准：使用 Given/When/Then 格式编写具体、可测试的标准。验收标准定义“完成”——如果所有标准通过，故事即完成。
- 应用 INVEST 标准：验证每个故事是否符合独立、可协商、有价值、可估算、小、可测试。不符合的故事需修改。
- 添加上下文和备注：包含相关设计参考、技术考虑和依赖项。
输出格式
使用 references/TEMPLATE.md 中的模板组织输出。完整输出中每个故事包含：故事标题；用户故事陈述；背景与上下文；验收标准；设计说明；技术说明；依赖项；范围外内容；以及待解决问题（如有）。多故事文档按示例在每个故事下嵌套这些部分。
适用场景
- PRD 获批后，将功能拆解为可实现的增量。
- 冲刺规划期间创建可执行的工作项。
- 为工程团队编写工单。
- 以易于理解的方式向干系人传达需求。
- 基于用户价值对待办事项进行优先级排序。
限制
以下情况不适用：
- 需要针对单个故事或切片提供更深入、可供 QA 使用的 Given/When/Then 覆盖时，应使用 deliver-acceptance-criteria。
- 需要功能级的边界条件和失败场景目录时，应使用 deliver-edge-cases。
- 功能本身尚未定义时，应先使用 deliver-prd；用户故事应可追溯到已记录的需求。
- 需要细化会议成果（估算、范围决策、待解决问题）时，应使用 iterate-refinement-notes。
质量检查清单
定稿前验证：
- 每个故事遵循“作为……我希望……以便……”格式。
- 故事相互独立（可按任意顺序构建）。
- 验收标准使用 Given/When/Then 格式。
- 每条标准可测试（可验证通过/失败）。
- 故事足够小，可在一个冲刺内完成。
- 故事陈述中不包含实现细节。
- 收益部分解释为什么这对用户重要。
示例
参见 references/EXAMPLE.md 中的完整示例。