用途：把一份计划、规格或当前对话拆解为一组工单，每张工单是一个 tracer-bullet 纵向切片，并声明阻塞它的其他工单。它通常不由模型自行发现，需由人指定，或由 /specs-to-tickets 在步骤 3 逐份规格调用。发布工单到共享追踪器必须被明确要求，不可主动发起。
主要能力：先收集上下文（对话内容或用户传入的规格路径、issue 编号/URL）；可选地探索代码库，使用项目领域词汇并遵守相关 ADR，寻找 prefactor 机会；在起草前先确定粒度（按切片边界切分，或目标最少工单数）；起草纵向切片，每片贯穿 schema、API、UI、测试各层，可独立演示或验证，且能放入单个新上下文窗口；为每张工单标注阻塞边；宽重构例外，按 expand–contract 排序。
使用方式：先确认追踪器与分诊标签词汇已提供，否则提示用户运行 /setup-matt-pocock-skills。随后以编号列表向用户展示拆分结果（标题、被谁阻塞、交付内容），询问粒度、阻塞边、是否合并或拆分，迭代至批准。发布时按依赖顺序（阻塞者在前）：本地文件写入 .scratch/<feature-slug>/issues/<NN>-<slug>.md，每张工单一个文件；真实追踪器（GitHub、Linear 等）每张工单一个 issue，使用平台原生阻塞/子 issue 关系，否则在“Blocked by”中引用阻塞 issue，并默认打上 ready-for-agent 标签。不要关闭或修改任何父 issue。
适用场景：把已定稿的规格转为构建待办，供 /implement 逐张处理；也可由人直接针对规格、issue 或对话调用。
限制：工单正文避免具体文件路径或代码片段（易过时），仅当原型片段比文字更精确编码决策时可内联并注明来源；粒度与合并/拆分决定需按 approval-policy 记录在追踪器上，理由写入工单或父项评论，不写入被切分的规格。资料未提供具体收费、价格与平台支持细节。