to-issues

转为 Issue

使用纵向切片（示踪弹）将计划拆分为可独立认领的 Issue。

Issue 跟踪器和分流标签词汇表应该已经提供给你；如果没有，请运行 /memo-flow。

流程

1. 收集上下文

基于当前对话中的已有内容开展工作。如果用户传入了 Issue 引用（Issue 编号、URL 或路径）作为参数，请从 Issue 跟踪器中获取该 Issue，并阅读其完整正文和评论。

2. 探索代码库（可选）

如果你尚未探索代码库，请先探索，以了解代码的当前状态。Issue 标题和描述应使用项目的领域词汇表，并遵循你要修改的领域中的 ADR。

3. 起草纵向切片

将计划拆分为示踪弹 Issue。每个 Issue 都是一条薄的纵向切片，端到端贯穿所有集成层，而不是只涵盖单一层的横向切片。

切片可以是「HITL」或「AFK」。HITL 切片需要人工参与，例如架构决策或设计评审。AFK 切片无需人工参与即可实现并合并。尽可能优先选择 AFK。

- 每个切片都应通过所有层（架构、API、UI、测试），交付范围窄但完整的路径 - 每个已完成的切片都能独立演示或验证 - 与其选择少量厚重切片，不如优先选择多个轻薄切片

4. 向用户确认

以编号列表的形式展示建议的拆分方案。对每个切片，列出：

• 标题：简短且描述性强的名称
• 类型：HITL / AFK
• 阻塞项：必须先完成的其他切片（如有）
• 涵盖的用户故事：此切片涉及的用户故事（如果源材料中包含）

询问用户：

• 粒度是否合适？（太粗 / 太细）
• 依赖关系是否正确？
• 是否应合并某些切片，或进一步拆分？
• HITL 和 AFK 标记是否正确？

反复调整，直到用户批准拆分方案。

5. 将 Issue 发布到 Issue 跟踪器

为每个获批的切片创建一个新 Issue。使用下面的 Issue 正文模板。这些 Issue 已准备好交由 AFK Agent 处理，因此除非另有指示，否则请添加正确的分流标签。

按依赖顺序发布 Issue（先发布阻塞项），以便在「阻塞项」字段中引用真实的 Issue 标识符。

## 父级

引用 Issue 跟踪器中的父级 Issue（如果源内容来自现有 Issue；否则省略本节）。

要构建的内容

简洁描述此纵向切片。描述端到端行为，而非逐层实现。

避免使用具体文件路径或代码片段——它们很快就会过时。例外情况：如果原型生成的代码片段比文字描述更精确地表达了一项决策（状态机、reducer、架构或类型），请将其内联写在此处，并简要说明该内容来自原型。仅保留包含关键信息的部分——不需要可运行的演示，只需说明重要内容。

验收标准

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

阻塞项

• 引用阻塞此 Issue 的工单（如有）

如果没有阻塞项，填写「无——可立即开始」。

不要关闭或修改任何父级 Issue。

6. 总结

发布完所有 Issue 后，按类型（AFK / HITL）分组，简要列出新 Issue 的编号和标题。最后必须以以下说明原文结束，不得添加具体 Issue 编号：

• AFK 切片：交给 afk-cook 技能处理——它会解析依赖关系，并按正确顺序交付所有 ready-for-agent 切片。该技能的文档会介绍如何调用；此处不要写出脚本路径或任何标志。
• HITL 切片：逐个打开，并以交互方式运行 /tdd。

不要建议针对特定 Issue 编号运行 afk-cook。 Runner 是排序顺序的唯一依据；在此处指定 Issue 会暗示作出一项 Runner 执行时会重新决定的决策。