Menú
通过用户访谈创建包含微小提交的详细重构计划，并将其录入 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
Manage git submodules for the learning-open-code mono-repo. Use when the user wants to: (1) Add a new git submodule — auto-detect or specify the category (open-ai-skills/open-sdd/open-ai-agent/open-ai-desktop/open-knowledge/open-productivity/open-java/open-trading/open-data), record the tracking branch in .gitmodules, clone the repo, and update README.md index. (2) Sync all existing submodules to their configured branches (git fetch + checkout branch + pull). (3) Update the root README.md with an up-to-date index of all synced projects grouped by category. (4) Initialize submodules after git clone — when open-*/ directories are empty or git submodule status returns nothing, guide through the full SOP (git submodule update --init --recursive [--remote]). Trigger keywords: submodule, git submodule, 子模块, add submodule, sync submodule, update submodule, submodule branch, README index, 更新索引, clone, init, 初始化子模块, submodule init, 拉取子模块.
对开源项目进行穷尽式教学文档生成——从宏观架构到微观实现的五层分级讲解，使用 Goal Loop 算法自主驱动完整代码覆盖。所有具体教学内容生成必须激活 `.agents/skills/teach/SKILL.md`。触发条件：用户要求"完整学习某个项目"、"生成项目架构文档"、"从入口到落地讲清楚每个功能"、"代码考古"、"源码分析"、或指定一个项目目录/仓库要求全面教学。
使用并行子 agent 为模块生成多个截然不同的接口设计。当用户想要设计 API、探索接口选项、比较模块形态，或提到 "设计两次" 时使用。
交互式 QA 会话，用户以对话方式报告 bug 或问题，agent 将其录入 GitHub Issue。在后台探索代码库以获取上下文和领域语言。当用户想要报告 bug、做 QA、以对话方式录入 issue，或提及 "QA session" 时使用。
从当前对话中提取 DDD 风格的通用语言词汇表，标记歧义并提出规范术语。保存到 UBIQUITOUS_LANGUAGE.md。当用户想要定义领域术语、构建词汇表、固化术语、创建通用语言，或提到 "领域模型" 或 "DDD" 时使用。
将当前对话交接给一个新的后台代理，由它立即接手继续工作。
| name | request-refactor-plan |
| description | 通过用户访谈创建包含微小提交的详细重构计划，并将其录入 GitHub Issue。当用户想要规划重构、创建重构 RFC，或将重构分解为安全的渐进步骤时使用。 |
当用户想要创建重构请求时，将调用此 skill。你应按照以下步骤进行。如果认为某些步骤不必要，可以跳过。
请用户详细描述他们想要解决的问题以及任何潜在的解决思路。
探索仓库以验证他们的陈述并了解代码库的当前状态。
询问他们是否考虑过其他选项，并向他们展示其他可选方案。
就实现方案对用户进行访谈。要极其详细和彻底。
敲定实现的确切范围。确定你计划更改什么以及不计划更改什么。
查看代码库，检查该区域是否有测试覆盖。如果测试覆盖不足，询问用户的测试计划是什么。
将实现拆解为微小提交的计划。牢记 Martin Fowler 的建议："让每个重构步骤尽可能小，这样你始终能看到程序处于正常工作状态。"
创建一个包含重构计划的 GitHub Issue。对 issue 描述使用以下模板：
开发者面临的问题，从开发者的角度描述。
问题的解决方案，从开发者的角度描述。
一份详细的实现计划。用通俗语言编写，将实现拆解为尽可能小的提交。每个提交应使代码库保持可工作状态。
已做出的实现决策列表。可以包括：
不要包含具体的文件路径或代码片段。它们可能很快就过时了。
已做出的测试决策列表。包括：
描述本次重构不在范围内的内容。
关于重构的任何额外说明。
