commit d298c703035ebda9b26dc81f00869c5c2e263dbc
Author: wehub-skill-sync <skill-sync@wehub.local>
Date:   Mon Jul 13 21:36:34 2026 +0800

    chore: import zh skill request-refactor-plan

diff --git a/README.wehub.md b/README.wehub.md
new file mode 100644
index 0000000..0fee04e
--- /dev/null
+++ b/README.wehub.md
@@ -0,0 +1,9 @@
+# WeHub 来源说明
+
+- Skill 名称：`request-refactor-plan`
+- 中文类目：制定细粒度重构计划
+- 上游仓库：`mattpocock__skills`
+- 上游路径：`skills/deprecated/request-refactor-plan/SKILL.md`
+- 上游链接：https://github.com/mattpocock/skills/blob/HEAD/skills/deprecated/request-refactor-plan/SKILL.md
+- 本仓库为 WeHub 中文 Skill 汉化包，基于 skill 市场筛选 Top200 清单整理
+- 原作者、版权和许可证信息以上游仓库为准
diff --git a/SKILL.md b/SKILL.md
new file mode 100644
index 0000000..5afe163
--- /dev/null
+++ b/SKILL.md
@@ -0,0 +1,68 @@
+---
+name: request-refactor-plan
+description: 通过用户访谈创建详细的、包含小型提交的重构计划，然后将其归档为 GitHub Issue。当用户想要规划重构、创建重构 RFC 或将重构分解为安全的增量步骤时使用。
+---
+
+此技能将在用户想要创建重构请求时被调用。你应该按以下步骤操作。如果你认为某些步骤不必要，可以跳过它们。
+
+1. 向用户询问他们想要解决的问题的详细长描述，以及任何潜在的解决方案想法。
+
+2. 探索代码仓库以验证他们的断言，并理解代码库的当前状态。
+
+3. 询问用户是否考虑过其他方案，并向他们展示其他可选方案。
+
+4. 就实现细节对用户进行访谈。要做到极其详细和彻底。
+
+5. 敲定实现的确切范围。明确你计划更改什么以及计划不更改什么。
+
+6. 在代码库中检查该区域是否有测试覆盖。如果测试覆盖不足，询问用户的测试计划。
+
+7. 将实现分解为一系列小型提交的计划。记住 Martin Fowler 的建议："让每个重构步骤尽可能小，这样你就能始终看到程序处于可工作状态。"
+
+8. 创建一个包含重构计划的 GitHub Issue。使用以下模板作为 Issue 描述：
+
+<refactor-plan-template>
+
+## 问题陈述
+
+从开发者角度描述开发者面临的问题。
+
+## 解决方案
+
+从开发者角度描述问题的解决方案。
+
+## 提交计划
+
+一份详细而冗长的实现计划。用通俗易懂的英文编写计划，将实现分解为尽可能小的提交。每次提交后代码库都应处于可工作状态。
+
+## 决策文档
+
+一份已做出的实现决策列表。可以包括：
+
+- 将要构建/修改的模块
+- 这些模块将要修改的接口
+- 来自开发者的技术澄清
+- 架构决策
+- 模式变更
+- API 契约
+- 特定交互
+
+不要包含具体的文件路径或代码片段。它们可能会很快过时。
+
+## 测试决策
+
+一份已做出的测试决策列表。包括：
+
+- 什么是好测试的描述（只测试外部行为，不测试实现细节）
+- 哪些模块将被测试
+- 测试的先前参考（即代码库中类似类型的测试）
+
+## 范围外
+
+对本重构来说不属于范围的描述。
+
+## 补充说明（可选）
+
+关于重构的任何补充说明。
+
+</refactor-plan-template>