Appearance
to-issues 解决的是计划太大、AI 无法稳定执行的问题。它要求把 PRD 或计划拆成 vertical slice Issue，每个 Issue 都能单独验证，并标出依赖关系、AFK/HITL 属性和验收标准。
AI 怎么把计划拆成可执行 Issue：to-issues 技能怎么用
一个完整功能直接交给 AI，最容易出现两个结果。
要么它改太多文件，review 看不动。
要么它做到一半丢失上下文，开始修补自己刚制造的问题。
to-issues 这个技能的目标，是把计划拆成可独立执行的 Issue。每个 Issue 都应该像一颗 tracer bullet：窄，但能打穿完整路径。
不按技术层拆
很多人拆任务时，会这样拆：
- 数据库。
- 后端接口。
- 前端页面。
- 测试。
这叫横向切片。它看起来整齐，但每一片单独完成后都不能演示。
to-issues 更适合按用户可见结果拆。
比如 API Key 管理功能，可以拆成：
- 用户能看到当前 API Key 状态。
- 用户能输入并保存新的 API Key。
- 保存失败时能看到错误。
- 用户能删除旧 API Key。
每个 Issue 都尽量包含它需要的最小前后端、状态和验证。这样一个 Issue 完成以后，就能单独检查。
AFK 和 HITL 要分清
Matt Pocock 这套技能里有两个重要标记：
- AFK：AI 可以离线执行，人只需要最后 review。
- HITL：Human in the loop，需要人参与决策或确认。
不是所有任务都应该交给 AFK Agent。
比如“补一个空状态文案”可能是 AFK。
“决定新权限模型”通常是 HITL。
拆 Issue 时要让 AI 明确标注：哪些可以自动执行，哪些必须等人拍板。
每个 Issue 都要有验收标准
一个好的 Issue 至少要写清：
- 要构建什么用户可见行为。
- 完成后怎么验证。
- 是否依赖其他 Issue。
- 是否能 AFK 执行。
可以这样要求 AI：
md
请把这份 PRD 拆成 vertical slice Issues。
不要按数据库、后端、前端这种技术层拆。
每个 Issue 需要包含：标题、AFK/HITL、依赖、用户故事、验收标准。
如果某个 Issue 不能单独验证，请继续拆小。这个 Prompt 的关键是“不能单独验证就继续拆”。
和现有任务拆解技能的关系
站内已经有 任务拆解技能，讲的是给 AI 的任务不要太大。
to-issues 更偏团队工作流：它把拆出来的任务发布到 Issue tracker，并服务后续 triage、AFK Agent 和人工 review。
个人项目也能用，只是 Issue tracker 可以换成本地 Markdown。
你可能还需要
同类技能：
如果一个计划拆完后仍然不能单独验证，那不是 Issue 太少，是切片方向还不对。