用途：把无法在一个冲刺内完成的大型用户故事、史诗或功能，拆解为更小、可独立交付、可独立测试的故事，以降低风险、加快反馈并保持敏捷流动。输入提供过大的故事或史诗原文，并可补充其“过大”的原因（无法估算、无法在一个冲刺完成、无法独立发布）与团队规模上限；若调用时已附带文本或上下文，则视为已提供答案，不再重复询问，也可空手开始。
主要能力：基于 Richard Lawrence 与 Peter Green 的《Humanizing Work Guide to Splitting User Stories》，提供 8 种系统性拆分模式，依次尝试直到适用为止——工作流步骤、业务规则变体、数据变体、验收标准复杂度、主要工作量、外部依赖、DevOps 步骤，以及当上述均不适用时用小型探索实验（TADs）解开未知。拆分后按用户故事格式（含 As a / I want to / so that 与 Given/When/Then 验收标准）逐一写出，并通过五项校验：每块是否交付用户价值、能否独立开发、能否独立测试、是否足够小（约 1-5 天）、组合起来是否等于原始故事。
使用方式：先识别原始故事，再按 8 种模式顺序套用，使用模板填写结构，最后写出拆分故事并校验。典型示例：将“管理员可从 CSV、Excel 或 HR 系统批量导入用户并含字段映射与错误处理”按数据变体或外部依赖拆分。
适用场景：故事过大、验收标准含多个 When/Then、史诗需拆为可交付增量、团队对规模无法达成共识、故事捆绑多个角色或工作流。
限制与反模式：不做水平切片（如前端故事与后端故事分开）、不做任务分解（如建数据库、写 API）、不做无意义切分；故事已足够小、拆分会产生拖慢交付的依赖、或本身是技术任务时不应使用。常见陷阱包括水平切片、过度拆分、无意义拆分、制造硬依赖、忽略 so that。需注意每块应有独立的用户结果，而非仅拆动作。相关依赖文档包括 skills/user-story/SKILL.md、skills/epic-hypothesis/SKILL.md。其他具体收费、价格或平台信息暂未提供。