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.
Summary
- Purpose
- It structures refactoring work into a safe, dependency-aware path from investigation through validation.
- When to use
- It is useful when a change has cross-file coupling or needs staged checks and recovery planning before implementation.
- Outputs
- It produces a repository-informed plan of the current and target states, affected files, ordered phases, verification, rollback, and risks, then waits for approval.
Upstream changes (4, latest included 2026-05-11)
c0d4a05 fix(refactor-plan): expand skill description and instructions (#1676) Expanded the skill description and instructions to require repository investigation and a complete, sequenced refactor plan before edits, including verification, rollback, clarification for ambiguity, and confirmation before implementation. caab1f6 Convert all prompts to skills and update plugin manifests Added `skills/refactor-plan/SKILL.md` as a skill document with metadata, instructions for planning multi-file refactors, and a structured plan template covering execution phases, verification, rollback, and risks. 2a32411 Fix review feedback: mode→agent frontmatter, add applyTo, generate plugin Changed the prompt frontmatter key from `mode` to `agent`, keeping its value as `agent`. 99018f4 Add context-engineering collection Added `prompts/refactor-plan.prompt.md` with agent/tool metadata, a refactor-goal placeholder, planning instructions, a phased plan template with rollback and risk sections, and a prompt asking whether to proceed. npx skills add "lettucebo/Skills#v2.2.0@refactor-plan" --full-depth ⚠ Available after v2.2.0 is published
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?"