用途
story-splitting 用于把一个过于宽泛或带有解决方案色彩的需求，拆分成若干个独立有价值的小故事（子故事）。它的定位是产品拆分，而非产出实施任务。它应在 planning 之前使用：当输入是一个大故事、史诗、功能想法、路线图项或待办项时，用它来发现小的、有价值的子故事；随后再由 planning 技能把选定的子故事排成实施切片。
该技能明确区分了不同不确定性的处理顺序：决策分支不确定时用 grill-me（如已安装）或 specification；需求过宽或带解决方案色彩时用 story-splitting；故事/规格/计划/原型有漏洞时用 find-gaps；已选定子故事需要构建时用 planning。story-splitting 不用于从头盘问每个产品决策，也不用于产出实施任务。
主要能力
核心原则
- 故事是对话，不是需求：故事是问题方与解决方协作的占位符，不要为完美的书面需求或从产品到工程的交接而优化。拆分时应引入产品、工程、设计、QA、运维视角。
- 切能力，不切组件：每个子故事都应描述从真实用户或外部系统视角看的行为变化。如果故事中的“用户”是内部组件、层、队列、数据库、API 或服务，那很可能是任务，不是故事。例如应写“买家可以用卡支付一张发票并收到确认”，避免“后端暴露支付端点 / 前端调用支付端点 / 数据库存储支付记录”。
- 先停留在问题空间：先问“尽快为客户交付价值的最简单选项是什么”，而不是“构建这个已想象好的解决方案的最简单方式是什么”。
- 从原始整体开始：优先一个微小的端到端整体，而非打磨过的部分。第一版可以是功能不足的垂直切片、结构未组合的路径、仅内部可用的能力，或明确标记为一次性的 tracer。
- 寻找便宜买卖（bargain）：寻找四分之一的想象功能就能带来大部分价值或学习的切片；把父故事当作草稿想法，愿意通过对话发现更便宜或更好的版本。
子故事质量标准
用 INVEST 作为质量检查（而非模板）：足够独立（I）、可协商（N）、有价值（V）、可估算（E）、足够小（S）、可测试（T）。同时应用反馈三重奏：好的切片应能工作、交付价值、能产生用户反馈。只带来内部进展的，多半是任务；能工作但不产生可能反馈或学习的，应追问更薄或不同的切片是否更有用。
使用方式
工作流程包含六步：
- 重构父项：用平实语言写出 actor（谁获得价值）、need/capability（他们能做什么或学到什么）、outcome（为何重要）、current constraint（为何过大、有风险、模糊或不确定）。如果是“构建网上银行门户”这类解决方案短语，重构成“客户可以支付账单/转账/查看余额”等能力；如果是“添加支付数据库”这类技术任务，找出它服务的用户行为，若无行为则保留为任务并挂到第一个证明它重要的故事上。
- 列出示例与变体：先列具体示例再想工单，包括 happy path、备选路径与错误路径、用户角色或客户细分、数据形态/规模/边界情况、业务规则与策略变体、接口/渠道/设备/集成，以及性能、规模、可靠性、安全、可访问性、可审计性等质量属性，还有可能推翻计划的未知或假设。
- 寻找拆分维度：可用维度包括能力（capability）、路径（path）、接口（interface）、数据（data）、规则（rules）、质量（quality）、风险（risk）。需要更多提示或应用 SPIDR、Hamburger、Humanizing Work 模式、Bill Wake 二十法时，加载 resources/pattern-catalog.md。
- 团队卡住时用 Hamburger 方法：列出技术层，列出每层从简单到丰富的选项，然后在每一层各取“第一口”，使结果仍是端到端，避免只吃一层。
- 选择第一个切片：优先能让团队至少降低一个后续故事优先级或删掉一个后续故事的拆分；在价值相当的情况下优先产生更多大小相近子项的拆分；优先价值成本比最高的切片；优先能尽早烧掉集成或架构风险的端到端切片；在复杂域中选一两个有用的学习切片，而不是假装一开始就枚举整个待办；如果第一个切片对任何人都没用，就让它对学习、运维、支持或验证有用，并明确说明。
- 编写子故事：每个子故事记录标题（actor + action + 窄范围）、价值、范围、有意推迟项、验收示例（前置条件 → 触发 → 可观察结果）、发布约束（可发布、仅内部、仅演示、一次性等，依项目策略）和后续项。使用用户的领域词汇（用户说“buyer”就写“buyer”，不写“user”）。
适用场景
- 梳理待办列表、分解史诗（epic）
- 规划 MVP 或行走骨架（walking skeleton）
- 寻找垂直切片、缩小故事规模
- 应用 SPIDR、Hamburger、能力切片等方法
- 避免 scatter-gather 或组件式故事
- 在实施规划前决定第一个有价值的故事
- 当工作跨越多个 UX 界面或原型状态时，可配合 storyboard 发现缺失界面与流程缺口，后者可成为子故事；设计类技能（shape、critique、polish）用于改进原型本身，而非替代产品切片
限制
- 该技能止于产品拆分。实施工作流、TDD、变异测试时机、特性开关策略、PR 前门禁、分支拓扑和交付机制，应交给项目说明和相关已安装技能处理。
- 故事拆分既不要求也不禁止本地变异运行或特性开关。
- 不要在选定故事到达实现之前使用领域与架构技能；不要按这些技术层拆分故事。
- 不用 story-splitting 产出实施任务；不用它从头拷问每个产品决策；不在没有可检查制品前使用 find-gaps。
- 若 find-gaps 发现计划仍是水平的或过大，应回到本技能再次拆分。
验证清单
返回拆分前，逐个检查每个子故事：是否命名了真实 actor 或外部系统？是否有触发条件和可观察结果？是否走该行为所需的真实生产路径？是否可在不等待所有兄弟故事的情况下测试？若发布、演示或演练，能否产生反馈、学习或可见决策？若后续故事不发生，它是否仍有价值或学习？依赖是否明确且小到可管理？推迟的路径、数据、规则和质量是否可见？是否可安全发布，或发布约束是否明确？是否避免规定不必要的实现细节？最终完整能力是否仍然可见？
危险信号包括：按流程活动拆（设计、编码、测试、文档、部署）的子故事；“作为数据库/API/前端/服务……”；“构建后端”和“构建前端”作为独立故事；“收集数据”或“构建集成”而没有用户可见或能产生反馈的结果；每个子项都必须完成才能测试任何子项；每个故事都要一个 spike；验收标准只说“可用”或“快”而没有可观察细节；切片细到只指定一个解决方案细节；所有业务规则被不加讨论地强行塞进第一个切片。
输出格式
被要求拆分故事时，返回可直接喂给 planning 的紧凑制品，包含：Parent（重构后的父能力）、Recommended First Slice（一句话故事及为何首选）、Split Candidates 表格（切片、价值、包含、推迟、验收示例、发布约束）、Parking Lot（明确的后续项、问题或有意图不拆的任务）、Warnings（组件式拆分、不安全的推迟、不明确的所有权或缺失示例）、Next Step（对选定的第一个切片使用项目的规划与交付说明；可用时对拆分运行 find-gaps；或提出一个决策问题）。若用户想要交互式梳理，一次只问一个高价值问题，通常是 actor、结果、发布约束、最高价值客户细分或最大风险。