Menú
通过用户访谈创建一份带有微小提交（tiny commits）的详细重构计划，然后将其作为 GitHub issue 提交。当用户想规划一次重构、创建重构 RFC，或将一次重构拆分为安全的增量步骤时使用。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
使用并行子代理为一个模块生成多个截然不同的接口设计。当用户想设计 API、探索接口方案、对比模块形态，或提到 "design it twice" 时使用。
交互式 QA 会话，用户以对话方式报告 bug 或问题，代理负责提交 GitHub issue。会在后台探索代码库以获取上下文和领域语言。当用户想报告 bug、做 QA、以对话方式提交 issue，或提到 "QA session" 时使用。
从当前对话中提炼出一份 DDD 风格的通用语言（ubiquitous language）术语表，标记歧义并提出规范术语。保存到 UBIQUITOUS_LANGUAGE.md。当用户想定义领域术语、构建术语表、固化用词、创建通用语言，或提到 "domain model" 或 "DDD" 时使用。
询问哪个技能或流程适合你当前的处境。它是本仓库中各技能的路由器。
从两个轴向审查某个固定点（commit、branch、tag 或 merge-base）以来的变更——Standards（代码是否遵循本仓库记录的编码规范？）和 Spec（代码是否符合源起的 issue/PRD 的要求？）。在并行子智能体中运行两项审查，并把它们并排报告。当用户想审查一个分支、一个 PR、进行中的变更，或要求 "review since X" 时使用。
用于设计深模块的共享词汇。当用户想设计或改进一个模块的接口、寻找深化机会、决定接缝放在何处、让代码更可测试或更易于 AI 导航，或当另一个技能需要深模块词汇时使用。
| name | request-refactor-plan |
| description | 通过用户访谈创建一份带有微小提交（tiny commits）的详细重构计划，然后将其作为 GitHub issue 提交。当用户想规划一次重构、创建重构 RFC，或将一次重构拆分为安全的增量步骤时使用。 |
当用户想要创建一份重构请求时，会调用本技能。你应当按照下面的步骤进行。如果你认为某些步骤没有必要，可以跳过。
请用户给出一段对他们想解决的问题的长篇、详细描述，以及任何可能的解决思路。
探索代码仓库以验证他们的论断，并了解代码库的当前状态。
询问他们是否考虑过其他方案，并向他们呈现其他方案。
就实现方案对用户进行访谈。要极其详细和彻底。
敲定实现的确切范围。弄清楚你计划改动什么、不打算改动什么。
查看代码库，检查该区域的测试覆盖情况。如果测试覆盖不足，询问用户他们的测试计划是什么。
把实现拆分成一份由微小提交组成的计划。记住 Martin Fowler 的建议："让每一步重构尽可能小，这样你始终能看到程序正常运行。"
创建一个 GitHub issue，写入重构计划。issue 描述使用以下模板：
开发者正面临的问题，从开发者的视角描述。
针对该问题的解决方案，从开发者的视角描述。
一份长篇、详细的实现计划。用平实的语言来写，把实现拆分成尽可能微小的提交。每一个提交都应让代码库保持在可运行状态。
一份所做实现决策的清单。可以包括：
不要写具体的文件路径或代码片段。它们可能很快就过时了。
一份所做测试决策的清单。包括：
对本次重构范围之外内容的描述。
关于本次重构的任何补充说明。
