拆成工单
把一份计划、规格说明或对话拆成一组工单：曳光弹式的垂直切片，每张工单都声明哪些工单阻塞它。
议题跟踪器与分诊标签词表应该已经提供给你了。如果没有，请告诉用户运行 /setup-matt-pocock-skills。
流程
1. 收集上下文
从对话上下文里已有的内容出发。如果用户以参数形式传了一个引用（规格说明的路径、议题编号或 URL），就把它取来，读完它的正文与评论。
2. 探索代码库（可选）
如果你还没有探索过代码库，就去探索一遍，弄清代码当前的状态。工单标题与描述应当使用项目领域词汇表的用词，并遵守你所触碰领域的 ADR。
找机会先做预重构，让实现更省力。「先让改动变容易，再做容易的改动。」
3. 起草垂直切片
把工作拆成一张张曳光弹工单。
- 每个切片都要穿过每一层（数据结构、API、UI、测试），切出一条狭窄但完整的路径：是垂直的，而不是某一层的水平切片
- 一个完成的切片本身就能演示或验证
- 每个切片的大小要能放进一个全新的上下文窗口
- 任何预重构都应最先做
给每张工单标出它的阻塞边：也就是必须先完成、它才能开始的其他工单。没有阻塞边的工单可以立刻开始。
大范围重构是垂直切片的例外。 大范围重构指一次机械性改动（重命名一列、给共享符号改类型），它的爆炸半径横跨整个代码库，一次编辑就会同时打断成千上万个调用点，没有任何垂直切片能单独落地并保持绿灯。不要硬把它塞进曳光弹；把它排成先扩展后收缩。先扩展：把新形式加在旧形式旁边，让什么都不坏。再按爆炸半径分批把调用点迁移过去（按包、按目录），每一批各自一张工单、被扩展那张阻塞；由于旧形式还在，一批接一批地保持 CI 绿。最后收缩：等没有调用方留下来时删掉旧形式，这张工单被所有迁移批次阻塞。如果连分批也无法各自保持绿，就保留这个顺序，但让它们共用一条集成分支，并让所有批次都阻塞一张最终的集成验证工单；只在那一张工单上承诺全绿。
4. 向用户逐项确认
把提议的拆分以编号清单形式呈现。每张工单都要展示：
- 标题：简短、有描述性的名字
- 被谁阻塞：还有哪些工单（如果有）必须先完成
- 它交付什么：这张工单让哪段端到端行为真正可用
问用户：
- 粒度合适吗？（太粗 / 太细）
- 阻塞边对吗：每张工单是不是只依赖真正拦住它的那些工单？
- 有没有哪些工单应该合并，或者再拆开？
反复迭代，直到用户认可这份拆分。
5. 把工单发布到已配置的跟踪器
把已认可的工单发布出去。怎么发布取决于 /setup-matt-pocock-skills 配置的跟踪器；两种方式下工单本身是一样的，只是阻塞边的形态不同：
- 本地文件 → 在
.scratch/<feature-slug>/issues/<NN>-<slug>.md下，一张工单写一个文件，按依赖顺序从01开始编号（先写阻塞方）。每个文件的「被谁阻塞」列出它依赖的编号／标题。使用下面的单工单文件模板：一张工单一个文件，绝不要把所有工单合成一个文件。 - 真实的议题跟踪器（GitHub、Linear、……） → 按依赖顺序（先写阻塞方）一张工单发布一个议题，这样每张工单的阻塞边都能引用真实的标识符。平台有原生阻塞／子议题关系就用原生的；没有就把每张工单的「被谁阻塞」设成阻塞它的那些议题。除非另有指示，否则打上
ready-for-agent分诊标签；这些工单从构造上就是代理可以直接领取的。
处理前沿：也就是那些不被任何工单阻塞、可以立刻开始的工单。对于一条纯线性的链条，就是从最上面一路做到最下面。
不要关闭或修改任何父议题。
: <工单标题>
要构建什么： 这张工单让哪段端到端行为真正可用，从用户的视角描述，而不是逐层的实现清单。
被谁阻塞： 拦住这张工单的工单编号／标题，或者「无（可以立刻开始）」。
状态： ready-for-agent
- 验收判据 1
- 验收判据 2
父议题
指向跟踪器上父议题的引用（如果来源就是一个已有议题；否则省略这一节）。
要构建什么
这张工单让哪段端到端行为真正可用，从用户的视角描述，而不是逐层的实现。
验收判据
- 判据 1
- 判据 2
被谁阻塞
- 指向每张阻塞工单的引用，或者「无（可以立刻开始）」。
无论采用哪种形式，都要避免写具体的文件路径或代码片段：它们很快就会过时。例外：如果某个原型产出的片段比文字叙述更精确地表达了某项决策（状态机、归约器、数据结构、类型形状），就把它内联进来，并简短说明它来自原型。只保留决策密集的部分，不要整个可运行的演示，只要重要的那几点。
