Menü
把一份计划、规格或当前对话拆解成一组曳光弹式工单，每个工单声明其阻塞边（blocking edge），发布到已配置的 tracker——本地形式下把边作为文本写进每个工单一个文件，在真实 tracker 上则用原生阻塞链接。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
从两个维度审查自某个固定基点（提交、分支、标签或 merge-base）以来的改动 —— 规范（代码是否遵循本仓库有文档记录的编码规范？）与 需求（代码是否符合最初发起的 issue/PRD 的要求？）。以并行子代理运行两项审查并并排汇报。当用户想要审查某个分支、PR、进行中的改动，或要求“审查自 X 以来的改动”时使用。
基于一份规格或一组工单来实现一部分工作。
设计深模块的共享术语体系。当用户想要设计或改进某个模块的接口、寻找加深（deepening）的机会、决定接缝（seam）放在哪里、让代码更易测试或更利于 AI 导航时，或当其他技能需要用到深模块术语时使用。
构建并打磨项目的领域模型。当用户想要确定领域术语或统一语言（ubiquitous language）、记录架构决策，或当其他技能需要维护领域模型时使用。
通过一场刨根问底的访谈来打磨一份计划或设计。
通过一场刨根问底的访谈来打磨一份计划或设计，并在过程中同时产出文档（ADR 和词汇表）。
| name | to-tickets |
| description | 把一份计划、规格或当前对话拆解成一组曳光弹式工单，每个工单声明其阻塞边（blocking edge），发布到已配置的 tracker——本地形式下把边作为文本写进每个工单一个文件，在真实 tracker 上则用原生阻塞链接。 |
| disable-model-invocation | true |
把一份计划、规格或对话拆解成一组 工单——曳光弹式的纵向切片，每个都声明 阻塞（block） 它的那些工单。
issue tracker 与分诊（triage）标签词汇应当已经提供给你——如果没有，运行 /setup-matt-pocock-skills。
从对话上下文中已有的内容出发。如果用户以参数形式传入了一个引用（一个规格路径、一个 issue 编号或 URL），就获取它并阅读其完整正文和评论。
如果你还没探索过代码库，就去探索一下，以理解代码当前的状态。工单标题和描述应使用项目的领域词汇表词汇，并尊重你所触及区域内的 ADR。
寻找可以对代码进行 预重构（prefactor） 以让实现更容易的机会。"先让改动变得容易，再做那个容易的改动。"
把工作拆解成 曳光弹 工单。
- 每个切片切出一条穿过每一层（schema、API、UI、测试）的窄而 **完整** 的路径——是纵向的，**不是** 单层的横向切片 - 一个完成的切片本身即可演示或验证 - 每个切片的大小要能装进一个全新的上下文窗口 - 任何预重构都应最先做给每个工单标注它的 阻塞边——那些必须在它能开始之前完成的其他工单。没有阻塞项的工单可以立即开始。
宽重构（wide refactor）是纵向切片的例外。 一次 宽重构 是一个机械性的改动（重命名一列、给一个共享符号重新定型），其 波及半径（blast radius） 扇形扩散到整个代码库，以至于单次编辑会一下子破坏成千上万个调用点，没有任何纵向切片能落地为绿。不要把它硬塞进一颗曳光弹；把它按 扩张—收缩（expand–contract） 排序。先扩张：在旧形式旁边添加新形式，使一切都不破。然后按波及半径大小分批（按包、按目录）把调用点迁移过去，每一批都是自己独立的、被扩张工单所阻塞的工单，因为旧形式仍然存在，故 CI 能一批批保持为绿。最后收缩：一旦没有调用方残留，就删掉旧形式，放在一个被每个迁移批次所阻塞的工单里。当连各批次都无法各自保持为绿时，保留这个序列，但让它们共享一个集成分支，该分支阻塞一个最终的"集成并验证"工单——绿只在那里被承诺。
把拟定的拆解作为带编号的列表呈现。对每个工单，展示：
问用户：
反复迭代，直到用户认可这份拆解。
发布已认可的工单。怎么发布？ 取决于 /setup-matt-pocock-skills 配置的 tracker——工单本身两种情况下都一样，只有阻塞边的形态不同：
.scratch/<feature-slug>/issues/<NN>-<slug>.md 下每个工单写一个文件，从 01 起按依赖顺序编号（阻塞项在前）。每个文件的 "Blocked by" 列出它所依赖的编号/标题。使用下面的每工单文件模板——一个工单一个文件，绝不用一个合并的大文件。ready-for-agent 分诊标签——这些工单按构造就是可被 agent 领取的。沿 前沿（frontier） 推进：任何其阻塞项全部完成的工单。对于纯线性链，这意味着自上而下。
不要关闭或修改任何父 issue。
要构建什么： 这个工单让哪一段端到端行为得以工作，从用户的视角出发——而不是一份逐层的实现清单。
阻塞于： 对这个工单构成门槛的工单的编号/标题，或 "无——可立即开始"。
状态： ready-for-agent
对 tracker 上父 issue 的引用（如果来源是一个已有的 issue，否则省略此节）。
这个工单让哪一段端到端行为得以工作，从用户的视角出发——而不是逐层实现。
无论哪种形式，都避免具体的文件路径或代码片段——它们过时得很快。例外：如果某个原型产出了一段比散文能更精确地编码某项决策的代码片段（状态机、reducer、schema、类型形状），就把它内联进去，并简要注明它来自一个原型。裁剪到富含决策的部分——不是一个能运行的演示，只保留重要的片段。
用 /implement 一次一个工单地沿前沿推进，在工单之间清空上下文。