// 使用 tracer-bullet 竖向切片法，把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues（并形成对应的实现工单）。适用于用户想把 PRD 转成 issues、创建实现任务，或把 PRD 拆成工作项。
使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划，并保存为本地 Markdown 文件（存放在 `./plans/`）。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划，或提到 “tracer bullets”。
通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。
使用 RED-GREEN-重构（red-green-refactor）循环进行测试驱动开发。适用于用户希望用 TDD 构建新功能或修复 bug，提到 “red-green-refactor”，希望使用集成测试，或询问“test-first development（先写测试）”。
通过探索代码库对 Bug/Issue 进行排查归因，并基于 TDD 方式生成修复计划，同时创建对应的 GitHub issue。适用于用户报告了 bug、希望创建 issue、提到“triage”，或想调查并规划某个问题的修复方案。
从当前对话中抽取 DDD 风格的“统一语言”术语表（ubiquitous language glossary），标记歧义，并提出规范的术语选择。保存为 `UBIQUITOUS_LANGUAGE.md`。适用于用户希望定义领域术语、构建术语表、固化用词并强化术语一致性，或提到 “domain model” / “DDD”（领域模型与 DDD）。
通过用户访谈、代码库探索与模块设计来编写 PRD（产品需求文档），然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档，或规划一个新功能。
| name | prd-to-issues |
| description | 使用 tracer-bullet 竖向切片法，把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues（并形成对应的实现工单）。适用于用户想把 PRD 转成 issues、创建实现任务，或把 PRD 拆成工作项。 |
使用 tracer-bullet（示踪子弹/纵向切片）方法，把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues。
请向用户索要 PRD 的 GitHub issue 编号（或 URL）。
如果 PRD 还不在你的上下文窗口中，可以用 gh issue view <number> 获取（带 comments）。
如果你还没有探索代码库，为了理解现状，你可以先探索代码库。
把 PRD 拆成 tracer bullet issues。每个 issue 都是一条足够薄的“贯穿式竖向切片（vertical slice）”：它要切穿所有集成层（schema、API、UI、tests），而不是只对某一层做横向拆分。
切片可能是：
HITL：需要人类参与（例如需要做出架构决策或设计评审）AFK：无需人类参与，可以直接实现并合并优先使用 AFK，尽可能减少 HITL。
把你建议的拆分结果以“编号列表”的形式呈现。对每个切片，展示：
然后提问让用户确认：
根据用户反馈，反复迭代直到用户认可拆分结果。
对于每个已批准的切片，使用 gh issue create 创建 GitHub issue。并使用如下 issue body 模板。
按依赖顺序创建 issues（先创建 blockers），这样你在 “Blocked by” 字段里就能引用到真实的 issue 编号。
## 父级 PRD（Parent PRD）#
对该竖向切片的简洁描述。描述端到端的最终行为，而不是按层逐一解释实现方式。应引用父级 PRD 的具体章节，而不是重复父级 PRD 的内容。
若无阻塞，则写：None - can start immediately
按父级 PRD 中的编号引用：
不要关闭或修改父级 PRD issue。