to-tickets

转换为工单

将计划、规格说明或对话拆分为一组工单：每个工单都是一条垂直切片的 tracer bullet，并声明阻塞它的工单。

应该已向你提供问题跟踪系统和分诊标签词汇。如果没有，请告知用户运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

利用对话中已有的上下文。如果用户将参考资料（规格说明路径、问题编号或 URL）作为参数传入，请获取并阅读其完整内容和评论。

2. 探索代码库（可选）

如果你尚未探索代码库，请先了解代码的当前状态。工单标题和描述应使用项目的领域词汇表，并遵循你要修改部分的 ADR。

留意能否预先重构代码，让实现更容易。“先让改动变得容易，再做容易的改动。”

3. 起草垂直切片

将工作拆分为tracer bullet 工单。

• 每个切片都应贯穿每一层（架构、API、UI、测试），形成一条范围窄但完整的路径：垂直切片，而非只覆盖某一层的水平切片
• 每个已完成的切片都能独立演示或验证
• 每个切片的工作量应适合在一个全新的上下文窗口中完成
• 任何预先重构都应先完成

为每个工单注明其阻塞关系：必须先完成哪些其他工单，它才能开始。没有阻塞项的工单可以立即开始。

为每个工单注明完成标准和停止条件，因为实现者会独立执行该工单：

• 完成意味着：验收标准中的每一项都是可观察的结果，且在起始提交时不成立、工作完成时成立（例如，“测试套件通过”“所有调用点都使用新客户端”）。实现者应持续工作，直到所有标准都满足。
• 只有在以下情况下停止并询问：实现者无法独立判断的一种情况，例如“测试因无法解释的原因失败”或“迁移会丢弃数据”。其他情况都由实现者自行决定，并在 PR 中记录决定。如果没有符合条件的情况，请写“无：自行决定并在 PR 中注明”。

大范围重构是垂直切片规则的例外。大范围重构是指一项机械性改动（例如重命名列、重新定义共享符号的类型），其影响范围遍及整个代码库，导致一次编辑就会同时破坏成千上万个调用点，因此无法通过任何垂直切片来保持 CI 通过。不要强行将其拆成 tracer bullet；应按扩展—收缩顺序推进。首先扩展：在旧形式旁边添加新形式，确保不造成破坏。然后分批迁移调用点，批次大小按影响范围划分（每个包或目录一个批次），每批单独建一个被扩展工单阻塞的工单；旧形式仍然存在，因此每批迁移后都要保持 CI 通过。最后收缩：确认不再有调用方后，在一个被所有迁移批次阻塞的工单中删除旧形式。如果连各批次都无法独立保持 CI 通过，就保留该顺序，但让它们共用一个集成分支，并让每个批次都阻塞最终的集成与验证工单；只有在该工单中才保证 CI 通过。

4. 向用户确认

以编号列表的形式展示拟议的拆分。每个工单都应列出：

• 标题：简短的描述性名称
• 阻塞项：必须先完成的其他工单（如有）
• 交付内容：该工单实现的端到端行为
• 只有在以下情况下停止并询问：实现者应停止的情况，或“无”

询问用户：

• 粒度是否合适？（太粗 / 太细）
• 阻塞关系是否正确：每个工单是否只依赖真正构成前置条件的工单？
• 是否需要合并某些工单，或进一步拆分？

与用户反复迭代，直到用户批准拆分方案。

5. 将工单发布到已配置的跟踪系统

发布已批准的工单。具体方式取决于配置的跟踪系统 /setup-matt-pocock-skills；无论采用哪种方式，工单内容都相同，只有阻塞关系的形式不同：

• 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下为每个工单写入一个文件，按依赖顺序从 01 开始编号（先列阻塞项）。每个文件的“Blocked by”列出它所依赖工单的编号／标题。使用下面的单工单文件模板：每个文件一个工单，绝不要合并到同一个文件中。
• 真实的问题跟踪系统（GitHub、Linear，……） → 按依赖顺序（先列阻塞项）为每个工单发布一个问题，以便每个工单的阻塞关系都能引用真实标识符。平台有原生阻塞关系功能时使用该功能；否则，将阻塞问题列入每个工单的“Blocked by”。如果来源是一个现有问题，则将每个工单设为它的子问题（使用跟踪系统文档中的操作）。除非另有说明，否则添加 ready-for-agent 分类标签；这些工单已按设计可由 Agent 领取。

按前沿推进：所有阻塞项都已完成的工单。对于完全线性的依赖链，这意味着从上到下推进。

不要关闭或修改任何父问题。

像上面那样将工单关联为父问题的原生子问题，不算“修改”父问题；这正是要做的事。

：

要构建的内容： 从用户角度描述此工单要实现的端到端行为，而不是逐层列出实现步骤。

阻塞项： 阻塞此工单的工单编号／标题，或“无（可立即开始）”。

状态： ready-for-agent

完成标准：

• 验收标准 1
• 验收标准 2

仅在以下情况暂停并询问： 实施者无法独自决定的一种情况，或“无：自行决定并在 PR 中说明”。

父问题

跟踪系统中父问题的引用（如果来源是现有问题；否则省略此部分）。

要构建的内容

从用户角度描述此工单要实现的端到端行为，而不是逐层描述实现过程。

完成标准

• 验收标准 1
• 验收标准 2

仅在以下情况暂停并询问

实施者无法独自决定的一种情况，或“无：自行决定并在 PR 中说明”。

阻塞项

• 对每个阻塞工单的引用，或“无（可立即开始）”。如果阻塞项已设为原生关系，则省略此部分。

无论使用哪种形式，都要避免使用具体文件路径或代码片段：它们很快就会过时。例外：如果原型生成的代码片段比文字更精确地表达了某项决策（状态机、reducer、架构、类型形状），则可以将其内联，并简要注明它来自原型。仅保留能清晰表达决策的部分，不要放入可运行的演示，只保留重要内容。