菜单
通过用户访谈创建包含微小提交的详细重构计划，然后将其提交为 GitHub Issue。当用户想要规划重构、创建重构 RFC，或将重构拆分为安全的增量步骤时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
一轮一轮地同时询问所有前沿问题，进行无情的盘问。
把你无法独自回答的决策转化为一份问卷，交给别人来填写。
使用并行子代理为一个模块生成多种截然不同的接口设计方案。当用户想要设计 API、探索接口选项、比较模块形态，或提到"设计两次"时使用。
交互式 QA 会话，用户以对话形式报告 bug 或问题，代理负责提交 GitHub Issue。在后台探索代码库以获取上下文和领域语言。当用户想要报告 bug、进行 QA、以对话形式提交 Issue，或提到"QA session"时使用。
从当前对话中提取 DDD 风格的通用语言（Ubiquitous Language）词汇表，标记歧义并提出规范术语。保存到 UBIQUITOUS_LANGUAGE.md。当用户想要定义领域术语、构建词汇表、强化术语体系、创建通用语言，或提到"领域模型"或"DDD"时使用。
询问哪种技能或流程适合你的情况。本仓库中技能的路由器。
| name | request-refactor-plan |
| description | 通过用户访谈创建包含微小提交的详细重构计划，然后将其提交为 GitHub Issue。当用户想要规划重构、创建重构 RFC，或将重构拆分为安全的增量步骤时使用。 |
该技能在用户想要创建重构请求时被调用。你应该按照以下步骤进行。如果你认为某些步骤不必要，可以跳过。
请用户详细、长篇地描述他们想要解决的问题，以及任何潜在的解决方案思路。
探索仓库以验证用户的断言，并了解代码库的当前状态。
询问用户是否考虑过其他方案，并向他们展示其他选项。
与用户面谈实现细节。要做到极其详细和全面。
敲定实现的确切范围。确定你计划修改的内容和计划保持不变的内容。
在代码库中检查该区域是否有测试覆盖。如果测试覆盖不足，询问用户他们的测试计划是什么。
将实现拆分为一系列微小提交。记住 Martin Fowler 的建议："让每个重构步骤尽可能小，这样你就能始终看到程序在正常工作。"
创建一个包含重构计划的 GitHub Issue。使用以下模板作为 Issue 描述：
从开发者的角度描述开发者面临的问题。
从开发者的角度描述问题的解决方案。
一个详细的实现计划。用通俗易懂的英文编写计划，将实现拆分为尽可能小的提交。每个提交都应使代码库保持可工作状态。
一份已做出的实现决策清单。可以包括：
不要包含具体的文件路径或代码片段。它们可能很快就会过时。
一份已做出的测试决策清单。包括：
描述本次重构不涉及的内容。
关于重构的任何补充说明。
