chore: import zh skill request-refactor-plan

This commit is contained in:
wehub-skill-sync
2026-07-13 21:36:34 +08:00
commit d298c70303
2 changed files with 77 additions and 0 deletions
+9
View File
@@ -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 清单整理
- 原作者、版权和许可证信息以上游仓库为准
+68
View File
@@ -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>