to-tickets

在开展面向仓库的工作之前，请阅读 ../../WORK-ROUTING.md。该文件是项目文档、工作路径选择、计划归属和收尾工作的共享路由依据。

转为工单

将计划、规范或对话拆分为一组工单——每个工单都是一个追踪子弹式的纵向切片，并明确声明哪些工单会阻塞它。

问题跟踪器和分类标签词汇表应该已经提供给你；如果没有，请运行 /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 开始编号（阻塞项在前）。每个文件的“Blocked by”列出其依赖的工单编号／标题。使用下方的单工单文件模板——每个文件对应一个工单，绝不合并到同一个文件中。
• 真实的问题跟踪系统（GitHub、Linear 等） → 按依赖顺序为每个工单发布一个问题（阻塞项在前），以便每个工单的阻塞关系都能引用真实标识符。如果平台支持原生的阻塞／子问题关系，请使用；否则在每个工单的“Blocked by”中列出阻塞它的问题。除非另有说明，否则添加 ready-for-agent 分诊标签——这些工单本身就已具备供 Agent 领取的条件。

处理前沿项：所有阻塞项都已完成的工单。若依赖链是纯线性的，则按从上到下的顺序处理。

请勿关闭或修改任何父级问题。

—

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

阻塞于： 阻塞此工单的其他工单的编号／标题，或“无——可立即开始”。

状态： ready-for-agent

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

父级问题

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

要构建的内容

此工单要实现的端到端行为，从用户的角度描述，而不是按层罗列实现内容。

验收标准

• 标准 1
• 标准 2

阻塞于

• 每个阻塞工单的引用，或“无——可立即开始”。

无论采用哪种形式，都避免写入具体文件路径或代码片段——它们很快就会过时。例外：如果原型生成的代码片段比文字更准确地表达了某项决策（状态机、reducer、schema、类型结构），则可将其内嵌，并简要注明它来自原型。只保留富含决策信息的部分——不要提供可运行的演示，只保留重要内容。