快速开始
npx skills add mattpocock/skills --skill=to-ticketsnpx skills update to-tickets功能说明
to-tickets 将计划、规格说明或当前对话拆解为一组任务（ticket）——每个任务都是一个追踪弹式的垂直切片——并将其发布到你配置好的追踪器中，每个任务都会声明阻塞它的前置任务。
每个任务都是一颗追踪弹（tracer bullet）——一个贯穿所有集成层（数据模式、API、UI、测试）的薄薄的垂直切片，而不是某一层的水平切片。一个完整的切片本身是可演示或可验证的，这正是每个任务可以安全地交给智能体去执行的原因。
何时使用
你通过输入 /to-tickets 来调用它——智能体不会主动使用它。
当你已经有了达成一致的计划或书面规格说明，并希望将其拆解为任务时使用它。将对话指向它，或者传入一个规格说明或问题（issue）的引用，它会先获取正文和评论。如果变更还没有被写为规格说明，请先生成一份——可以使用 to-spec。
前置条件
to-tickets 会发布到你的问题追踪器中，所以 setup-matt-pocock-skills 必须已经为该代码仓库配置好了追踪器及其分类标签词汇。在真实的追踪器上，它会在发布时自动应用 ready-for-agent 标签。
一份产物，两种解读
阻塞依赖关系是核心要点。它们使得同一组任务可以根据追踪器的不同有两种解读方式：
- 本地文件 → 在
.scratch/<feature>/issues/下每个任务一个文件，按依赖顺序编号（阻塞者优先），依赖关系以文本形式写入。你按顺序从上到下逐个手动处理，全程保持参与。
- 真实追踪器（GitHub、Linear） → 每个任务对应一个 issue，依赖关系以原生的阻塞链接（或子问题）表示。所有前置任务都已完成的任务处于前沿（frontier），可以被领取——这样多个智能体可以同时运行。
无论使用哪种媒介，依赖关系都存在于任务中；媒介只决定是否可以并行处理它们。to-tickets 负责生成产物——至于如何执行（按顺序手动处理，还是并行队列）则由你决定。
垂直切片，而非水平切片
整个技能围绕一个核心区别展开。水平切片只交付变更的某一层——所有数据模式，或所有 API——在每一层都完成之前，整个功能都无法工作。垂直切片，即追踪弹，一次性贯穿每一层的一条狭窄路径，因此完成之后立刻就可以演示。
在切片之前，to-tickets 会寻找预重构（prefactoring）的机会——"先让变更变简单，再做简单的变更"——并优先安排这部分工作。然后，在发布任何内容之前，它会向你确认拆分方案（粒度、阻塞依赖关系、哪些需要合并或拆分），并且会先发布被阻塞的任务，这样每个任务的"Blocked by"字段就能引用真实存在的任务。
大规模重构的例外情况
有一种情况会打破追踪弹规则：大规模重构——一个单一的机械性变更（比如重命名一个列、重类型化一个共享符号），其影响半径波及整个代码库，一处修改会同时破坏数千个调用点，没有任何垂直切片能保持构建绿色。to-tickets 会将其拆解为扩展-收缩（expand–contract）模式：先扩展（在旧形式旁边添加新形式，确保没有任何功能被破坏），然后迁移（按影响半径分批迁移调用点，每批一个任务，由于旧形式仍然存在，整个过程 CI 保持绿色），最后收缩（在所有调用者都迁移完成后删除旧形式）。当即使分批也无法独自保持绿色时，它们会共享一个集成分支，所有批次都阻塞一个最终的集成与验证任务，只有在那里才承诺构建绿色。
在整个流程中的位置
to-tickets 是主构建链中的一个步骤：
grill-with-docs → to-spec → to-tickets → implement → code-review它位于 to-spec（提供已确定的规格说明和用户故事作为切片依据）和 implement（负责构建每个任务，内部驱动 tdd 以测试优先的方式编写测试，然后进行 code-review 评审）之间。每开启一个新的上下文就处理一个前沿任务，任务之间保持上下文隔离。当你不确定哪个技能或流程适合时，可以找 ask-matt 帮你导航。