to-tickets

转为工单

将计划、规格说明或对话拆分为一组工单：每个工单都是一个示踪弹式纵向切片，并注明会阻塞该工单的其他工单。

应该已经向你提供了问题跟踪系统和分诊标签词汇表。如果没有，请告知用户运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

基于对话中已有的上下文开展工作。如果用户通过参数传入了参考资料（规格说明路径、问题编号或 URL），请获取并阅读其完整正文和评论。

2. 探索代码库（视情况而定）

如果新接手的实现者不熟悉某个工单涉及的领域，或工单位于智能区边缘附近，就应进行探索；只有在你已经了解该领域且工单规模较小时，才跳过探索。探索的成果是每个工单都包含的概览（即其“概览”部分中的稳定锚点），这样新接手的 Agent 就不必重新探索——参见下方的智能区块。

了解代码的当前状态，使用项目领域词汇表中的术语，并遵循你正在处理领域的 ADR。

寻找通过预先调整代码来简化实现的机会。“先让改动变容易，再轻松地完成改动。”

3. 拆分垂直切片

将工作拆成示踪弹工单。

• 每个切片都要贯穿每一层（架构、API、UI、测试），覆盖一条狭窄但完整的路径：要做垂直切片，不要只切某一层做水平切片
• 每个完成的切片都能独立演示或验证
• 每个切片的规模要适合在一个全新上下文窗口的智能区内完成，而不是窗口宣称的原始上限（见下方的智能区说明）
• 任何预重构都应先完成

一个切片的规模应适合在一个全新会话的智能区内完成——大约是全新上下文窗口的前 100K–150K 个 token，在此期间 Agent 仍能敏锐地推理。超出这一区域后，Agent 会进入迟钝区：仍能执行任务，但会变得粗心、健忘，更容易出错。规划时应以智能区为准，绝不要以窗口宣称的上限为准。

全新会话在写下一行代码之前，要先付出加载上下文的成本。接手工单的 Agent 一开始一无所知：它需要阅读工单正文、上级规范和相关议题、该领域的 ADR 和术语表、编码规范，然后浏览代码库以熟悉情况。加载所用的 token 和实现所用的 token 一样，都会计入智能区——智能区是一份预算，而熟悉情况也要花费预算。因此，起草工单的首要任务是减少实现者必须加载的内容：在工单的 Orientation 部分预先提供稳定的定位锚点，并进行预重构，让变更更容易完成。只有无法预先提供的内容才会成为需要纳入预算的成本。

有效实现预算是智能区 − 加载上下文的开销。估算全新的实现者处理这张工单需要付出的加载成本（如果起草者已经探索过并留下锚点，成本较低；如果所在区域陌生或规模庞大，成本较高），再加上实现成本（阅读、编写和推理所需的开销），并将工单拆分，直到加载成本和实现成本的总和稳妥地处于智能区内。判断是否进入迟钝区时，应看总量（加载成本 + 工作量），而不只是工作量：变更本身很小的工单，如果所在区域需要大量加载，也可能超出预算。如有疑虑，就拆分。

为每张工单标明其阻塞关系：必须先完成哪些其他工单，它才能开始。没有阻塞项的工单可以立即开始。

宽范围重构是垂直切片的例外。宽范围重构指一项机械性变更（例如重命名列、修改共享符号的类型），其影响范围遍及整个代码库，因此一次编辑就会导致数千个调用点同时出错，无法通过任何垂直切片让代码保持绿色。不要强行将其拆成示踪弹；应按扩展–收缩的顺序安排。首先扩展：在旧形式旁边新增形式，确保不会破坏现有功能。然后分批迁移调用点，批次大小按影响范围确定（按包或目录划分）；每批作为一张独立工单，并依赖扩展工单。由于旧形式仍然存在，每批迁移完成后 CI 都能保持绿色。最后收缩：确认不再有调用方使用旧形式后，在一张依赖所有迁移批次的工单中删除旧形式。如果连分批迁移都无法单独保持绿色，就保留这一顺序，但让各批次共用一个集成分支，并将它们都设为最终集成与验证工单的阻塞项；只有到了这一步，才能承诺代码保持绿色。

