/to-tickets 技能

它的作用

to-tickets 取一个计划、 spec，或你当前所在的对话，并把它们拆成一组 tickets 在你的 issue 追踪器上。每个任务声明它的 阻塞边界: the other tickets that have to finish before it can start.

每个任务都是一个 曳光弹: a narrow but complete path through every layer of the change (schema, API, UI, tests) that you can demo on its own as soon as it lands. This is what makes the skill different from the obvious way to split work, which is to cut one layer at a time and integrate at the end. It also sizes each ticket to fit in a single fresh 上下文窗口, because a 会话 that has never seen your spec will pick the ticket up.

何时使用

你通过输入 /to-tickets. The agent 不会自动调用它。

那些 to-tickets 产出的天生为智能体就绪。不要运行 triage over them. Triage is for work that arrived from someone else.

前置条件

to-tickets 发布到追踪器，所以 setup-matt-pocock-skills 必须为这个仓库配置一个，连同分流标签词汇。两种都可以：GitHub 或 Linear 这样的真实追踪器，或 .scratch/, which work with no extra setup.

曳光弹，不是分层

A horizontal 切片只发布改动的一层。在所有层都落地之前什么都不工作，而且每个任务的验收标准必须伸进另一个任务拥有的工作。 vertical slice (the tracer bullet) ships one thin path through all the layers at once, so it is verifiable alone and owns everything it grades.

This is the rule people break most often. One team ran a 26-ticket stack sliced by layer (corpus, producer, aggregator, selector) and got roughly twenty agent runs per closed ticket, about three quarters of them rework. Their own post-mortem traced every failure class back to the horizontal slicing rather than to the implementations.

在发布任何内容之前有两件事发生。 to-tickets looks for prefactoring (the principle "make the change easy, then make the easy change") and orders that work first. Then it presents the breakdown as a numbered list and quizzes you on it: is the granularity right, are the blocking edges real, should anything merge or split. Nothing reaches the tracker until you approve, and that quiz is the place to push back.

阻塞边界

The edges are the point of the artifact. They work in two ways, depending on the tracker:

The edges live in the ticket either way. The tracker only decides whether anything can act on them in parallel. to-tickets produces the artifact; running it (one session at a time, or a fleet) is your job, not the skill's.

宽重构例外

有一种形态破坏了曳光弹规则。 宽重构 is a single mechanical change (rename a column, retype a shared symbol) whose 爆炸半径 covers the whole codebase. One edit breaks thousands of call sites, so no vertical slice can land green.

to-tickets 把那个排序为 扩展-收缩 改为：

• 展开: add the new form beside the old, so nothing breaks.
• 迁移: move call sites over in batches sized by blast radius (per package, per directory), one ticket per batch, each blocked by the expand. CI stays green because the old form still exists.
• 契约: delete the old form once no caller remains, in a ticket blocked by every migrate batch.

Where even the batches can't stay green alone, they share an integration branch and all block a final integrate-and-verify ticket. CI only has to be green at that ticket.

常见问题

它为三行的改动产出了十二个任务。 Over-decomposition is the most reported problem with this skill, and many users see it. The model defaults to atomic units and loses the grouping that would make them meaningful. The quiz step is where you fix this. Ask it to merge tickets, and it will. There is also a lower limit. If the whole change fits in one 上下文窗口，你根本不需要这个技能。直接使用 implement.

The tickets came out one per layer: all the schema in one, all the API in another. This is the failure the vertical-slice rule is written against, and the skill still produces it sometimes. Catch it at the quiz step by asking one question per ticket: what can I demo when this is done? A ticket with no answer is a horizontal slice. Some people add a "demo path" line to each ticket for this reason, and report that it pushes the model toward vertical slices.

在 GitHub 上，任务没有被创建为规格 issue 的子 issue。 This was reported across a dozen runs and several models, 在 issue #554 中阐述得最充分. Fixed: to-tickets now makes each ticket a sub-issue of its source issue, and the GitHub tracker template gives the command (gh issue create --parent <n>, gh 2.94+). Re-run setup-matt-pocock-skills to refresh an older docs/agents/issue-tracker.md.

「Blocked by」被写进了 issue 正文，而不是真正的阻塞链接。 This is the same kind of problem, 在 issue #513 中被报告, where the agent even stated that GitHub has no native blocking relationship at all. It does: gh issue create --blocked-by 12,15. Because the skill publishes blockers first, their numbers are always available at creation time. The body text is meant to be the fallback for trackers with no native edge, not the default. The ticket template now omits ## Blocked by when the edges are native.

本地任务去哪了？v1.1 的说明提到一个根级 tickets.md. They did, and that was a bug. A single shared file also caused race conditions when parallel agents wrote to it. Local mode now writes one file per ticket under .scratch/<feature-slug>/issues/<NN>-<slug>.md，按依赖顺序，与本地追踪器模板已描述的布局一致。这个 NN 前缀是真实的任务 ID，所以 /implement 03 能用的方案，而不是重新输入长标题。

它读我的规格说明时一直截断。 A very large spec can outgrow what a tracker issue serves back cleanly. There is no local copy to fall back on, so the agent spends 次工具调用 fetching chunks again and never reaches the end. Don't clear or compact between /to-spec and /to-tickets. Run them in the same context window and the agent never has to fetch the spec back.

The acceptance criteria graded nothing: some passed before any work was done. The template asks for criteria and says nothing about whether they can fail, so this happens. Three shapes recur: a criterion already true at the base commit, a criterion that only work in another ticket can satisfy, and one that restates the request rather than deriving from the artifact. Vertical slicing prevents most of it, because a slice that delivers new behaviour fails at the base commit by construction. The check is still worth doing by hand. For each criterion, name the observation that would show it false, and confirm it fails at the commit the implementer starts from.

任务已发布。我到底怎么运行它们？ The skill stops at the artifact, and there is no auto-dispatch mode. Dispatch is manual: look at the board, count the tickets with no open blockers, and open that many agent sessions. Give each ticket a fresh context, and clear between them. implement does not reliably close or check off the ticket when it finishes, on GitHub or in local markdown, so you update the ticket's state yourself.

做到以下就算成功

• Every ticket has an answer to "what can I demo when this is done?", and the answer is behaviour, not a layer.
• 列表编号返回给你，每项带「Blocked by」行，在任何内容发布之前。
• 最上面的任务没有阻塞项，可以立即开始。
• 任务正文里没有文件路径或行号，除了原型产出的片段。
• 每个任务读起来都像全新会话能在你不在场时完成的东西。
• 预重构（如果发现任何）排在顺序最前，而不是混进功能任务里。

在流程中的位置

to-tickets 是主构建链上的一步：

grill-with-docs → to-spec → to-tickets → implement → code-review → retro

上游是 to-spec, which hands it a settled spec to slice against. Keep both in one context window, with no clear between them. Downstream is implement，它每个全新会话构建一个任务，驱动 tdd 用于测试，并以 code-review. implement-spec is the other way down. It reads the same blocking edges as a task graph and builds every ready ticket in parallel on one integration branch. When you're unsure which skill or flow fits, ask-matt 为你指路。