luestr/skills/to-tickets

拆解为工单

把计划、规格说明（spec）或对话拆成一组工单：曳光弹式的垂直切片，每个工单声明哪些工单阻塞它。

issue 跟踪器和分诊标签词汇应该已经提供给你。如果没有，让用户运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

基于对话上下文中已有的内容工作。如果用户把引用（规格路径、issue 编号或 URL）作为参数传入，就获取它并完整读取其正文和评论。

2. 探索代码库（可选）

如果还没有探索过代码库，就去了解代码的当前状态。工单标题和描述应使用项目的领域术语表词汇，并遵守你所触及区域的 ADR。

寻找预先重构（prefactor）代码、让实现更容易的机会。“先让改动变简单，再做简单的改动。”

3. 草拟垂直切片

把工作拆成曳光弹工单。

<vertical-slice-rules>

• 每个切片穿过每一层（schema、API、UI、测试）切出一条狭窄但完整的路径：是垂直切片，而不是某一层的水平切片
• 完成的切片本身可演示或可验证
• 每个切片的大小应能放进一个全新的上下文窗口
• 任何预先重构都应先做

</vertical-slice-rules>

给每个工单标明它的阻塞关系（blocking edges）：必须在其之前完成的其他工单。没有阻塞项的工单可以立即开始。

大范围重构是垂直切片的例外。 大范围重构（wide refactor）是一次机械性改动（重命名一列、修改一个共享符号的类型），它的影响半径横扫整个代码库，一次编辑同时破坏成千上万个调用点，因此没有任何垂直切片能保持绿灯落地。不要硬把它塞进曳光弹；按扩展–收缩（expand–contract）的顺序做。先扩展：在旧形式旁边加上新形式，让任何东西都不被破坏。再按影响半径分批（按包、按目录）迁移调用点，每一批都是自己的工单，被扩展工单阻塞；因为旧形式仍然存在，批次之间 CI 保持绿灯。最后收缩：在没有任何调用者之后删除旧形式，放在一个被所有迁移批次阻塞的工单里。如果连各批次单独也无法保持绿灯，就保留这个顺序，但让它们共用一个集成分支，并让这些迁移批次全部阻塞一张最终的“集成并验证”工单；只有在那里才承诺绿灯。

4. 向用户提问

把提议的拆解结果以编号列表呈现。每个工单展示：

• 标题：简短、描述性的名称
• 阻塞项：必须先完成的其他工单（如有）
• 交付内容：此工单实现的端到端行为

询问用户：

• 粒度合适吗？（太粗/太细）
• 阻塞关系正确吗：每个工单是否只依赖真正构成阻塞的工单？
• 有工单需要合并或进一步拆分吗？

反复迭代，直到用户批准拆解方案。

5. 把工单发布到已配置的跟踪器

发布获批的工单。如何发布取决于 /setup-matt-pocock-skills 配置的跟踪器；两种方式下工单本身相同，只是阻塞关系的形态不同：

• 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下为每个工单写一个文件，从 01 开始按依赖顺序编号（阻塞项在前）。每个文件的“阻塞项”列出它依赖的编号/标题。使用下面的单工单文件模板：一个工单一个文件，绝不合并成单个文件。
• 真实的 issue 跟踪器（GitHub、Linear、……） → 按依赖顺序（阻塞项在前）每个工单发布一个 issue，这样每个工单的阻塞关系都能引用真实的标识符。平台有原生阻塞关系就用它；否则把每个工单的“阻塞项”设为其阻塞 issue。如果来源是一个已有 issue，让每个工单成为它的子 issue（跟踪器文档中的操作）。除非另有指示，应用 ready-for-agent 分诊标签；按设计，这些工单可由 Agent 直接抓取。

按前沿推进：即所有阻塞项都已完成的工单。对于纯线性链，这意味着从上到下。

不要关闭或修改任何父 issue。

<local-ticket-template>

<NN>：<工单标题>

要构建什么： 此工单实现的端到端行为——从用户视角描述，而不是逐层实现的清单。

阻塞项： 阻塞此工单的工单编号/标题，或“无（可立即开始）”。

状态： ready-for-agent

• [ ] 验收标准 1
• [ ] 验收标准 2

</local-ticket-template>

<issue-template>

父 issue

跟踪器上父 issue 的引用（如果来源是一个已有 issue；否则省略本节）。

要构建什么

此工单实现的端到端行为——从用户视角描述，而不是逐层实现。

验收标准

• [ ] 标准 1
• [ ] 标准 2

阻塞项

• 对每个阻塞工单的引用，或“无（可立即开始）”。当阻塞项以原生关系设置时，省略本节。

</issue-template>

无论采用哪种形式，都要避免具体的文件路径或代码片段：它们很快会过期。例外：如果原型产出的片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型形态），就把它内联进来，并简要说明它来自原型。只保留决策密集的部分，不是可运行的演示，只留关键内容。