用途：把一份 PRD 拆解为可独立认领的任务（issue），每个任务以本地 Markdown 文件形式写入 issues/ 目录。
主要能力与流程：
- 定位 PRD：向用户询问 PRD 文件路径（如 issues/prd.md），若不在上下文中则读取该文件。
- 探索代码库（可选）：如尚未了解代码库现状，先进行探索。
- 起草垂直切片：将 PRD 拆成曳光弹式任务，每个任务是贯穿所有集成层的薄垂直切片，而非单一层的水平切片。切片分为 HITL（需人工交互，如架构决策或设计评审）与 AFK（无需人工交互即可实现并合并），尽量优先 AFK。
- 向用户确认：以编号列表展示拆分方案，每项包含标题、类型（HITL/AFK）、被谁阻塞、覆盖哪些用户故事；并询问粒度是否合适、依赖关系是否正确、是否需要合并或拆分、HITL/AFK 标记是否正确，迭代至用户批准。
- 创建任务文件：对每个获批切片，按 issues/NNN-short-title.md 命名（如 issues/001-add-user-auth.md）写入 issues/。编号从下一个可用数字开始（检查 issues/ 已有文件）。按依赖顺序创建（阻塞者优先），以便在“Blocked by”字段引用真实文件名。
文件内容结构：引用所用 PRD 文件；What to build（描述端到端行为，引用 PRD 具体章节而非复制内容）；Acceptance criteria（验收标准清单）；Blocked by（引用 issues/NNN-title.md，无阻塞则写 None - can start immediately）；User stories addressed（按 PRD 编号引用）。
限制：不要使用 gh issue create 或任何 GitHub CLI 命令，不要引用 GitHub issue 编号，所有交叉引用使用本地文件名；不要关闭或修改父 PRD 文件。
适用场景：需要把产品需求文档转化为可并行、可独立认领的开发任务清单时。
其他信息（如具体平台支持、收费方式等）暂未提供。