to-tickets

name	to-tickets
description	将计划、规格或当前对话拆成一组示踪弹式工单，每个工单声明自己的阻塞关系，并发布到已配置的跟踪器。本地文件用文字记录依赖，真实跟踪器使用原生阻塞链接。
disable-model-invocation	true

转换为工单

将计划、规格或对话拆成一组工单。每个工单都是一条示踪弹式纵向切片，并明确声明哪些其他工单会阻塞它。

Issue 跟踪器和分诊标签词汇应当已经配置。没有时运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

使用当前对话中已经存在的内容。用户通过参数传入引用时，例如规格路径、Issue 编号或 URL，获取并阅读完整正文和评论。

2. 探索代码库（可选）

此前尚未探索代码库时，先了解代码当前状态。工单标题和描述应使用项目领域术语表中的词汇，并遵守所涉及区域的 ADR。

寻找能够提前调整代码、使后续实现更容易的机会。“先让改动变得容易，再完成容易的改动。”

3. 起草纵向切片

把工作拆成一组**示踪弹（tracer bullet）**工单。

• 每个切片都要沿所有相关层级切出一条狭窄但完整的路径，包括 schema、API、UI 和测试。它必须是纵向切片，不能只横向覆盖某一层。
• 每个完成的切片都能独立演示或验证。
• 每个切片的规模都必须适合在一个全新的上下文窗口中完成。
• 所有预先重构（prefactoring）都应先完成。

为每个工单添加阻塞关系（blocking edges），列出开始该工单前必须完成的其他工单。没有阻塞项的工单可以立即开始。

大范围重构是纵向切片的例外。 **大范围重构（wide refactor）是一次机械性改动，例如重命名字段或改变共享符号的类型；它的影响半径（blast radius）会扩散到整个代码库，一次编辑就破坏成千上万个调用点，因此任何纵向切片都无法独立保持绿色。不要强行把它包装成示踪弹，而应使用扩展—收缩（expand–contract）**顺序。先扩展：在旧形式旁边加入新形式，保证现有行为不受破坏。随后按影响半径分批迁移调用点，例如按 package 或目录划分；每一批都是一个独立工单，并受“扩展”工单阻塞。旧形式仍然存在，因此 CI 应在各批次之间保持绿色。最后收缩：确认没有调用方继续使用旧形式后删除它；该工单被所有迁移批次阻塞。即使迁移批次单独也无法保持绿色时，仍保留这个顺序，但让它们共享一条集成分支，并共同阻塞最终的“集成并验证”工单；此时只在最终工单承诺恢复绿色。

4. 向用户核对

将建议的拆分结果作为编号列表展示。每个工单包含：

• Title：简短、具有描述性的名称
• Blocked by：开始前必须完成哪些其他工单，如果没有则说明无
• What it delivers：该工单最终打通的端到端行为

询问用户：

• 粒度是否合适，是过粗还是过细？
• 阻塞关系是否正确，每个工单是否只依赖真正会卡住它的工单？
• 是否需要合并某些工单，或进一步拆分？

持续修改，直到用户批准拆分方案。

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

发布已经批准的工单。具体方式由 /setup-matt-pocock-skills 配置的跟踪器决定。工单内容在两种方式中保持一致，只有阻塞关系的表现形式不同：

• 本地文件 → 在仓库根目录写入一份 tickets.md，按依赖顺序排列全部工单，阻塞项在前。每个工单的 “Blocked by” 列出它依赖的工单标题。使用下方文件模板。
• 真实 Issue 跟踪器（GitHub、Linear 等） → 按依赖顺序为每个工单发布一个 Issue，先发布阻塞项，使后续工单可以引用真实标识符。平台支持原生阻塞关系或子 Issue 时，优先使用原生功能；否则在每个工单的 “Blocked by” 中列出对应 Issue。除非用户另有要求，添加 ready-for-agent 分诊标签。工单从结构上已经可以直接交给 Agent。

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

Tickets: <工作的简短名称>

用一行概括这些工单最终构建什么。存在源规格时，在这里引用。

处理前沿（frontier）：所有阻塞项均已完成的工单都属于当前前沿。对于纯线性链条，这意味着从上到下依次处理。

<工单标题>

What to build: 从用户视角说明该工单打通的端到端行为，不要按层级罗列实现事项。

Blocked by: 列出阻塞该工单的其他工单标题，或写 “None — can start immediately”。

• 验收标准 1
• 验收标准 2

<工单标题>

...

Parent

引用跟踪器中的父 Issue。源内容本身是已有 Issue 时添加，否则省略本节。

What to build

从用户视角说明该工单打通的端到端行为，不要按层级罗列实现事项。

Acceptance criteria

• 标准 1
• 标准 2

Blocked by

• 引用每个阻塞工单，或写 “None — can start immediately”。

无论采用哪种形式，都应避免具体文件路径或代码片段，因为它们很快会过时。例外：原型产生的代码片段能够比文字更准确地表达某项决策时，例如状态机、reducer、schema 或类型结构，可以内联该片段，并简短注明它来自原型。只保留承载决策的部分，不要放入一份完整可运行演示。

使用 /implement 每次处理前沿中的一个工单，并在工单之间清空上下文。