Back to Details

to-tickets

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

To Tickets

To Tickets

把 plan、spec 或 conversation 拆成一组 tickets：tracer-bullet vertical slices，每个 ticket 都声明 block 它的 tickets。
Issue tracker 和 triage label vocabulary 应该已经提供；如果没有，运行 
/setup-matt-pocock-skills
。
Split plans, specs, or conversations into a set of tickets: tracer-bullet vertical slices, where each ticket declares the tickets that block it.
The issue tracker and triage label vocabulary should already be provided; if not, run 
/setup-matt-pocock-skills
.

Process

Process

1. Gather context

1. Gather context

使用 conversation context 中已经存在的内容。如果用户把 reference（spec path、issue number 或 URL）作为参数传入，获取并完整读取其 body 和 comments。
Use content already present in the conversation context. If the user passes a reference (spec path, issue number, or URL) as a parameter, retrieve and fully read its body and comments.

2. Explore the codebase (optional)

2. Explore the codebase (optional)

如果还没有探索 codebase，先了解 code 当前状态。Ticket title 和 description 应使用项目 domain glossary vocabulary，并遵守相关 ADRs。
寻找 prefactor code、让 implementation 更容易的机会。“Make the change easy, then make the easy change.”
If you haven't explored the codebase yet, first understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary and comply with relevant ADRs.
Look for opportunities to refactor code in advance to make implementation easier. "Make the change easy, then make the easy change."

3. Draft vertical slices

3. Draft vertical slices

把工作拆成 tracer bullet tickets。
<vertical-slice-rules>
  • 每个 slice 都要贯穿每一层（schema、API、UI、tests）形成窄而完整的路径；必须是 vertical slice，不是某一层的 horizontal slice
  • 完成的 slice 可独立 demo 或 verify
  • 每个 slice 的大小必须能放进一个 fresh context window
  • 任何 prefactoring 都应先完成
</vertical-slice-rules>
为每个 ticket 给出 blocking edges：它开始前必须完成的其他 tickets。没有 blockers 的 ticket 可以立即开始。
Wide refactors 是 vertical slicing 的例外。 Wide refactor 是一个影响整个 codebase 的 mechanical change，例如 rename column 或 retype shared symbol；一次 edit 会破坏成千上万 call sites，无法让任何 vertical slice 独立保持 green。不要强行做成 tracer bullet；应按 expand–contract 排序。先 expand：在旧形式旁加入新形式，保持一切正常。再按 blast radius 分批迁移 call sites（按 package、directory 等），每批一个 ticket，并被 expand block；旧形式仍存在，因此 CI 每批都保持 green。最后 contract：在所有 migrate batches block 的 ticket 中删除旧形式。如果连单独 batches 也不能保持 green，仍保留这个 sequence，但让它们共享 integration branch，并全部 block 最后的 integrate-and-verify ticket；只在最后承诺 green。
Split the work into tracer bullet tickets.
<vertical-slice-rules>
  • Each slice must run through every layer (schema, API, UI, tests) to form a narrow yet complete path; it must be a vertical slice, not a horizontal slice of a single layer
  • Completed slices can be demoed or verified independently
  • Each slice must be small enough to fit into a fresh context window
  • Any pre-refactoring should be completed first
</vertical-slice-rules>
Provide blocking edges for each ticket: other tickets that must be completed before it can start. Tickets with no blockers can start immediately.
Wide refactors are an exception to vertical slicing. A wide refactor is a mechanical change that affects the entire codebase, such as renaming a column or retyping a shared symbol; a single edit can break thousands of call sites, making it impossible for any vertical slice to stay green independently. Do not force it into a tracer bullet; instead, follow the expand–contract sequence. First, expand: add the new form alongside the old one, keeping everything functional. Then migrate call sites in batches by blast radius (by package, directory, etc.), with each batch as a ticket blocked by the expand ticket; the old form remains, so CI stays green for each batch. Finally, contract: remove the old form in a ticket blocked by all migrate batches. Even if individual batches can't stay green, keep this sequence but have them share an integration branch, all blocking the final integrate-and-verify ticket; only commit to green at the end.

4. Quiz the user

4. Quiz the user

把建议的拆分作为 numbered list 展示。每个 ticket 包含：
  • Title：简短的描述性名称
  • Blocked by：必须先完成的其他 tickets（如有）
  • What it delivers：这个 ticket 打通的 end-to-end behaviour
询问用户：
  • Granularity 是否合适（太粗或太细）？
  • Blocking edges 是否正确，每个 ticket 是否只依赖真正 gate 它的 tickets？
  • 是否应继续合并或拆分 tickets？
迭代到用户批准拆分。
Present the proposed split as a numbered list. Each ticket includes:
  • Title: A short, descriptive name
  • Blocked by: Other tickets that must be completed first (if any)
  • What it delivers: The end-to-end behaviour this ticket enables
