// 使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划，并保存为本地 Markdown 文件（存放在 `./plans/`）。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划，或提到 “tracer bullets”。
| name | prd-to-plan |
| description | 使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划，并保存为本地 Markdown 文件（存放在 `./plans/`）。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划，或提到 “tracer bullets”。 |
使用竖向切片（tracer bullet）把 PRD 拆分为分阶段的实施计划。输出会写成 ./plans/ 目录下的一份 Markdown 文件。
PRD 应当已经出现在对话中。若没有，请让用户粘贴 PRD，或指出文件位置。
如果你还没有探索代码库，可以先探索以理解当前架构、既有模式以及集成层（integration layers）。
在开始切片之前，先识别那些在实现过程中不太会改变的高层决策，并把它们放在计划的开头，方便每个阶段都能引用：
把 PRD 拆成 tracer bullet 阶段。每个阶段都是一个薄的“贯穿式竖向切片”：它要切穿所有集成层的端到端闭环，而不是只对某一层做横向拆分。
- 每个切片都要提供一条狭窄但完整的路径（覆盖 schema、API、UI、tests） - 完成的切片应当可演示或可独立验证 - 相比少数几个很厚的切片，更倾向于使用许多更薄的切片 - 不要包含那些很可能随后续阶段而变化的具体文件名、函数名或实现细节 - 但要包含“耐久/可持续”的决策：如路由路径、schema 形状、数据模型名称把你建议的阶段拆分以“编号列表”的形式呈现。对每个阶段展示：
并向用户提问：
根据用户反馈进行迭代，直到用户认可拆分结果。
如果 ./plans/ 目录不存在，请先创建。然后把计划写成 Markdown 文件，文件名以功能名命名（例如：./plans/user-onboarding.md）。使用如下模板：
来源 PRD：<简要标识或链接>
贯穿所有阶段的可持续决策：
用户故事（User stories）：<从 PRD 提取的列表>
对该竖向切片的简洁描述。描述端到端的行为，而不是按层逐一解释实现方式。
用户故事（User stories）：<从 PRD 提取的列表>
...
使用 tracer-bullet 竖向切片法，把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues（并形成对应的实现工单）。适用于用户想把 PRD 转成 issues、创建实现任务，或把 PRD 拆成工作项。
通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（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、创建产品需求文档，或规划一个新功能。