Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-05-15 11:11:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(refactor-plan): expand skill description and instructions (#1676)

Browse Source 
Clarify when to invoke the skill and require a plan-first,
  confirm-before-edit workflow so agents do not start changing
  files during planning.
This commit is contained in:
Joseph Kasprzyk
2026-05-11 17:49:12 -06:00
committed by GitHub
parent bcf1d72af3
commit c0d4a0583c
2 changed files with 14 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/refactor-plan/SKILL.md
+13 -12
View File
@@ -1,23 +1,24 @@
---
name: refactor-plan
description: 'Plan a multi-file refactor with proper sequencing and rollback steps'
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 for this refactoring task.
## Refactor Goal
{{refactor_description}}
Create a detailed plan before making any code changes.
## Instructions
1. Search the codebase to understand current state
2. Identify all affected files and their dependencies
3. Plan changes in a safe sequence (types first, then implementations, then tests)
4. Include verification steps between changes
5. Consider rollback if something fails
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
@@ -62,4 +63,4 @@ If something fails:
- [Potential issue and mitigation]
```
Shall I proceed with Phase 1?
After the plan, ask: "Shall I proceed with Phase 1?"