用途
当用户希望创建一次重构请求（refactor request）时，会调用该技能。它主要用于把一次重构从模糊想法梳理成结构化、可执行的实施计划，并最终形成 GitHub issue。
主要流程与能力
该技能按以下步骤推进（部分步骤在认为不必要时可跳过）：
- 请用户详细、长篇幅地描述想要解决的问题以及可能的解决方案想法。
- 探索代码仓库，以验证用户的陈述并理解代码库当前状态。
- 询问用户是否考虑过其他选项，并向其展示其他可选方案。
- 就实现细节对用户进行极其详尽彻底的访谈。
- 确定确切的实现范围：明确计划改什么、不改什么。
- 检查代码库中该区域的测试覆盖情况。若测试覆盖不足，询问用户的测试计划。
- 将实现拆分为由微小提交组成（tiny commits）的计划，遵循 Martin Fowler 的建议“让每个重构步骤尽可能小，以便始终能看到程序在正常工作”。
- 创建带有重构计划的 GitHub issue。
GitHub Issue 模板结构
技能使用固定模板撰写 issue 描述，包含以下部分：
- Problem Statement（问题陈述）：从开发者视角描述其所面临的问题。
- Solution（解决方案）：从开发者视角描述问题的解决方案。
- Commits（提交）：一份长而详细的实现计划，用平实英语撰写，将实现拆解为尽可能微小的提交。每个提交都应使代码库保持可运行状态。
- Decision Document（决策文档）：列出已做出的实现决策，可包括：将构建/修改的模块、这些模块中将被修改的接口、来自开发者的技术澄清、架构决策、schema 变更、API 契约、具体交互。该部分明确要求不包含具体文件路径或代码片段，因为它们可能很快过时。
- Testing Decisions（测试决策）：列出已做出的测试决策，包括：好测试的描述（只测试外部行为，不测试实现细节）、将测试哪些模块、测试的既有先例（即代码库中类似类型的测试）。
- Out of Scope（范围之外）：描述本次重构不在范围内的事项。
- Further Notes（进一步说明，可选）：关于本次重构的任何进一步说明。
使用方式
该技能在用户想规划重构、发起重构请求时被调用。它通过对话式访谈与代码库探索相结合来完成计划制定，并产出 GitHub issue。
适用场景
- 需要系统规划一次代码重构时。
- 希望把重构拆分为一系列微小、可保持代码可运行的提交时。
- 需要在重构前澄清范围、决策与测试策略，并形成可追踪的 issue 时。
限制
关于收费、价格、平台支持等具体信息暂未提供。模板中明确禁止在决策文档里包含具体文件路径或代码片段。