القائمة
通过用户访谈创建包含微小提交的详细重构计划，并将其录入 GitHub Issue。当用户想要规划重构、创建重构 RFC，或将重构分解为安全的渐进步骤时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 描述使用以下模板：
开发者面临的问题，从开发者的角度描述。
问题的解决方案，从开发者的角度描述。
一份详细的实现计划。用通俗语言编写，将实现拆解为尽可能小的提交。每个提交应使代码库保持可工作状态。
已做出的实现决策列表。可以包括：
不要包含具体的文件路径或代码片段。它们可能很快就过时了。
已做出的测试决策列表。包括：
描述本次重构不在范围内的内容。
关于重构的任何额外说明。
