to-issues

工程开发社区 @mattpocock

信任分: 88/100
兼容 Agent: 1

速查档案只列事实：领域、Agent、信任分、作者、原文章节。装与不装请看下方作者解读。

领域: 工程开发
兼容 Agent: Claude Code
信任分: 88 / 100 · 社区维护
作者 / 版本 / 许可: @mattpocock · 未声明 license
安装命令数: 1 条

需要注意： 未限定 allowed-tools，默认拥有全部工具权限。

解读由编辑根据原文凝练而成，命令、链接、术语均与作者原文一致；想看完整论述请切到右侧

to-issues 把一份计划拆成「独立可被任意 agent / 人抓走干」的 issue 列表。核心方法是vertical slice / tracer bullets——每条 issue 都纵切所有集成层（schema / API / UI / tests），一条做完即可独立 demo / 验证。

设计思路

作者反对横切（horizontal slice），那种「一个 issue 只改 schema、另一个只改 UI」的拆法会让单条 issue 完成时没有任何用户可见 behavior。tracer bullets 反过来：宁可多条窄，每条都从最上层穿到最下层；这样并行干活时谁先做完都不阻塞别人。

工作流

Step 1 收上下文：从当前对话的 context + 用户传入的 issue 引用（issue 号 / URL / path）抓全文与 comment；Step 2 探代码（可选但推荐）；Step 3 起草 vertical slices：每条标注 HITL（要人决策 / 设计评审）/ AFK（agent 可独立完成），尽量 AFK；Step 4 Quiz the user：呈现编号清单，每条标 Title / Type / Blocked by / 覆盖的 user stories，问粒度对不对、依赖对不对、要不要拆 / 合、HITL / AFK 标对没；迭代直到用户拍板；Step 5 发布：按依赖顺序（被依赖的先发）发到 issue tracker，引用真 issue 号填 "Blocked by"，AFK ready 的发布时同时打 ready-for-agent 之类 triage label。

Issue body 模板

Parent（父 issue）/ What to build / Acceptance criteria / Blocked by（真依赖再写）。Acceptance 写「能被外部观察到的 behavior」而非「调了哪个内部函数」。

适合谁

已有计划 / PRD / refactor RFC，要把它落成可分配的 ticket
多 agent 并行执行，必须保证「同时抓两条不会撞车」
HITL 与 AFK 任务混合的项目，希望明确什么是人决策、什么交 agent

何时不要用

没有 issue tracker：无消费者
单条 PR 就能落的小改动：开 issue 反而成开销

配套

request-refactor-plan（issue 上游的重构 RFC）、to-prd（issue 上游的 PRD）、triage（issue 落地后的状态机管理）、subagent-driven-development（按 issue 派 subagent 干）、setup-matt-pocock-skills（issue tracker 与 triage 标签的前置配置）。

To Issues

Break a plan into independently-grabbable issues using vertical slices (tracer bullets).

The issue tracker and triage label vocabulary should have been provided to you — run /setup-matt-pocock-skills if not.

Process

1. Gather context

Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.

2. Explore the codebase (optional)

If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.

3. Draft vertical slices

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.

- 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

4. Quiz the user

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.

5. Publish the issues to the issue tracker

For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.

Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.

## Parent

A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).

What to build

A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.

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 here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.

Acceptance criteria

Criterion 1
Criterion 2
Criterion 3

Blocked by

A reference to the blocking ticket (if any)

Or "None - can start immediately" if no blockers.

Do NOT close or modify any parent issue.