当需要把 plan、spec 或对话拆成带…

把已整理的 plan、spec 或当前对话转成一组可独立演示、带依赖关系、可被 agent 领取并发布到已配置 tracker 的 tickets。

适用场景

解决思路

1. 使用当前 conversation context 中已经存在的内容。
2. 如果用户把 reference（spec path、issue number 或 URL）作为参数传入，获取并完整读取其 body 和 comments。
3. 如果还没有探索 codebase，先探索 codebase 以了解 code 当前状态。
4. Ticket title 和 description 使用项目领域词汇表词汇，并遵守相关 ADRs。
5. 寻找 prefactor code、让 implementation 更容易的机会，遵循 “Make the change easy, then make the easy change.”
6. 把工作拆成 tracer-bullet（曳光弹式）tickets。
7. 让每个 slice 都贯穿每一层（schema、API、UI、tests），形成窄而完整的路径；必须是 vertical slice，不是某一层的 horizontal slice。
8. 让完成的 slice 可独立 demo 或 verify。
9. 让每个 slice 的大小能放进一个 fresh context window。
10. 任何 prefactoring 都应先完成。
11. 为每个 ticket 给出 blocking edges：它开始前必须完成的其他 tickets；没有 blockers 的 ticket 可以立即开始。
12. 识别 wide refactor：影响整个 codebase 的 mechanical change，例如 rename column 或 retype shared symbol；一次 edit 会破坏成千上万 call sites，无法让任何 vertical slice 独立保持 green。
13. 对 wide refactor 不要强行做成 tracer bullet；按 expand–contract 排序。
14. 先 expand：在旧形式旁加入新形式，保持一切正常。
15. 再按 blast radius 分批迁移 call sites（按 package、directory 等），每批一个 ticket，并被 expand block；旧形式仍存在，因此 CI 每批都保持 green。
16. 最后 contract：一旦没有 caller 残留，就在被所有 migrate batches block 的 ticket 中删除旧形式。
17. 如果连单独 batches 也不能保持 green，仍保留这个 sequence，但让它们共享 integration branch，并全部 block 最后的 integrate-and-verify ticket；只在最后承诺 green。
18. 把建议的拆分作为 numbered list 展示。
19. 每个展示的 ticket 包含 Title：简短的描述性名称。
20. 每个展示的 ticket 包含 Blocked by：必须先完成的其他 tickets（如有）。
21. 每个展示的 ticket 包含 What it delivers：这个 ticket 打通的 end-to-end behaviour。
22. 询问用户 Granularity 是否合适（太粗或太细）。
23. 询问用户 Blocking edges 是否正确，每个 ticket 是否只依赖真正 gate 它的 tickets。
24. 询问用户是否应继续合并或拆分 tickets。
25. 迭代到用户批准拆分。
26. 发布已批准的 tickets 到 /setup-matt-pocock-skills 配置的 tracker；tickets 相同，只有 blocking edges 的形状不同。
27. Local files：在 `.scratch/<feature-slug>/issues/<NN>-<slug>.md` 下每 ticket 写一个文件，按 dependency order（blockers 优先）从 `01` 编号。
28. Local files：每个文件的 Blocked by 列出它依赖的 number/title。
29. Local files：使用 per-ticket template；每个文件只放一个 ticket，绝不要写成一个 combined file。
30. 真实 issue tracker（GitHub、Linear 等）：按 dependency order（blockers 优先）每 ticket 发布一个 issue，让 blocking edges 能引用真实 identifiers。
31. 真实 issue tracker：平台支持时使用 native blocking/sub-issue relationship，否则把 blocking issues 写进每个 ticket 的 Blocked by。
32. 真实 issue tracker：除非另有指示，应用 `ready-for-agent` triage label；这些 tickets 天生可被 agent 领取。
33. 处理 frontier：所有 blockers 都完成的 tickets；纯 linear chain 就是从上到下。
34. 不要 close 或 modify 任何 parent issue。
35. 使用 local-ticket-template：标题为 `# <NN> — <Ticket title>`。
36. 使用 local-ticket-template：`**What to build:**` 写这个 ticket 从用户视角打通的 end-to-end behaviour，而不是逐层 implementation list。
37. 使用 local-ticket-template：`**Blocked by:**` 写 gate 这个 ticket 的 numbers/titles，或「None — can start immediately」。
38. 使用 local-ticket-template：写 `**Status:** ready-for-agent`。
39. 使用 local-ticket-template：添加 `- [ ] Acceptance criterion 1`、`- [ ] Acceptance criterion 2` 等验收标准。
40. 使用 issue-template：`## Parent` 写 tracker 上 parent issue 的 reference（如果来源是 existing issue；否则省略本 section）。
41. 使用 issue-template：`## What to build` 写这个 ticket 从用户视角打通的 end-to-end behaviour，而不是逐层 implementation。
42. 使用 issue-template：`## Acceptance criteria` 添加 `- [ ] Criterion 1`、`- [ ] Criterion 2` 等。
43. 使用 issue-template：`## Blocked by` 写每个 blocking ticket 的 reference，或「None — can start immediately」。
44. 无论哪种形式，都避免具体 file paths 或 code snippets；它们很快会过时。
45. 例外：如果 prototype 产出的 snippet 比 prose 更精确地编码了 decision（state machine、reducer、schema、type shape），可以内联，并简短说明来自 prototype；只保留 decision-rich parts，不要放 working demo。

适用边界 · 注意事项

• Issue tracker 和 triage label vocabulary 未配置或未提供时，不要直接发布 tickets；先让用户运行 `/setup-matt-pocock-skills`。
• 对影响整个 codebase 的 wide refactor（如 rename column、retype shared symbol）不要强行拆成 tracer-bullet vertical slices；应改用 expand–contract 排序。
• 不要 close 或 modify 任何 parent issue。