用途
to-tickets 用于把一份计划、规格说明（spec）或当前对话内容，拆解成一组工单（tickets）。这些工单是“曳光弹式”的垂直切片，每个工单都声明其阻塞边（blocking edges），即必须先完成哪些工单才能开始。最终工单会发布到已配置的问题跟踪器。
使用前提：问题跟踪器和分类标签词表应当已经提供给你。如果没有，需要提示用户运行 /setup-matt-pocock-skills。
主要能力
- 从对话上下文、规格路径、issue 编号或 URL 中收集上下文。
- 可选地探索代码库，理解当前代码状态，并使用项目领域词汇表命名工单，遵守相关 ADR。
- 寻找预重构（prefactor）机会，让后续实现更容易。
- 将工作拆解为垂直切片：每个切片贯穿所有层（schema、API、UI、测试），是垂直而非水平切片；每个切片可独立演示或验证，且大小适合单个全新上下文窗口。
- 为每个工单指定阻塞边、完成标准（finish line）和停止条件（stop condition）。
- 处理宽重构（wide refactor）这一垂直切片的例外情况，采用 expand–contract 顺序。
- 向用户展示拆解方案并迭代，直到用户批准。
- 将批准的工单发布到已配置的跟踪器。
使用方式
流程分为五步：
- 收集上下文：基于对话中已有内容工作；若用户传入引用（规格路径、issue 编号或 URL），则获取并阅读其完整正文和评论。
- 探索代码库（可选）：若尚未探索，则了解代码当前状态；工单标题和描述应使用项目领域词汇表，并遵守相关 ADR；寻找预重构机会。
- 起草垂直切片：将工作拆成曳光弹工单，每个切片贯穿所有层、可独立验证、适合单个上下文窗口；预重构应最先完成；为每个工单指定阻塞边、完成标准和停止条件。
- 向用户提问：以编号列表展示拆解方案，每个工单显示标题、被谁阻塞、交付内容、停止条件；询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分；迭代直到用户批准。
- 发布工单到已配置的跟踪器：根据 /setup-matt-pocock-skills 配置的跟踪器类型发布。本地文件则每个工单写一个文件到 .scratch/<feature-slug>/issues/<NN>-<slug>.md，按依赖顺序从 01 编号；真实问题跟踪器（GitHub、Linear 等）则按依赖顺序每个工单发布一个 issue，并作为父 issue 的原生子 issue 链接，阻塞关系也作为原生阻塞边连接。默认应用 ready-for-agent 分类标签。不要关闭或修改任何父 issue。
工单模板包含：What to build（从用户视角描述的端到端行为）、Blocked by（阻塞它的工单编号/标题，或“None”）、Status（ready-for-agent）、Done means（验收标准）、Stop and ask only if（唯一需要停下来询问的情况，或“None: decide and note it in the PR”）。
适用场景
- 需要把计划、规格或讨论内容转化为可执行、可独立验证的工单时。
- 希望工单按依赖顺序排列、每个工单有明确完成标准和停止条件时。
- 需要将工单发布到本地文件或 GitHub、Linear 等真实问题跟踪器时。
- 需要处理宽重构（如重命名列、重新类型化共享符号）这类无法用单一垂直切片落地的情况时。
限制
- 使用前必须已配置问题跟踪器和分类标签词表，否则需先运行 /setup-matt-pocock-skills。
- 工单中应避免具体文件路径或代码片段，因为它们容易过时；例外是原型产生的、比文字更精确表达决策的片段（如状态机、reducer、schema、类型形状），可内联并注明来自原型。
- 宽重构是垂直切片的例外，需按 expand–contract 顺序处理；当批次无法单独保持绿色时，需共享集成分支并由最终 integrate-and-verify 工单保证绿色。
- 不要关闭或修改任何父 issue；将工单作为原生子 issue 链接到父 issue 不属于“修改”父 issue。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。