Ask the user:
  • Is the granularity appropriate (too coarse or too fine)?
  • Are the blocking edges correct, with each ticket only depending on the tickets that truly gate it?
  • Should tickets be merged or split further?
Iterate until the user approves the split.

5. Publish the tickets to the configured tracker

5. Publish the tickets to the configured tracker

发布已批准的 tickets。具体方式取决于 
/setup-matt-pocock-skills
配置的 tracker；tickets 相同，只有 blocking edges 的形状不同：
  • Local files → 在 
    .scratch/<feature-slug>/issues/<NN>-<slug>.md
    下每 ticket 写一个文件，按 dependency order（blockers 优先）从 
    01
    编号。每个文件的 “Blocked by” 列出它依赖的 number/title。使用下面的 per-ticket template；每个文件只放一个 ticket，绝不要写成一个 combined file。
  • 真实 issue tracker（GitHub、Linear 等） → 按 dependency order（blockers 优先）每 ticket 发布一个 issue，让 blocking edges 能引用真实 identifiers。平台支持时使用 native blocking/sub-issue relationship，否则把 blocking issues 写进每个 ticket 的 “Blocked by”。除非另有指示，应用 
    ready-for-agent
    triage label；这些 tickets 天生可被 agent 领取。
处理 frontier：所有 blockers 都完成的 tickets。纯 linear chain 就是从上到下。
不要 close 或 modify 任何 parent issue。
<local-ticket-template>
Publish the approved tickets. The specific method depends on the tracker configured via 
/setup-matt-pocock-skills
; the tickets are the same, only the format of blocking edges differs:
  • Local files → Write one file per ticket under 
    .scratch/<feature-slug>/issues/<NN>-<slug>.md
    , numbered starting from 
    01
    in dependency order (blockers first). Each file's "Blocked by" section lists the numbers/titles of the tickets it depends on. Use the per-ticket template below; never put multiple tickets in a single combined file.
  • Real issue trackers (GitHub, Linear, etc.) → Publish one issue per ticket in dependency order (blockers first), allowing blocking edges to reference real identifiers. Use native blocking/sub-issue relationships if the platform supports them; otherwise, list blocking issues in each ticket's "Blocked by" section. Apply the 
    ready-for-agent
    triage label unless instructed otherwise; these tickets are inherently ready for agents to pick up.
Handle the frontier: tickets where all blockers are completed. A pure linear chain is processed top to bottom.
Do not close or modify any parent issues.
<local-ticket-template>

<NN> — <Ticket title>

<NN> — <Ticket title>

What to build: 这个 ticket 从用户视角打通的 end-to-end behaviour，而不是逐层 implementation list。
Blocked by: gate 这个 ticket 的 numbers/titles，或 “None — can start immediately”。
Status: ready-for-agent
  • Acceptance criterion 1
  • Acceptance criterion 2
</local-ticket-template> <issue-template>
What to build: The end-to-end behaviour this ticket enables from the user's perspective, not a layer-by-layer implementation list.
Blocked by: Numbers/titles of tickets that gate this one, or "None — can start immediately".
Status: ready-for-agent
  • Acceptance criterion 1
  • Acceptance criterion 2
</local-ticket-template> <issue-template>

Parent

Parent

Tracker 上 parent issue 的 reference（如果来源是 existing issue；否则省略本 section）。
Reference to the parent issue on the tracker (omit this section if the source is not an existing issue).

What to build

What to build

这个 ticket 从用户视角打通的 end-to-end behaviour，而不是逐层 implementation。
The end-to-end behaviour this ticket enables from the user's perspective, not a layer-by-layer implementation.

Acceptance criteria

Acceptance criteria

  • Criterion 1
  • Criterion 2
  • Criterion 1
  • Criterion 2

Blocked by

Blocked by

  • 每个 blocking ticket 的 reference，或 “None — can start immediately”。
</issue-template>
无论哪种形式，都避免具体 file paths 或 code snippets；它们很快会过时。例外：如果 prototype 产出的 snippet 比 prose 更精确地编码了 decision（state machine、reducer、schema、type shape），可以内联，并简短说明来自 prototype。只保留 decision-rich parts，不要放 working demo。
使用 
/implement
一次处理 frontier 上的一个 ticket，并在 tickets 之间清空 context。
  • Reference to each blocking ticket, or "None — can start immediately".
</issue-template>
Regardless of the format, avoid specific file paths or code snippets; they become outdated quickly. Exception: If a snippet from a prototype encodes a decision (state machine, reducer, schema, type shape) more precisely than prose, it can be inline with a brief note indicating it comes from the prototype. Only keep decision-rich parts, not working demos.
Use 
/implement
to handle one ticket on the frontier at a time, and clear the context between tickets.