refactor-plan
Create a concrete plan before starting a multi-file refactor. Use when the user asks to plan, sequence, scope, or safely execute a refactor across multiple files; always investigate first, output the plan, and wait for confirmation before making code changes.
摘要
- 用途
- 它将重构工作整理成安全且考量相依性的流程，涵盖从调查到验证。
- 使用时机
- 当变更涉及跨文件耦合，或需要在实作前安排分阶段检查与复原方式时，适合使用它。
- 输出结果
- 它会产出依据保存库现况的计划，说明目前与目标状态、受影响文件、分阶段步骤、验证、复原与风险，并等待核准。
上游变更（4 条，最新收录 2026-05-11）
c0d4a05 fix(refactor-plan): expand skill description and instructions (#1676) 扩充了技能描述与指示，要求先调查代码库并提出完整且分阶段的重构计划，再进行编辑，并纳入验证、复原、厘清模糊需求及实作前确认。 caab1f6 Convert all prompts to skills and update plugin manifests 添加 `skills/refactor-plan/SKILL.md` 技能文档，包含中继数据、多文件重构规划指示，以及涵盖运行阶段、验证、复原与风险的结构化计划范本。 2a32411 Fix review feedback: mode→agent frontmatter, add applyTo, generate plugin 将提示档前置中继数据中的 `mode` 字段改为 `agent`，并保留其值为 `agent`。 99018f4 Add context-engineering collection 添加 `prompts/refactor-plan.prompt.md`，包含代理程序与工具中继数据、重构目标占位符、规划指示、含复原与风险区段的分阶段计划范本，以及询问是否继续的提示。 npx skills add "lettucebo/Skills#v2.2.0@refactor-plan" --full-depth ⚠ v2.2.0 发布后即可使用
Refactor Plan
Create a detailed plan before making any code changes.
Instructions
- Do not edit files while preparing the plan.
- Search the codebase to understand the current state. Read enough implementation, tests, configuration, and docs to make the plan specific to the repository.
- Identify affected files, ownership boundaries, dependencies, and likely hidden coupling.
- Plan changes in a safe sequence. Prefer contracts and types first, then implementations, then callers, then tests, then cleanup.
- Include verification steps between phases and a final validation command.
- Include rollback or recovery steps for the riskiest phases.
- Output the complete plan using the format below.
- Stop after the plan and ask for confirmation before implementing. If the user already asked you to implement, still produce the plan first and wait for confirmation unless they explicitly said to continue without review after the plan.
If the request is too ambiguous to plan safely, ask concise clarifying questions instead of editing files.
Output Format
## Refactor Plan: [title]
### Current State
[Brief description of how things work now]
### Target State
[Brief description of how things will work after]
### Affected Files
| File | Change Type | Dependencies |
|------|-------------|--------------|
| path | modify/create/delete | blocks X, blocked by Y |
### Execution Plan
#### Phase 1: Types and Interfaces
- [ ] Step 1.1: [action] in `file.ts`
- [ ] Verify: [how to check it worked]
#### Phase 2: Implementation
- [ ] Step 2.1: [action] in `file.ts`
- [ ] Verify: [how to check]
#### Phase 3: Tests
- [ ] Step 3.1: Update tests in `file.test.ts`
- [ ] Verify: Run `npm test`
#### Phase 4: Cleanup
- [ ] Remove deprecated code
- [ ] Update documentation
### Rollback Plan
If something fails:
1. [Step to undo]
2. [Step to undo]
### Risks
- [Potential issue and mitigation]
After the plan, ask: "Shall I proceed with Phase 1?"