Refactor Planner

MIT License

Copyright (c) 2026 OpenAgentSkills Contributors

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.

Refactor Planner

What this skill does

This skill directs the agent to analyze a block of code (or an entire module) and produce an ordered, safe refactoring plan. Rather than rewriting everything at once, it breaks the work into small, reversible steps — each one leaving the tests green and the behavior unchanged. It identifies code smells, maps dependencies, flags high-risk areas, and sequences the changes so you can ship incrementally without introducing regressions.

Use this when you have messy, hard-to-understand code that works but needs cleaning up before you can safely add features.

How to use

Claude Code / Cline

Copy this file to .agents/skills/refactor-planner/SKILL.md in your project root.

Then ask the agent:

• *"Use the Refactor Planner skill on src/utils/dataProcessor.ts."*
• *"Plan a safe refactor of this function using the Refactor Planner skill."*

Paste in the code you want refactored, or point to a file path.

Cursor

Add the "Prompt / Instructions" section below to your .cursorrules file, or paste it directly into the Cursor AI pane before sharing the code you want refactored.

Codex

Paste the target code into the chat along with the instructions from the section below. For large files, include the full file plus any files that import from it so Codex can map dependencies.

The Prompt / Instructions for the Agent

When asked to plan a refactor, follow these steps precisely:

1. Read the code thoroughly. If a file path is given, read the full file. Also read any files that import from it or that it imports from, so you understand the dependency graph.

2. Identify code smells. Look for:

• Functions longer than 40 lines
• Deeply nested conditionals (more than 3 levels)
• Duplicated logic (copy-paste code)
• Magic numbers and hardcoded strings
• God objects or functions that do too many things
• Inconsistent naming conventions
• Mutable shared state
• Missing or misleading comments
• Dead code (unreachable or unused)

3. Map dependencies. For each problematic section, note:

• What calls it (callers)
• What it calls (callees)
• What data it reads or mutates
• Whether it has test coverage

4. Assess risk for each change. Label every planned step as:

• Low risk — pure rename, extract with no logic change, add a comment
• Medium risk — restructure logic that has test coverage
• High risk — change with no tests, touches shared state, or modifies a public API

5. Generate the ordered refactoring plan. Each step must:

• Be small enough to do in a single commit
• Leave the code in a working state after it is applied
• Be described clearly so a developer can execute it manually
• Reference the specific function, class, or line range it affects
• Come with a one-line "how to verify this step didn't break anything"

6. Format the output as follows:

## Code Smells Found
- [Smell type]: [Description] — [Location]
...

## Dependency Map
- `functionName` is called by: X, Y, Z
- `functionName` depends on: A, B
...

## Refactoring Plan

### Step 1 — [Title] [Risk: Low/Medium/High]
**What:** [What to change]
**Why:** [Which smell this addresses]
**How:** [Concrete action, e.g., "Extract lines 45–67 into a new function called `validateInput`"]
**Verify:** [How to confirm nothing broke, e.g., "Run `npm test` — all existing tests should pass"]

### Step 2 — ...
...

## High-Risk Flags
[List any steps that need special attention, tests to write first, or API surface changes that require coordination]

7. Do not rewrite the code yet. The output is a plan only. If the user then asks you to execute a specific step, do it one step at a time.

Example

Input to Agent:

> "Use the Refactor Planner skill on this function:

>

> `ts

> function process(data: any) {

> let result = [];

> for (let i = 0; i < data.length; i++) {

> if (data[i].type === 'A') {

> if (data[i].value > 100) {

> if (data[i].active) {

> result.push({ id: data[i].id, score: data[i].value * 1.5 });

> }

> }

> } else if (data[i].type === 'B') {

> if (data[i].value > 50) {

> result.push({ id: data[i].id, score: data[i].value * 1.2 });

> }

> }

> }

> return result;

> }

> `"

Output from Agent:

> ## Code Smells Found

> - Deep nesting: Triple-nested conditionals make the logic hard to follow — lines 3–13

> - Magic numbers: 100, 1.5, 50, 1.2 have no named meaning — lines 5, 8, 12, 13

> - Loose typing: data: any loses all type safety — line 1

>

> ## Refactoring Plan

>

> ### Step 1 — Name the magic numbers [Risk: Low]

> What: Extract 100, 1.5, 50, 1.2 into named constants at the top of the file.

> Why: Eliminates magic numbers, makes thresholds searchable.

> How: Add const TYPE_A_THRESHOLD = 100, const TYPE_A_MULTIPLIER = 1.5, etc.

> Verify: Run existing tests — output should be identical.

>

> ### Step 2 — Add types [Risk: Low]

> What: Define an Item interface and replace any.

> Why: Prevents silent bugs from misshapen input.

> How: interface Item { id: string; type: 'A' | 'B'; value: number; active?: boolean }

> Verify: TypeScript should compile with no new errors.

>

> ### Step 3 — Extract per-type handlers [Risk: Medium]

> What: Move the type A and type B branches into processTypeA(item) and processTypeB(item).

> Why: Eliminates deep nesting, makes each branch independently testable.

> How: Extract the inner if blocks into separate functions that return { id, score } | null.

> Verify: Run tests; add a unit test for each new function before extracting.