4. 请用户评审

用编号列表展示拟议的拆分。对于每个任务，列出：

• 标题：简短的描述性名称
• 阻塞于：必须先完成的其他任务（如有）
• 交付内容：该任务实现的端到端行为

询问用户：

• 粒度是否合适？（太粗／太细）
• 每个任务是否都提供了新实施者所需的背景信息（在其 Orientation 部分中包含稳定锚点），让实施者无需重新探索？
• 每个任务是否都能轻松控制在智能区内，还是有任务会让其 Agent 进入迟钝区？
• 阻塞关系是否正确：每个任务是否只依赖确实会阻碍它的其他任务？
• 是否应该合并任何任务，或进一步拆分？

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

5. 将任务发布到已配置的跟踪系统

发布已批准的任务。具体方式取决于 /setup-matt-pocock-skills 配置的跟踪系统；任务内容相同，只是阻塞关系的表达方式不同：

• 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下为每个任务创建一个文件，按依赖顺序从 01 开始编号（先列阻塞项）。每个文件的“Blocked by”列出它依赖的编号／标题。使用下方的逐任务文件模板：每个文件一个任务，绝不合并到单个文件中。
• 真实的问题跟踪系统（GitHub、Linear 等） → 按依赖顺序（先列阻塞项）为每个任务发布一个问题，以便每个任务的阻塞关系都能引用真实标识符。如果平台提供原生阻塞关系，就使用该功能；否则，在每个任务的“Blocked by”中列出阻塞问题。如果来源是现有问题，则将每个任务设为其子问题（使用跟踪系统文档中的操作）。除非另有指示，否则添加 ready-for-agent 分类标签；这些任务设计上可由 Agent 直接领取。

处理前沿任务：其所有阻塞项均已完成的任务。对于纯线性依赖链，这意味着从上到下依次处理。

请勿关闭或修改任何父问题。

：

**构建内容：**该任务实现的端到端行为，从用户角度描述，而不是按层罗列实现步骤。

**背景信息：**新实施者在开始编写代码前应阅读的稳定锚点——ADR ID、术语表条目、模块／包名称、父问题。不要包含易变的文件路径或行号。减少加载上下文的成本，让实施者无需重新探索。

**规模：**背景信息前置（使用上述稳定锚点）；剩余的上下文加载与实现预计可控制在智能区内（整个会话约 100K–150K 个令牌）

**阻塞于：**阻塞此任务的任务编号／标题，或“无（可立即开始）”。

**状态：**ready-for-agent

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

父项

引用跟踪系统中的父问题（如果来源是现有问题；否则省略此部分）。

构建内容

该任务实现的端到端行为，从用户角度描述，而不是按层罗列实现步骤。

背景信息

新实施者在开始编写代码前应阅读的稳定锚点——ADR ID、术语表条目、模块／包名称、父问题。不要包含易变的文件路径或行号。减少加载上下文的成本，让实施者无需重新探索。

**规模：**背景信息前置（使用上述稳定锚点）；剩余的上下文加载与实现预计可控制在智能区内（整个会话约 100K–150K 个令牌）

验收标准

• 标准 1
• 标准 2

## 阻塞项

• 引用每个阻塞工单，或填写“无（可立即开始）”。如果阻塞项已设为原生边，则省略此部分。

无论采用哪种形式，都要避免易变引用——具体的文件路径、行号或 dist 内部信息：它们很快就会过时。建议使用稳定锚点：ADR ID、术语表词条、模块/包名称、父工单——这些内容经得起变更，能让新接手的实现人员准确找到所需内容。例外情况：如果原型生成的代码片段比文字说明更精确地表达了某项决策（状态机、reducer、架构），可以将其内联，并简要注明该片段来自原型。只保留有助于明确决策的部分，不要贴出完整的演示代码，只保留重要内容。

6. 语言

工单正文使用英文。工单是给 Agent 的工作项，不是主要内容——切勿在工单、子工单或后续工单中附加 ## Chinese Summary (non-authoritative) 注释。中文摘要仅适用于主要内容（为个人仓库发布的 to-spec 运行生成的规范工单），而不是每个工单或每次运行。