To Tickets

SkillFiles & storage

Break a plan, spec, or current conversation into a set of tracer-bullet-style tickets, each declaring its blocking edges, and publish them to the configured tracker, one file per ticket locally with edges in text form, or native blocking links on a real tracker.

Available today. Use it from your connected AI after setup.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Then ask your AI: use the To Tickets skill

What this skill tells your AI

The instructions your AI receives, as published by wenwuzhidao/mattpocock-skills-zh in skills/engineering/to-tickets/SKILL.md and read by ahel’s review.

把一个计划、规格说明或对话拆分成一组工单——曳光弹式的垂直切片,每张都声明阻塞它的那些工单。

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

流程

1. 收集上下文

从对话上下文中已有的任何东西出发。如果用户传入了一个引用(一个规格说明路径、一个 issue 编号或 URL)作为参数,就获取它并阅读其完整正文和评论。

2. 探索代码库(可选)

如果你还没探索过代码库,就探索一下以了解代码的当前状态。工单标题和描述应使用项目领域术语表的词汇,并尊重你所触及区域内的 ADR。

寻找预重构(prefactor)代码的机会,让实现更容易。"先让改动变容易,再做那个容易的改动。"

3. 起草垂直切片

把工作拆分成曳光弹式工单。

  • 每个切片穿过每一层(schema、API、UI、测试)切出一条狭窄但完整的路径——是纵向的,而不是某一层的横向切片
  • 一个完成的切片本身即可演示或可验证
  • 每个切片的大小以能装进单个全新上下文窗口为准
  • 任何预重构都应先做

给每张工单它的阻塞边——在它能开始之前必须完成的其他工单。没有阻塞项的工单可以立即开始。

宽重构是垂直切片的例外。 一次宽重构是一个机械性的改动——重命名一个列、重新给一个共享符号定类型——其波及半径扇形铺展到整个代码库,因此单次编辑一下子就破坏成千上万个调用点,没有任何垂直切片能落地变绿。不要硬把它塞进一颗曳光弹;用**扩展—收缩(expand–contract)**来编排它。先扩展:在旧形式旁边加上新形式,这样什么都不会坏。然后按波及半径的大小(每个包、每个目录)分批把调用点迁过去,每一批都是它自己的、被扩展所阻塞的工单,逐批保持 CI 变绿,因为旧形式依然存在。最后收缩:一旦没有调用方残留就删掉旧形式,放在一个被每一个迁移批次所阻塞的工单里。当连各批次也无法单独保持变绿时,保留这个序列但让它们共享一个集成分支,这些批次都阻塞一个最终的"集成并验证"工单——只在那里承诺变绿。

4. 盘问用户

把提议的拆分作为一个编号列表呈现。对每张工单,展示:

  • 标题:简短的描述性名称
  • Blocked by:哪些其他工单(如有)必须先完成
  • 它交付什么:这张工单让其工作起来的端到端行为

问用户:

  • 粒度感觉对吗?(太粗 / 太细)
  • 阻塞边正确吗——每张工单是否只依赖真正对它设闸的工单?
  • 有工单应该合并或进一步拆分吗?

反复迭代,直到用户批准这个拆分。

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

发布已批准的工单。如何发布取决于 /setup-matt-pocock-skills 所配置的跟踪器——两种方式下工单都是一样的,只有阻塞边的形态改变:

  • 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下每张工单写一个文件,按依赖顺序(阻塞项优先)从 01 编号。每个文件的"Blocked by"列出它所依赖的编号/标题。使用下面的每工单文件模板——每个文件一张工单,绝不是单个合并文件。
  • 一个真实的 issue 跟踪器(GitHub、Linear……) → 按依赖顺序(阻塞项优先)每张工单发布一个 issue,这样每张工单的阻塞边都能引用真实的标识符。使用平台的原生阻塞 / 子 issue 关系(如果它有的话);否则把每张工单的"Blocked by"设为那些阻塞它的 issue。除非另有指示,否则应用 ready-for-agent 分诊标签——这些工单按构造就是 agent 可认领的。

处理前沿:任何阻塞项全部完成的工单。对于纯线性链,这意味着自上而下。

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

—

What to build: the end-to-end behaviour this ticket makes work, from the user's perspective — not a layer-by-layer implementation list.

Blocked by: the numbers/titles of the tickets that gate this one, or "None — can start immediately".

Status: ready-for-agent

  • Acceptance criterion 1
  • Acceptance criterion 2

Parent

A reference to the parent issue on the tracker (if the source was an existing issue, otherwise omit this section).

What to build

The end-to-end behaviour this ticket makes work, from the user's perspective — not layer-by-layer implementation.

Acceptance criteria

  • Criterion 1
  • Criterion 2

Blocked by

  • A reference to each blocking ticket, or "None — can start immediately".

无论哪种形式,都避免使用具体的文件路径或代码片段——它们很快就会过时。例外:如果某个原型产出了一个比散文更精确地编码了某项决策的片段(状态机、reducer、schema、类型形态),就把它内联进来,并简短注明它来自一个原型。修剪到富含决策的部分——不是一个能运行的 demo,只是重要的那几处。

Signals

GitHub stars
23
Forks
4
Last commit
Aug 2026
Advanced
Item type
skill
Key
to-tickets-wenwuzhidao
Source
github.com/wenwuzhidao/mattpocock-skills-zh