菜单
将计划、spec 或当前对话拆分为一组曳光弹式 tickets，每个 ticket 声明其阻塞边，发布到已配置的 tracker —— 对于本地文件，边以文本形式呈现；对于真实 tracker，使用原生阻塞链接。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
询问哪种技能或流程适合你的情况。本仓库技能的导航器。
沿两个轴线审查自某个固定点（commit、分支、tag 或合并基准）以来的变更 — 标准（代码是否遵循此仓库已记录的编码规范？）和规范（代码是否匹配原始 issue/PRD 要求的内容？）。以并行子 agent 运行两项审查，并将结果并排呈现。当用户想要审查分支、PR、进行中的变更，或要求"从 X 开始审查"时使用。
设计深层模块的共享词汇。当用户想要设计或改进模块接口、寻找深化机会、决定缝合点放在哪里、使代码更可测试或更适合 AI 导航，或当其他技能需要深层模块词汇时使用。
针对疑难 bug 和性能回归的诊断循环。当用户说"诊断"/"调试这个"，或报告有东西损坏/抛出异常/失败/变慢时使用。
构建和精炼项目的领域模型。当用户想要确定领域术语或通用语言、记录架构决策，或当其他技能需要维护领域模型时使用。
一场无情的面试，用于打磨方案或设计。
| name | to-tickets |
| description | 将计划、spec 或当前对话拆分为一组曳光弹式 tickets，每个 ticket 声明其阻塞边，发布到已配置的 tracker —— 对于本地文件，边以文本形式呈现；对于真实 tracker，使用原生阻塞链接。 |
| disable-model-invocation | true |
将计划、spec 或对话拆分为一组 tickets —— 曳光弹式垂直切片，每个 ticket 声明阻塞它的那些 tickets。
Issue tracker 和 triage 标签词汇表应已提供给你 —— 如果没有，运行 /setup-matt-pocock-skills。
基于对话上下文中已有的内容进行工作。如果用户将某个引用（spec 路径、issue 编号或 URL）作为参数传入，拉取它并读取其完整正文和评论。
如果尚未探索代码库，进行探索以了解代码的当前状态。Ticket 标题和描述应使用项目的领域词汇表，并尊重所涉及区域的 ADR。
寻找预重构（prefactor）的机会，使实现更简单。"让变更变容易，然后做容易的变更。"
将工作拆分为曳光弹 tickets。
为每个 ticket 标注其阻塞边 —— 即必须在它开始之前完成的其他 tickets。没有阻塞边的 ticket 可以立即开始。
宽重构是垂直切片的例外。 宽重构是指一个机械性变更 —— 重命名字段、修改共享符号的类型 —— 其影响范围辐射整个代码库，因此单次编辑会破坏数千个调用点，任何垂直切片都无法以绿色状态落地。不要强行将其塞入曳光弹；应将其排序为扩展-收缩序列。首先扩展：在旧形式旁边添加新形式，使一切不中断。然后按影响范围分批迁移调用点（按包、按目录），每批是一个由扩展阶段阻塞的独立 ticket，保持 CI 逐批绿色，因为旧形式仍然存在。最后收缩：当没有调用方残留时删除旧形式，由一个由所有迁移批次阻塞的 ticket 负责。当连批次本身都无法独立保持绿色时，保持排序不变，但让它们共享一个集成分支，所有批次共同阻塞一个最终的集成验证 ticket —— 绿色仅在该处得到承诺。
以编号列表形式呈现提议的拆分方案。对于每个 ticket，展示：
询问用户：
迭代直到用户批准拆分方案。
发布已批准的 tickets。如何发布取决于 /setup-matt-pocock-skills 配置的 tracker —— 无论哪种方式 tickets 都相同，只有阻塞边的形式不同：
tickets.md，按依赖顺序排列所有 tickets（阻塞者在前），每个 ticket 的"被阻塞于"列出它所依赖的标题。使用下面的文件模板。ready-for-agent triage 标签 —— 这些 tickets 在构造上就是 agent 可领取的。不要关闭或修改任何父 issue。
一句话总结这些 tickets 构建的内容。如果有来源 spec，引用它。
从前沿开始工作：找到所有阻塞边已完成的 tickets。对于纯线性链，这意味着从上到下。
要构建什么： 此 ticket 使哪些端到端行为可用，从用户视角 —— 不是逐层实现清单。
被阻塞于： 阻碍此 ticket 的 tickets 标题，或"无 —— 可立即开始"。
...
对 tracker 上父 issue 的引用（如果来源是已有 issue，否则省略此节）。
此 ticket 使哪些端到端行为可用，从用户视角 —— 不是逐层实现。
无论哪种形式，避免具体文件路径或代码片段 —— 它们会很快过时。例外：如果原型产生了一个代码片段，它比文字更精确地编码了一个决策（状态机、reducer、schema、类型结构），将其内联并简要注明来自原型。精简到富含决策的部分 —— 不是可运行的演示，只是关键部分。
使用 /implement 逐个处理前沿上的 tickets，ticket 之间清空上下文。