القائمة
将计划、规格或当前对话拆成一组示踪弹式工单，每个工单声明自己的阻塞关系，并发布到已配置的跟踪器。本地文件用文字记录依赖，真实跟踪器使用原生阻塞链接。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态，或提到“design it twice”的场景。
运行交互式 QA session：用户通过对话报告 bugs 或 issues，agent 随后创建 GitHub issues；同时在后台探索 codebase，获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues，或提到“QA session”的场景。
通过用户访谈创建一份由微小 commits 组成的详细 refactor plan，并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC，或将 refactor 拆分为安全的增量步骤。
从当前对话中提取一份 DDD 风格的 ubiquitous language glossary，标出歧义并提出规范术语，保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language，或提到“domain model”或“DDD”的场景。
询问当前情境适合使用哪个 Skill 或工作流。本 Skill 是仓库内其他 Skills 的路由入口。
从用户指定的固定点（commit、branch、tag 或 merge-base）开始，从两个维度审查代码变更：Standards 检查代码是否遵守仓库记录的编码规范，Spec 检查实现是否符合原始 Issue、PRD 或规格。两个审查由并行子 Agent 分别完成，再并列汇报。适用于用户希望审查分支、PR、开发中的改动，或要求“审查自 X 以来的变更”时。
| name | to-tickets |
| description | 将计划、规格或当前对话拆成一组示踪弹式工单，每个工单声明自己的阻塞关系，并发布到已配置的跟踪器。本地文件用文字记录依赖，真实跟踪器使用原生阻塞链接。 |
| disable-model-invocation | true |
将计划、规格或对话拆成一组工单。每个工单都是一条示踪弹式纵向切片，并明确声明哪些其他工单会阻塞它。
Issue 跟踪器和分诊标签词汇应当已经配置。没有时运行 /setup-matt-pocock-skills。
使用当前对话中已经存在的内容。用户通过参数传入引用时，例如规格路径、Issue 编号或 URL，获取并阅读完整正文和评论。
此前尚未探索代码库时，先了解代码当前状态。工单标题和描述应使用项目领域术语表中的词汇，并遵守所涉及区域的 ADR。
寻找能够提前调整代码、使后续实现更容易的机会。“先让改动变得容易，再完成容易的改动。”
把工作拆成一组**示踪弹（tracer bullet）**工单。
为每个工单添加阻塞关系（blocking edges），列出开始该工单前必须完成的其他工单。没有阻塞项的工单可以立即开始。
大范围重构是纵向切片的例外。 **大范围重构（wide refactor）是一次机械性改动，例如重命名字段或改变共享符号的类型；它的影响半径（blast radius）会扩散到整个代码库，一次编辑就破坏成千上万个调用点，因此任何纵向切片都无法独立保持绿色。不要强行把它包装成示踪弹，而应使用扩展—收缩（expand–contract）**顺序。先扩展：在旧形式旁边加入新形式，保证现有行为不受破坏。随后按影响半径分批迁移调用点，例如按 package 或目录划分；每一批都是一个独立工单，并受“扩展”工单阻塞。旧形式仍然存在，因此 CI 应在各批次之间保持绿色。最后收缩：确认没有调用方继续使用旧形式后删除它；该工单被所有迁移批次阻塞。即使迁移批次单独也无法保持绿色时，仍保留这个顺序，但让它们共享一条集成分支，并共同阻塞最终的“集成并验证”工单；此时只在最终工单承诺恢复绿色。
将建议的拆分结果作为编号列表展示。每个工单包含：
询问用户：
持续修改，直到用户批准拆分方案。
发布已经批准的工单。具体方式由 /setup-matt-pocock-skills 配置的跟踪器决定。工单内容在两种方式中保持一致，只有阻塞关系的表现形式不同：
tickets.md，按依赖顺序排列全部工单，阻塞项在前。每个工单的 “Blocked by” 列出它依赖的工单标题。使用下方文件模板。ready-for-agent 分诊标签。工单从结构上已经可以直接交给 Agent。不要关闭或修改任何父 Issue。
用一行概括这些工单最终构建什么。存在源规格时，在这里引用。
处理前沿（frontier）：所有阻塞项均已完成的工单都属于当前前沿。对于纯线性链条，这意味着从上到下依次处理。
What to build: 从用户视角说明该工单打通的端到端行为，不要按层级罗列实现事项。
Blocked by: 列出阻塞该工单的其他工单标题，或写 “None — can start immediately”。
...
引用跟踪器中的父 Issue。源内容本身是已有 Issue 时添加，否则省略本节。
从用户视角说明该工单打通的端到端行为，不要按层级罗列实现事项。
无论采用哪种形式，都应避免具体文件路径或代码片段，因为它们很快会过时。例外：原型产生的代码片段能够比文字更准确地表达某项决策时，例如状态机、reducer、schema 或类型结构，可以内联该片段，并简短注明它来自原型。只保留承载决策的部分，不要放入一份完整可运行演示。
使用 /implement 每次处理前沿中的一个工单，并在工单之间清空上下文。