To Issues
使用纵向切片（曳光弹 / tracer bullets）将计划拆解为可独立领取的任务。
流程
- 选择发布位置
默认为本地 Markdown —— 文件放在本仓库的 .scratch/ 目录下，无需远程。不要探测 git remote；仅在用户明确要求时才发布到 GitHub 或 GitLab。
询问用户希望发布到哪里，并预先选中本地 Markdown：
本地 Markdown（默认）—— 文件位于本仓库的 .scratch/<feature-slug>/issues/ 下
GitHub —— GitHub issues（gh CLI），仅在要求时使用
GitLab —— GitLab issues（glab CLI），仅在要求时使用
将选择带入第 6 步。对于 GitHub 或 GitLab，如果 docs/agents/issue-tracker.md 覆盖了该后端，则遵循其中确切的约定与分诊标签映射；否则使用下方 <destination-conventions> 中的约定。运行 /setup-matt-pocock-skills 来配置这些约定和分诊标签词汇表。
- 收集上下文
基于对话上下文中已有的内容进行工作。如果用户传入一个 issue 引用（issue 编号、URL 或路径）作为参数，则从 issue tracker 获取它并阅读其完整正文与评论。
- 探索代码库（可选）
如果你尚未探索过代码库，请进行探索以了解代码的当前状态。issue 的标题和描述应使用项目的领域词汇表术语，并遵循你所涉及区域的 ADR。
寻找机会对代码进行预重构（prefactor），以便让实现更容易。“先让改动变容易，再做容易的改动。”
- 起草纵向切片
将计划拆解为曳光弹 issue。每个 issue 都是一条薄纵向切片，端到端地贯穿所有集成层，而不是某一层的横向切片。
每条切片都通过每一层（schema、API、UI、测试）交付一条狭窄但完整的路径
完成的切片可单独演示或验证
任何预重构都应首先完成
- 向用户提问确认
以编号列表形式呈现建议的拆解方案。对每条切片，展示：
标题：简短的描述性名称
阻塞于（Blocked by）：哪些其他切片（如有）必须先完成
覆盖的用户故事：该切片解决的用户故事（如果源材料中包含）
询问用户：
粒度是否合适？（太粗 / 太细）
依赖关系是否正确？
是否有切片应合并或进一步拆分？
迭代直到用户批准该拆解方案。
- 发布 issue
对每条已批准的切片，将其作为新 issue 发布到第 1 步选择的目标位置。使用下方的 issue 正文模板。这些 issue 被视为可供 AFK 智能体处理，因此除非另有指示，发布时带上正确的分诊标签。
按依赖顺序发布 issue（阻塞者优先），以便在“Blocked by”字段中引用真实的 issue 标识符。对于本地 Markdown，标识符是文件的编号/ slug，“Blocked by”引用阻塞文件（例如 01-foo.md）。
GitHub —— gh issue create --title "..." --body "..."（多行正文使用 heredoc）。分诊标签通过 --label 指定。
GitLab —— glab issue create --title "..." --description "..."（多行描述使用 heredoc）。分诊标签通过 --label 指定。
本地 Markdown —— 将每个 issue 写为 .scratch/<feature-slug>/issues/<NN>-<slug>.md，从 01 开始编号，如有需要则创建目录。在每个文件顶部附近以 Status: 行记录分诊状态，而不是使用标签。
（如源为已有 issue，则包含指向 issue tracker 上父 issue 的引用；否则省略此部分。）
要构建什么
对该纵向切片的简洁描述。描述端到端行为，而不是逐层实现。
避免具体的文件路径或代码片段 —— 它们很快会过时。例外：如果某个原型产出的片段比文字更精确地编码了某项决策（状态机、reducer、schema、类型形状），可在此内联，并简要说明它来自原型。只保留决策密集的部分 —— 不是可运行的演示，只是关键部分。
验收标准
标准 1
标准 2
标准 3
阻塞于
指向阻塞工单的引用（如有）
若无阻塞，则为“None - can start immediately”。
不要关闭或修改任何父 issue。 对 issue 的唯一改动应涉及其状态；如果该 issue 已 100% 完成，可将其状态改为“Done”。