转为工单
将计划、规格或对话拆解为一组工单：追踪子弹式垂直切片，每张工单声明其阻塞的工单。
应向您提供问题追踪器和分类标签词汇表。如果未提供，请告知用户运行 /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
被谁阻塞
- 每个阻塞工单的引用，或“无（可立即开始）”。
无论哪种形式，避免指定文件路径或代码片段：它们会很快过时。例外：如果原型产生了一个比散文更精确地编码决策的片段（状态机、reducer、模式、类型形状），则内联它并简要说明它来自原型。仅保留决策丰富的部分，而非工作演示，只包含重要的位。