refactor plan
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.
Introduction source: author · github · b6483db44fb602654bca6a097185fcaddb305f97 Reference
Author's original introduction
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.
SkillPi interpretation
- Tasks
- refactor plan
- Audience
- Use the scenarios stated in the author's introduction.
- Inputs and outputs
- See the complete author document; outputs have not been runtime verified by SkillPi.
- Software, accounts and paid services
- Check required software, accounts, costs and permissions in the full document; confirm and authorize actual file access and external services in your host. Domains referenced in the documents (not a runtime allowlist): No HTTP(S) domain stated.
- Limits and differences
- Functionality, version status and outcome statements in the introduction are author claims. Only pinned source and static attachment evidence were checked; runtime behavior, external services and compatibility are not guaranteed.
- Testing
- Not tested
Permissions and checks before use
Automatically summarized from this main document. Matches may be examples or defensive advice; they are not actual permission declarations. Attachments, external dependencies and runtime behavior are not covered.
These common operations were not identified in the main document. This does not mean no permissions or risks exist.
Security rating and access scope
caution · Static evidence review; not a runtime safety guarantee.
Check required software, accounts, costs and permissions in the full document; confirm and authorize actual file access and external services in your host. Domains referenced in the documents (not a runtime allowlist): No HTTP(S) domain stated.
Before use, confirm and authorize actual file access, external services and network destinations in your host. This review grants no runtime permissions.
Original SKILL.md
--- name: refactor-plan description: '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.' --- # Refactor Plan Create a detailed plan before making any code changes. ## Instructions 1. Do not edit files while preparing the plan. 2. Search the codebase to understand the current state. Read enough implementation, tests, configuration, and docs to make the plan specific to the repository. 3. Identify affected files, ownership boundaries, dependencies, and likely hidden coupling. 4. Plan changes in a safe sequence. Prefer contracts and types first, then implementations, then callers, then tests, then cleanup. 5. Include verification steps between phases and a final validation command. 6. Include rollback or recovery steps for the riskiest phases. 7. Output the complete plan using the format below. 8. 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 ```markdown ## 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?"
Copyright and license notice
MIT License Copyright GitHub, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
User discussion