用途
To Tickets 用于把一份计划、规格说明（spec）或当前对话，拆解成一组工单（tickets）。这些工单是「曳光弹」式的垂直切片，每个工单都声明阻塞它的其他工单（blocking edges），最终发布到已配置的追踪器。
使用前提：issue tracker 与分诊（triage）标签词汇应已提供给你。如果没有，需提示用户运行 /setup-matt-pocock-skills。
主要能力与流程
1. 收集上下文
从对话上下文中已有的内容出发。如果用户以参数形式传入引用（spec 路径、issue 编号或 URL），则获取并阅读其完整正文与评论。
2. 探索代码库（可选）
如果尚未探索代码库，则进行探索以了解代码当前状态。工单标题与描述应使用项目的领域词汇表（domain glossary）术语，并遵守所涉及区域的 ADR。仅在能消除已证实的阻塞或缩小所请求变更的影响范围时，才寻找预重构（prefactoring）。原则是「先让变更变容易，再做容易的变更」。
3. 起草垂直切片
把工作拆成曳光弹工单：
- 每个切片贯穿每一层（schema、API、UI、测试），是一条狭窄但完整的路径：是垂直的，而不是某一层的水平切片。
- 完成的切片本身可演示或可验证。
- 每个切片的大小应能放进一个全新的上下文窗口。
- 任何预重构都应最先完成。
- 为每个工单指定阻塞边：必须先完成哪些其他工单才能开始。没有阻塞的工单可立即开始。
宽泛重构（wide refactor）是垂直切片的例外。宽泛重构是一次机械性变更（重命名一列、改变共享符号的类型），其影响范围横跨整个代码库，单次编辑会同时破坏成千上万个调用点，任何垂直切片都无法保持绿色。不要强行把它塞进曳光弹，而应按 expand–contract 排序：先 expand，在旧形式旁添加新形式，确保不破坏任何东西；再按影响范围分批迁移调用点（按包、按目录），每批自成一个工单，被 expand 阻塞，由于旧形式仍存在，CI 可逐批保持绿色；最后 contract，在无调用者残留后删除旧形式，该工单被所有迁移批次阻塞。当批次本身也无法单独保持绿色时，保留该序列，但让它们共享一个集成分支，全部阻塞一个最终的 integrate-and-verify 工单，绿色只在那里承诺。
4. 向用户提问确认
以编号列表呈现提议的拆解。每个工单展示：
- Title：简短描述性名称
- Blocked by：必须先完成哪些其他工单（如有）
- What it delivers：该工单让什么端到端行为得以工作
询问用户：粒度是否合适（太粗/太细）？阻塞边是否正确，每个工单是否只依赖真正阻塞它的工单？是否有工单应合并或进一步拆分？迭代直到用户批准该拆解。
5. 发布工单到已配置的追踪器
发布已批准的工单。方式取决于 /setup-matt-pocock-skills 配置的追踪器；工单本身相同，只是阻塞边的形态不同：
- 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下每个工单写一个文件，按依赖顺序从 01 编号（阻塞者在前）。每个文件的「Blocked by」列出其依赖的编号/标题。使用下方每工单文件模板：一个工单一个文件，绝不合并成单个文件。
- 真实 issue tracker（GitHub、Linear 等）→ 按依赖顺序（阻塞者在前）每个工单发布一个 issue，以便每个工单的阻塞边能引用真实标识符。若平台有原生阻塞/子 issue 关系则使用之；否则把每个工单的「Blocked by」设为阻塞它的 issue。除非另有指示，应用 ready-for-agent 分诊标签；这些工单在构造上就是可供 agent 抓取的。
处理前沿（frontier）：任何阻塞者都已完成的工单。对于纯线性链，即从上到下。
不要关闭或修改任何父 issue。
工单模板
模板包含以下字段：
- What to build：该工单让什么端到端行为得以工作，从用户视角描述，而非逐层实现清单。
- Blocked by：阻塞该工单的编号/标题，或「None (can start immediately)」。
- Status：ready-for-agent
- 验收标准（Acceptance criterion 1、2……）
- Parent：对追踪器上父 issue 的引用（如果来源是已有 issue，否则省略此节）。
另一种形态包含：Parent、What to build、Acceptance criteria、Blocked by。
两种形态都应避免实现文件路径或代码片段：它们很快会过时。保留配置的本地工作流所需的追踪器路径。例外：如果原型产出的片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型形状），则内联它并简要注明来自原型。只保留决策密集的部分，不是可运行 demo，只是重要片段。
适用场景
适用于需要把计划、规格或对话转化为可执行、可追踪、带依赖关系的工单集合的软件开发流程，尤其适合希望工单能被 AI agent 抓取执行的团队。
限制
使用前必须已配置 issue tracker 与分诊标签词汇（通过 /setup-matt-pocock-skills），否则需先提示用户运行该命令。工单应避免实现文件路径与代码片段。不要关闭或修改任何父 issue。