to-tickets

拆分为工单

将计划、规格说明或对话拆分为一组工单：每个工单都是一个探针式（tracer bullet）纵向切片，并声明会阻塞它的其他工单。

问题追踪器和分流标签词汇应已提供给你。如果没有，请告知用户运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

基于对话上下文中已有的内容开展工作。如果用户以参数形式传入引用（规格路径、Issue 编号或 URL），请获取并阅读其完整正文和评论。

2. 探索代码库（可选）

如果尚未探索代码库，请先探索，以了解代码的当前状态。工单标题和描述应使用项目领域术语表中的词汇，并遵守所涉及领域的 ADR。

寻找可以先对代码进行预重构（prefactor）的机会，使实现更容易。"先让变更变得容易，再做那个容易的变更。"

3. 起草纵向切片

将工作拆分为探针式工单。

• 每个切片贯穿每一层（schema、API、UI、测试）切出一条窄但完整的路径：纵向，而非只针对单一层的横向切片
• 完成后的切片可以独立演示或验证
• 每个切片的大小应能放入单个全新的上下文窗口中
• 任何预重构都应先完成

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

大范围重构是纵向切片的例外。 大范围重构是指一次机械性变更（如重命名列、更改共享符号的类型），其影响范围遍及整个代码库，单次修改就会导致数千处调用点同时出错，因此没有任何纵向切片能够独立保持绿色构建。不要强行将其拆成探针式工单，而应按**扩展–收缩（expand–contract）**方式排序。首先进行扩展：在旧形式旁边添加新形式，使现有功能不受影响。然后按影响范围的大小（按包、按目录）分批迁移调用点，每一批作为一个独立工单，并以扩展工单为阻塞项；由于旧形式仍然存在，各批之间可保持 CI 绿色。最后进行收缩：当不再有任何调用方时，删除旧形式，该工单以所有迁移批次为阻塞项。如果即使分批也无法单独保持绿色，则保留这一顺序，但让各批次共用一个集成分支，并由所有批次阻塞一个最终的集成与验证工单；只有在该工单处才承诺绿色构建。

4. 向用户确认

将拟定的拆分方案以编号列表形式呈现。对每个工单，展示：

• 标题：简短的描述性名称
• 阻塞于：必须先完成的其他工单（如有）
• 交付内容：该工单实现的端到端行为

询问用户：

• 粒度是否合适？（过粗 / 过细）
• 阻塞关系是否正确：每个工单是否只依赖真正对其构成阻塞的工单？
• 是否有工单需要合并或进一步拆分？

反复调整，直至用户批准该拆分方案。

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

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

• 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下为每个工单写入一个文件，按依赖顺序从 01 开始编号（阻塞项在前）。每个文件的“阻塞于”字段列出其依赖的工单编号／标题。使用下方的单工单文件模板：每个文件对应一个工单，绝不合并到单个文件中。
• 真实的工单跟踪系统（GitHub、Linear 等） → 按依赖顺序（阻塞项在前）为每个工单发布一个 issue，以便各工单的阻塞关系可以引用真实标识符。平台支持原生阻塞关系／子工单关系时，请使用该功能；否则，在每个工单的“阻塞于”字段中列出阻塞它的工单。除非另有说明，否则添加 ready-for-agent 分类标签；这些工单从设计上即可由 Agent 领取。

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

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

：

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

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

状态： ready-for-agent

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

父级

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

要构建的内容

描述此工单要实现的端到端行为，从用户角度出发，不要按层罗列实现方式。

验收标准

• 标准 1
• 标准 2

阻塞于

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

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