How do I install the Githubcopilot Refactor Plan skill?

Run npx skillmds@latest add pyfagorass/githubcopilot-refactor-plan in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Githubcopilot Refactor Plan safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Githubcopilot Refactor Plan?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Githubcopilot Refactor Plan free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Githubcopilot Refactor Plan?

pyfagorass (@pyfagorass) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Githubcopilot Refactor Plan by pyfagorass

Name: Githubcopilot Refactor Plan
Author: pyfagorass

Githubcopilot 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.

pyfagorass a1e21cc 2.2 KB Updated Sep 17, 2026

File contents

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?"

---name: githubcopilot-refactor-plandescription: 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 PlanCreate a detailed plan before making any code changes.## Instructions1. 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 PlanIf 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?"

Frequently asked questions