用途：把计划、规格或当前对话拆解为一组工单（tracer-bullet 纵向切片），每个工单声明阻塞它的其他工单，并发布到已配置的跟踪系统。使用前需已提供问题跟踪器与分诊标签词表，否则先运行 /setup-matt-pocock-skills。
主要能力与流程：一、收集上下文，基于对话已有内容；若用户传入规格路径、issue 编号或 URL，则抓取并阅读其正文与评论。二、可选地探索代码库，理解现状，工单标题与描述应使用项目领域词汇并遵守相关 ADR，同时寻找预重构机会。三、起草纵向切片：每个切片贯穿 schema、API、UI、测试等所有层，是纵向而非单层横向切片；完成的切片可独立演示或验证，且大小适合单个全新上下文窗口；预重构应最先完成；为每个工单标注阻塞边，无阻塞者可立即开始。宽泛重构是例外，按 expand–contract 排序：先扩展（新旧并存），再按影响范围分批迁移调用点，最后收缩删除旧形式；若分批无法单独保持绿色，可共享集成分支并由最终集成验证工单统一保证绿色。四、向用户提问确认：以编号列表展示每个工单的标题、被谁阻塞、交付内容，询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分，迭代至用户批准。五、发布到已配置的跟踪器：本地文件则写入 .scratch/<feature-slug>/issues/<NN>-<slug>.md，按依赖顺序从 01 编号，每工单一个文件；真实跟踪器（GitHub、Linear 等）则按依赖顺序每工单发布一个 issue，使用平台原生阻塞/子 issue 关系，否则在“Blocked by”中引用阻塞 issue，并默认打上 ready-for-agent 分诊标签。不要关闭或修改任何父 issue。
工单内容包含：What to build（从用户视角描述端到端行为，而非逐层实现清单）、Blocked by、Status、验收标准；若来源是已有 issue 可含 Parent。避免具体文件路径或代码片段，例外是原型中能更精确表达决策的片段（状态机、reducer、schema、类型形状），需精简并注明来自原型。
适用场景：需要把计划或规格转化为可独立交付、可验证、带依赖顺序的工单时。限制：依赖已配置的跟踪器与标签词表；未提供具体平台配置细节、收费或效果信息。