Menu
通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | request-refactor-plan |
| description | 通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。 |
当用户希望创建“重构请求（refactor request）”时会调用本技能。你需要按下方步骤执行；如果你认为某些步骤不必要，可以跳过。
向用户索要一份长篇、细节充分的问题描述：他们想解决的是什么问题；以及任何可能的解决想法。
探索仓库：用于验证用户的判断，并理解当前代码库状态。
询问用户是否考虑过其他方案，并把这些备选方案一并呈现给用户。
围绕实现方案对用户进行访谈：要尽可能详细、透彻。
明确重构实现的准确范围：梳理你计划改什么、以及你计划不改什么。
查看代码库中该区域的测试覆盖情况：如果测试覆盖不足，询问用户他们打算如何安排测试。
把实现拆解成“由一串微小提交组成”的计划。记住 Martin Fowler 的建议：让每一步重构都尽可能小，以便你随时能看到程序仍然在工作。
使用该重构计划创建 GitHub issue。issue 描述使用如下模板：
从开发者视角来看，开发者正在面临的问题。
从开发者视角来看，针对该问题的解决方案。
一份很长、很详细的实现计划。请用通俗英文（plain English）来写，尽可能把实现拆分成“最小粒度”的提交。每一次提交都应保证代码库处于可工作的状态。
实现决策列表。可能包括：
不要包含具体文件路径或代码片段。这些内容很可能会在很快之后变得过时。
测试决策列表。需要包含：
描述本次重构明确不包含哪些内容。
关于该次重构的其他补充说明。
使用 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、创建产品需求文档，或规划一个新功能。
