Back to Details

to-issues

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

To Issues

转换为Issues

Break a plan into independently-grabbable GitHub issues using vertical slices (tracer bullets).
使用垂直切片（追踪式切片）将计划拆分为可独立承接的GitHub issues。

Process

流程

1. Gather context

1. 收集上下文

Work from whatever is already in the conversation context. If the user passes a GitHub issue number or URL as an argument, fetch it with 
gh issue view <number>
(with comments).
基于对话中已有的所有信息开展工作。如果用户传入GitHub issue编号或URL作为参数，使用
gh issue view <number>
（包含评论）获取该issue内容。

2. Explore the codebase (optional)

2. 探索代码库（可选）

If you have not already explored the codebase, do so to understand the current state of the code.
如果尚未探索过代码库，请进行探索以了解代码的当前状态。

3. Draft vertical slices

3. 草拟垂直切片

Break the plan into tracer bullet issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
<vertical-slice-rules> - Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests) - A completed slice is demoable or verifiable on its own - Prefer many thin slices over few thick ones </vertical-slice-rules>
将计划拆分为追踪式切片任务。每个任务都是贯穿所有集成层的端到端薄垂直切片，而非单一层次的水平切片。
切片分为“HITL”或“AFK”类型。HITL切片需要人工交互，例如架构决策或设计评审。AFK切片无需人工交互即可实现并合并。尽可能优先选择AFK类型。
<vertical-slice-rules> - 每个切片提供一条贯穿所有层级（schema、API、UI、测试）的狭窄但完整的路径 - 完成后的切片可独立进行演示或验证 - 优先拆分为多个薄切片，而非少量厚切片 </vertical-slice-rules>

4. Quiz the user

4. 询问用户

Present the proposed breakdown as a numbered list. For each slice, show:
  • Title: short descriptive name
  • Type: HITL / AFK
  • Blocked by: which other slices (if any) must complete first
  • User stories covered: which user stories this addresses (if the source material has them)
Ask the user:
  • Does the granularity feel right? (too coarse / too fine)
  • Are the dependency relationships correct?
  • Should any slices be merged or split further?
  • Are the correct slices marked as HITL and AFK?
Iterate until the user approves the breakdown.
以编号列表形式展示拟议的拆分方案。对于每个切片，需展示：
  • 标题：简短描述性名称
  • 类型：HITL / AFK
  • 依赖项：哪些其他切片必须先完成（如有）
  • 覆盖的用户故事：该切片对应的用户故事（若源材料包含）
询问用户：
  • 粒度是否合适？（过于粗略 / 过于精细）
  • 依赖关系是否正确？
  • 是否需要合并或进一步拆分某些切片？
  • HITL和AFK类型的标记是否正确？
反复迭代直至用户批准拆分方案。

5. Create the GitHub issues

5. 创建GitHub issues

For each approved slice, create a GitHub issue using 
gh issue create
. Use the issue body template below.
Create issues in dependency order (blockers first) so you can reference real issue numbers in the "Blocked by" field.
<issue-template>
针对每个已批准的切片，使用
gh issue create
创建GitHub issue。使用下方的issue正文模板。
按照依赖顺序创建issues（先创建被依赖的任务），以便在“依赖项”字段中引用真实的issue编号。
<issue-template>

Parent

父任务

#<parent-issue-number> (if the source was a GitHub issue, otherwise omit this section)
#<parent-issue-number>（若源材料为GitHub issue则保留，否则省略此部分）

What to build

需构建内容

A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
该垂直切片的简要描述。描述端到端行为，而非逐层实现细节。

Acceptance criteria

验收标准

  • Criterion 1
  • Criterion 2
  • Criterion 3
  • 标准1
  • 标准2
  • 标准3

Blocked by

依赖项

  • Blocked by #<issue-number> (if any)
Or "None - can start immediately" if no blockers.
</issue-template>
Do NOT close or modify any parent issue.
  • 依赖于#<issue-number>（如有）
若无依赖项则填写“无 - 可立即开始”。
</issue-template>
请勿关闭或修改任何父issue。