mcpField
T
to-tickets

to-tickets

github.com/mattpocockAgent 工作流305.7k731.4k 次安装1 天前更新
代码仓库

关于 to-tickets

to-tickets 是一项 Agent 技能，可将计划、规格或对话拆分为带依赖关系的任务。它按可独立验证的纵向切片组织工作，并将获批任务发布到已配置的跟踪器。

主要功能

  1. 01按纵向切片拆分工作
  2. 02定义任务阻塞关系
  3. 03以扩展—收缩处理大规模重构
  4. 04与用户确认拆分方案
  5. 05按依赖顺序发布任务

适用场景

  1. 01将规格转换为实施任务
  2. 02明确阻塞关系并安排工作
  3. 03分阶段规划大型重构

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mattpocock/skills --skill to-tickets

安装后在 Claude Code 中输入/to-tickets确认已加载。

附带文件agents/openai.yaml

详细介绍

拆分为工单

将计划、规格说明或对话拆分为一组工单：每个工单都是一个探针式（tracer bullet）纵向切片，并声明会阻塞它的其他工单。

问题追踪器和分流标签词汇应已提供给你。如果没有，请告知用户运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

基于对话上下文中已有的内容开展工作。如果用户以参数形式传入引用（规格路径、Issue 编号或 URL），请获取并阅读其完整正文和评论。

2. 探索代码库（可选）

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

寻找可以先对代码进行预重构（prefactor）的机会，使实现更容易。"先让变更变得容易，再做那个容易的变更。"

3. 起草纵向切片

将工作拆分为探针式工单。

  • 每个切片贯穿每一层（schema、API、UI、测试）切出一条窄但完整的路径：纵向，而非只针对单一层的横向切片
  • 完成后的切片可以独立演示或验证
  • 每个切片的大小应能放入单个全新的上下文窗口中
  • 任何预重构都应先完成

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

大范围重构是纵向切片的例外。 大范围重构是指一次机械性变更（如重命名列、更改共享符号的类型），其影响范围遍及整个代码库，单次修改就会导致数千处调用点同时出错，因此没有任何纵向切片能够独立保持绿色构建。不要强行将其拆成探针式工单，而应按**扩展–收缩（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。

：<工单标题>

构建内容： 本工单实现的端到端行为，从用户视角描述，而不是逐层的实现清单。

被阻塞于： 阻塞本工单的工单编号或标题，或“无（可立即开始）”。

状态： ready-for-agent

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

父 Issue

对跟踪系统中父 Issue 的引用（若来源是一个已有 Issue；否则省略此部分）。

构建内容

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

验收标准

  • 标准 1
  • 标准 2

被阻塞于

  • 对每个阻塞工单的引用，或“无（可立即开始）”。如果阻塞关系已通过原生关联设置，则省略此部分。

无论采用哪种形式，都应避免具体的文件路径或代码片段，因为它们很快会过时。例外：如果原型产生的代码片段比文字更精确地表达了某项决策（如状态机、reducer、schema、类型结构），则将其内联，并简要说明它来自原型。只保留包含关键决策的部分，而不是完整的可运行演示，只保留重要的部分。

评论

支持 Markdown