to-issues

拆分为 Issue

使用垂直切片（曳光弹）将计划拆分为可独立认领的 Issue。

Issue 跟踪器和分类标签词汇表应该已提供给你——如果没有，请运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

根据对话上下文中已有的内容开展工作。如果用户将 Issue 引用（Issue 编号、URL 或路径）作为参数传入，请从 Issue 跟踪器中获取它，并阅读其完整正文和评论。

2. 探索代码库（可选）

如果你尚未探索代码库，则进行探索，以了解代码的当前状态。Issue 标题和描述应使用项目的领域术语表词汇，并遵循所涉及区域的 ADR。

寻找对代码进行预重构的机会，以让实现更容易。“先让变更变得容易，再让容易的变更变得容易。”

3. 起草 Issue

将计划拆分为 曳光弹 Issue，并遵循 垂直切片规则。大范围重构是该规则的例外；应改用 扩展—收缩 方式进行切片（参见 大范围重构）。

4. 询问用户

以编号列表形式呈现拟议的拆分方式。对于每个切片，显示：

• 标题：简短描述性名称
• 被阻塞于：必须先完成的其他切片（如有）
• 涵盖的用户故事：此切片所解决的用户故事（如果源材料中有）

询问用户：

• 粒度是否合适？（太粗／太细）
• 依赖关系是否正确？
• 是否应合并或进一步拆分某些切片？

反复调整，直到用户认可该拆分方案。

5. 将 Issue 发布到 Issue 跟踪器

对于每个获批的切片，使用 Issue 正文模板 在 Issue 跟踪器中发布一个新 Issue。这些 Issue 视为已可供 AFK Agent 使用，因此除非另有指示，否则发布时需使用正确的分类标签。

按照依赖顺序发布 Issue（先发布阻塞项），以便引用真实的 Issue 标识符。如果跟踪器支持这些功能，则将每个切片作为原生 子 Issue 链接到其父 Issue，并将每个阻塞项配置为原生 阻塞边（具体机制见 Issue 跟踪器文档）；否则，使用 ## Parent 和 ## Blocked by 正文部分作为后备方案。

切勿关闭或修改任何父 Issue。

参考

垂直切片规则

每个 Issue 都是一个端到端贯穿所有集成层的精简垂直切片，而不是某一层的水平切片。

• 每个切片都提供一条贯穿各层的狭窄但完整路径（模式、API、UI、测试）
• 已完成的切片可以单独演示或验证
• 所有预重构都应首先完成

大范围重构

大范围重构是一项机械式更改——重命名列、更改共享符号的类型——其 影响范围 遍及整个代码库，因此单次编辑会同时破坏数千个调用点，任何垂直切片都无法单独合入并保持全绿。不要强行将其做成曳光弹；应改为按 扩展—收缩 顺序处理。首先扩展：在旧形式旁添加新形式，确保不会破坏任何内容。然后按影响范围确定批次大小，逐步迁移调用点（按包、按目录）；每个批次单独创建一个由扩展阶段阻塞的 Issue，由于旧形式仍然存在，因此可以让每个批次都保持 CI 全绿。最后收缩：一旦不再有调用方，就删除旧形式；该 Issue 由所有迁移批次阻塞。即使这些批次无法单独保持全绿，也要保留这一顺序，但让它们共享一个集成分支，并让所有批次都阻塞最后一个“集成并验证”Issue——全绿仅在该 Issue 中得到保证。

Issue 正文模板

## 父 Issue

指向 Issue 跟踪器中父 Issue 的引用（如果源材料是现有 Issue；否则省略本节）。

构建内容

简要说明此垂直切片。描述端到端行为，而不是逐层实现。

避免提及具体文件路径或代码片段——这些内容很快就会过时。例外：如果 /prototype 技能生成的代码比文字更准确地体现了某项设计决策（状态机、reducer、schema 或类型结构），请添加指向该原型代码所在位置的上下文指针，而不是直接内联。

验收标准

• 标准 1
• 标准 2
• 标准 3

阻塞因素

• 对阻塞工单的引用（如果有）

或“无——可立即开始”，如果没有阻塞因素。