Back to Details

to-tickets

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- markdownlint-disable MD013 MD033 -->
<!-- markdownlint-disable MD013 MD033 -->

To Tickets

生成工单

Break a plan, spec, or the current conversation into a set of tickets — tracer-bullet vertical slices, each declaring the tickets that block it — and publish them to the tracker.
The tracker and label vocabulary come from 
docs/agents/issue-tracker.md
; run 
bootstrap
if missing. Titles and bodies use the glossary in 
docs/agents/domain.md
.
将计划、规格说明或当前对话拆分为一组工单——追踪式垂直切片，每个工单明确指出其阻塞的前置工单——并发布至任务追踪器。
任务追踪器和标签词汇来自
docs/agents/issue-tracker.md
；若缺失请运行
bootstrap
初始化。工单标题和内容使用
docs/agents/domain.md
中的术语表。

Process

流程

1. Gather context

1. 收集上下文

Work from the conversation. If the user passes a reference (spec path, issue number/URL), fetch its full body and comments. If a meta issue already exists for this work (the strategic spec/PRD), fetch it — the tactical tickets you create will set their parent to it.
从对话内容入手。如果用户提供了参考（规格说明路径、议题编号/URL），获取其完整内容和评论。如果已存在针对此项工作的meta issue（战略规格说明/PRD），获取该议题——你创建的战术工单会将其设为父议题。

2. Explore the codebase (optional)

2. 探索代码库（可选）

If not already done, explore to understand current state. Look for prefactoring opportunities: "make the change easy, then make the easy change."
如果尚未完成，探索代码库以了解当前状态。寻找预重构机会："先让变更变得容易，再完成这个容易的变更。"

3. Draft vertical slices

3. 草拟垂直切片

<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 fits in a single fresh context window.
  • Each slice stays on the minimalism ladder (
    docs/agents/workflow.md
    ): no speculative abstractions, no scaffolding "for later", the minimum seam that proves the path.
</vertical-slice-rules>
Give each ticket its blocking edges — the tickets that must complete before it can start. A ticket with no blockers can start immediately.
Wide refactors are the exception. A mechanical change whose blast radius fans across the whole codebase can't be a single tracer bullet. Sequence it expand–contract: first expand (add the new form beside the old so nothing breaks), then migrate call sites in batches sized by blast radius (per package / directory), each batch a ticket blocked by the expand, keeping CI green; a final contract ticket removes the old form once all batches land.
<vertical-slice-rules>
  • 每个切片都要贯穿所有层级（schema、API、UI、测试），切出一条狭窄但完整的路径——是垂直切片，而非单一层级的水平切片。
  • 完成后的切片可独立演示或验证。
  • 每个切片的内容适配单一全新上下文窗口。
  • 每个切片遵循极简主义阶梯（
    docs/agents/workflow.md
    ）：不做推测性抽象，不搭建"为未来准备"的脚手架，只保留能验证路径的最小必要衔接。
</vertical-slice-rules>
为每个工单明确其阻塞依赖——即必须先完成才能启动当前工单的其他工单。无阻塞依赖的工单可立即启动。
大范围重构是例外情况。影响范围覆盖整个代码库的机械变更无法作为单一追踪式切片处理。需按扩展-收缩模式排序：首先扩展（在旧代码旁添加新实现，确保原有功能不受影响），然后按影响范围分批迁移调用站点（按包/目录划分），每批作为一个工单，依赖于扩展步骤的完成，确保CI始终保持绿色；最后一个收缩工单在所有批次完成后移除旧实现。

4. Publish

4. 发布

Create one issue per ticket via the GitHub MCP (
GitHub_issue_write
, 
GitHub_sub_issue_write
) or 
gh
. Set the full field set at creation: milestone (the release the meta issue carries), assignee (
@me
), project, labels, and parent to the meta issue (
gh issue create ... --parent <meta>
) so the tactical tickets roll up under the strategic epic. Model blocking edges as native sub-issues, or a 
Blocked by: #N
line in the body. Apply the 
ready-for-agent
label to tickets with no unresolved blockers. Hand back the ticket URLs and the blocking graph.
通过GitHub MCP（
GitHub_issue_write
、
GitHub_sub_issue_write
）或
gh
工具为每个工单创建一个议题。创建时设置完整字段：milestone（meta issue关联的版本）、assignee（
@me
）、project、标签，以及parent（关联至meta issue，使用
gh issue create ... --parent <meta>
），使战术工单归属于战略史诗议题。将阻塞依赖建模为原生子议题，或在工单正文中添加
Blocked by: #N
行。为无未解决阻塞依赖的工单添加
ready-for-agent
标签。返回工单URL和阻塞关系图。

5. Hand off to delivery

5. 交付移交

Each ticket becomes one branch and one PR; the blocking graph is the stack order (a PR's base is the branch of the ticket that blocks it). Note the issue number and branch name per ticket so 
implement
opens an atomic PR that links it.
每个工单对应一个分支和一个PR；阻塞关系图即为堆叠顺序（PR的基准分支是其依赖工单的分支）。记录每个工单的议题编号和分支名称，以便
implement
工具创建关联该工单的原子PR。

Boundaries

边界

Produces tickets and their edges. Does not implement them (that's 
implement
).
仅生成工单及其依赖关系。不负责工单的实现（实现由
implement
工具完成）。