// 通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。
使用 tracer-bullet 竖向切片法，把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues（并形成对应的实现工单）。适用于用户想把 PRD 转成 issues、创建实现任务，或把 PRD 拆成工作项。
使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划，并保存为本地 Markdown 文件（存放在 `./plans/`）。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划，或提到 “tracer bullets”。
使用 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 | request-refactor-plan |
| description | 通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。 |
当用户希望创建“重构请求（refactor request）”时会调用本技能。你需要按下方步骤执行；如果你认为某些步骤不必要，可以跳过。
向用户索要一份长篇、细节充分的问题描述：他们想解决的是什么问题；以及任何可能的解决想法。
探索仓库：用于验证用户的判断，并理解当前代码库状态。
询问用户是否考虑过其他方案，并把这些备选方案一并呈现给用户。
围绕实现方案对用户进行访谈：要尽可能详细、透彻。
明确重构实现的准确范围：梳理你计划改什么、以及你计划不改什么。
查看代码库中该区域的测试覆盖情况：如果测试覆盖不足，询问用户他们打算如何安排测试。
把实现拆解成“由一串微小提交组成”的计划。记住 Martin Fowler 的建议：让每一步重构都尽可能小，以便你随时能看到程序仍然在工作。
使用该重构计划创建 GitHub issue。issue 描述使用如下模板：
从开发者视角来看，开发者正在面临的问题。
从开发者视角来看，针对该问题的解决方案。
一份很长、很详细的实现计划。请用通俗英文（plain English）来写，尽可能把实现拆分成“最小粒度”的提交。每一次提交都应保证代码库处于可工作的状态。
实现决策列表。可能包括：
不要包含具体文件路径或代码片段。这些内容很可能会在很快之后变得过时。
测试决策列表。需要包含：
描述本次重构明确不包含哪些内容。
关于该次重构的其他补充说明。