mcpField
R
refactor-plan

refactor-plan

github.com/helderberto开发2047 次安装6 天前更新
代码仓库

关于 refactor-plan

用于规划代码重构的开发技能，面向需要先明确范围与方案的开发者。它强调小步、连续且始终保持代码可运行，并将计划整理为 GitHub Issue。

主要功能

  1. 01梳理问题与现有代码状态
  2. 02访谈并明确改动范围
  3. 03比较方案及其权衡
  4. 04拆分为可运行的小步提交
  5. 05创建 GitHub Issue 计划

适用场景

  1. 01规划大型重构的实施步骤
  2. 02在重构前检查受影响区域的测试覆盖
  3. 03将获批的重构方案记录为 GitHub Issue

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/helderberto/agent-skills --skill refactor-plan

安装后在 Claude Code 中输入/refactor-plan确认已加载。

详细介绍

重构规划

流程

1. 理解问题
  • 获取用户的详细描述
  • 询问用户考虑过哪些可能的解决方案
  • 探索代码库以确认当前状态
2. 确定范围
  • 询问用户实现细节
  • 提出备选方案——将每种方案作为一个选项，并在描述中说明权衡；适用时使用预览展示代码草图。若可用，请使用 AskUserQuestion；否则以编号列表呈现。
  • 明确界定哪些内容会更改，哪些内容保持不变
  • 检查受影响区域的测试覆盖率
3. 拆分工作

遵循 Martin Fowler 的原则：“尽可能将每个重构步骤拆得更小，这样你就能随时确认程序仍在正常运行。”

  • 创建由多个微小提交组成的列表
  • 每个提交都应保证代码库可正常运行
  • 按顺序进行更改，而非并行进行
4. 创建 GitHub Issue
gh issue create --title "Refactor: <title>" --body "$(cat <<'EOF'
## Problem Statement

The problem from the developer's perspective.

## Solution

The approach from the developer's perspective.

## Commits

Detailed plan broken into the tiniest commits possible. Each leaves codebase working.

1. Add new interface type
2. Update service to accept new interface (keep old code path)
3. Add tests for new code path
4. Update consumers to use new interface
5. Remove old code path

## Implementation Decisions

- Modules to build/modify and their interfaces
- Architectural decisions
- Schema changes
- API contracts

Do NOT include file paths or code snippets -- they go stale.

## Testing Decisions

- What makes a good test (behavior, not implementation)
- Which modules need tests
- Prior art: similar test patterns in the codebase

## Out of Scope

What is explicitly not included.
EOF
)"

规则

  • 每个提交都必须保证代码库功能正常
  • 计划中不要包含实现细节（聚焦于行为）
  • 开始前确认测试覆盖率
  • 获取用户对方案的批准

错误处理

  • gh issue create 失败——运行 gh auth status 验证身份验证；也可以提出改为以 Markdown 格式输出
  • 测试覆盖不足——注明缺口，并将“为 X 添加测试”作为第一个提交
  • 范围超出预期——继续之前与用户一起修订计划

另请参阅

  • tdd —— 使用测试驱动开发实现重构后的代码

评论

支持 Markdown