karasukaigan 此技能将在用户想要创建重构请求时被调用。你应该按照以下步骤进行。如果认为某些步骤不必要，可以跳过。
请用户提供他们想要解决的问题的详细描述以及任何潜在的解决方案想法。
探索仓库以验证他们的断言并理解代码库的当前状态。
询问他们是否考虑过其他选项，并向他们展示其他选项。
就实现细节对用户进行访谈。要极其详细和彻底。
确定实现的确切范围。弄清楚你计划改变什么和不改变什么。
查看代码库以检查该区域的测试覆盖率。如果测试覆盖率不足，询问用户的测试计划。
将实现分解为微小提交的计划。记住 Martin Fowler 的建议："使每个重构步骤尽可能小，以便你始终可以看到程序在工作。"
使用以下模板创建包含重构计划的 GitHub issue：
问题陈述
从开发人员的角度描述开发人员面临的问题。
解决方案
从开发人员的角度描述问题的解决方案。
提交
一个长篇、详细的实现计划。用通俗英语编写计划，将实现分解为尽可能小的提交。每次提交都应该使代码库处于工作状态。
决策文档
已做出的实现决策列表。可以包括：
- 将构建/修改的模块
- 将被修改的模块接口
- 来自开发人员的技术澄清
- 架构决策
- 模式更改
- API 契约
- 特定交互
不要包含具体的文件路径或代码片段。它们可能很快就会过时。
测试决策
已做出的测试决策列表。包括：
- 良好测试的描述（仅测试外部行为，而不是实现细节）
- 哪些模块将被测试
- 测试的先例（即代码库中类似类型的测试）
超出范围
描述此重构范围之外的内容。
进一步说明（可选）
关于重构的任何进一步说明。