Back to Details

to-tickets

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

To Tickets

生成任务工单

Break a plan, spec, or conversation into a set of tickets — tracer-bullet vertical slices, each declaring the tickets that block it.
The issue tracker and triage label vocabulary should have been provided to you — run 
/setup-matt-pocock-skills
if not.
将计划、规格说明或对话拆分为一组任务工单——即tracer-bullet垂直切片，每个工单需声明其依赖的前置工单（即阻塞它的工单）。
任务追踪系统和分类标签词汇表应已提供给你——如果未提供，请运行
/setup-matt-pocock-skills
命令。

Process

流程

1. Gather context

1. 收集上下文

Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.
基于对话上下文已有的信息开展工作。如果用户传入了参考内容（如规格说明路径、工单编号或URL）作为参数，请获取并阅读其完整内容及评论。

2. Explore the codebase (optional)

2. 探索代码库（可选）

If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
如果你尚未探索过代码库，请先进行探索以了解代码的当前状态。工单标题和描述应使用项目领域术语表中的词汇，并遵循你所涉及领域的ADRs（架构决策记录）。
寻找预重构代码的机会，以便简化后续实现。遵循原则：‘先让变更变得容易，再完成容易的变更。’

3. Draft vertical slices

3. 草拟垂直切片

Break the work into tracer bullet tickets.
<vertical-slice-rules>
  • Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, NOT a horizontal slice of one layer
  • A completed slice is demoable or verifiable on its own
  • Each slice is sized to fit in a single fresh context window
  • Any prefactoring should be done first
</vertical-slice-rules>
Give each ticket its blocking edges — the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
Wide refactors are the exception to vertical slicing. A wide refactor is one mechanical change — rename a column, retype a shared symbol — whose blast radius fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as expand–contract. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket — green is promised only there.
将工作拆分为tracer bullet工单。
<vertical-slice-rules>
  • 每个切片需覆盖从架构层、API层、UI层到测试层的完整窄路径——是垂直切片，而非单一层面的水平切片
  • 完成后的切片可独立演示或验证
  • 每个切片的规模应适配单次全新上下文窗口的处理能力
  • 任何预重构操作都应优先执行
</vertical-slice-rules>
为每个工单标注阻塞关系——即必须先完成的其他工单。无阻塞的工单可立即启动。
大范围重构是垂直切片规则的例外情况。所谓大范围重构是指一种机械性变更——例如重命名列、重新定义共享符号——其影响范围覆盖整个代码库，单次修改会同时破坏数千个调用点，无法通过垂直切片实现绿色构建。不要强行将其纳入tracer bullet模式，而是采用扩展-收缩的流程：首先是扩展阶段：在原有实现旁添加新实现，确保现有功能不受影响。然后按照影响范围（按包、按目录）分批迁移调用点，每批迁移作为一个独立工单，依赖于扩展阶段的工单完成，由于原有实现仍存在，每批迁移都能保持CI构建绿色。最后是收缩阶段：当所有调用点都完成迁移后，删除原有实现，该工单依赖于所有迁移批的工单完成。如果单批迁移也无法保持绿色构建，仍需遵循该流程，但可将这些批处理工单合并到一个集成分支中，所有批处理工单都依赖于最终的集成验证工单——仅在该工单中保证绿色构建。

4. Quiz the user

4. 询问用户意见

Present the proposed breakdown as a numbered list. For each ticket, show:
  • Title: short descriptive name
  • Blocked by: which other tickets (if any) must complete first
  • What it delivers: the end-to-end behaviour this ticket makes work
Ask the user:
  • Does the granularity feel right? (too coarse / too fine)
  • Are the blocking edges correct — does each ticket only depend on tickets that genuinely gate it?
  • Should any tickets be merged or split further?
Iterate until the user approves the breakdown.
将拟议的工单拆分方案以编号列表形式呈现。每个工单需展示：
  • 标题：简短描述性名称
  • 依赖阻塞：需先完成的其他工单（如有）
  • 交付内容：该工单实现的端到端功能
询问用户：
  • 拆分粒度是否合适？（过粗/过细）
  • 阻塞关系是否正确——每个工单是否仅依赖于真正制约它的工单？
  • 是否需要合并或进一步拆分某些工单？
反复迭代直至用户认可该拆分方案。

5. Publish the tickets to the configured tracker

5. 将工单发布至已配置的追踪系统

Publish the approved tickets. How depends on the tracker 
/setup-matt-pocock-skills
configured — the tickets are the same either way, only the shape of the blocking edges changes:
  • Local files → write one 
    tickets.md
    in the repo root, all tickets in dependency order (blockers first), each with its "Blocked by" listing the titles it depends on. Use the file template below.
  • A real issue tracker (GitHub, Linear, …) → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the 
    ready-for-agent
    triage label unless instructed otherwise — the tickets are agent-grabbable by construction.
Do NOT close or modify any parent issue.
<tickets-file-template>
发布已获批准的工单。发布方式取决于
/setup-matt-pocock-skills
配置的追踪系统——工单内容一致，仅阻塞关系的呈现形式不同：
  • 本地文件→在仓库根目录下创建
    tickets.md
    文件，所有工单按依赖顺序排列（阻塞工单在前），每个工单的‘依赖阻塞’部分列出其依赖的工单标题。使用下方的文件模板。
  • 真实任务追踪系统（GitHub、Linear等）→按依赖顺序（阻塞工单在前）为每个工单创建一个议题，以便每个工单的阻塞关系可引用真实的标识符。如果平台支持原生阻塞/子议题关系，请使用该关系；否则在每个工单的‘依赖阻塞’部分列出阻塞议题。除非另有指示，否则添加
    ready-for-agent
    分类标签——这些工单本质上是可由Agent处理的。
请勿关闭或修改任何父议题。
<tickets-file-template>

Tickets: <short name of the work>

任务工单：<工作简短名称>

A one-line summary of what these tickets build. Reference the source spec if there is one.
Work the frontier: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
这些工单所构建内容的单行摘要。如有源规格说明，请引用。
优先处理前沿工单：即所有依赖阻塞工单已完成的工单。对于纯线性依赖链，意味着从上到下依次处理。

<Ticket title>

<工单标题>

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 titles of the tickets that gate this one, or "None — can start immediately".
  • Acceptance criterion 1
  • Acceptance criterion 2
**构建内容：**从用户视角出发，该工单实现的端到端功能——而非逐层实现清单。
**依赖阻塞：**制约该工单的工单标题，或‘无——可立即启动’。
  • 验收标准1
  • 验收标准2

<Ticket title>

<工单标题>

...
</tickets-file-template> <issue-template>
...
</tickets-file-template> <issue-template>

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
  • 标准1
  • 标准2

Blocked by

依赖阻塞

  • A reference to each blocking ticket, or "None — can start immediately".
</issue-template>
In either form, avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
Work the frontier one ticket at a time with 
/implement
, clearing context between tickets. </content>
  • 每个阻塞工单的引用，或‘无——可立即启动’。
</issue-template>
无论采用哪种形式，都应避免使用具体文件路径或代码片段——这些内容会很快过时。例外情况：如果原型生成的代码片段比文字更精准地体现了决策（如状态机、 reducer、 schema、类型结构），可嵌入该片段并简要说明其来自原型。仅保留富含决策信息的部分——无需完整可运行演示，只保留关键内容。
使用
/implement
命令逐个处理前沿工单，处理每个工单前清空上下文。