Claude Code Prompts for Refactoring

Refactor with Claude Code without surprise scope creep. Copy-paste prompts for safe rename refactors, extract-function, dead-code removal, and large-scale migrations.

💥 50p impulse-buy: Power Prompts PDF (first 10 buyers) 30 battle-tested Claude Code prompts · 8-page PDF · paste into CLAUDE.md and never re-type a prompt again · 50p impulse-buy, no commitment

Most Claude Code refactor failures come from prompts that say "refactor X" without bounding the scope. Claude will helpfully also rename your variables, reformat your strings, and "modernise" three unrelated files. The prompts below box in the change to exactly what you wanted.

Prompt 1 — The safe rename (mechanical, zero risk)

Rename [OLD_NAME] to [NEW_NAME] across this codebase.

Constraints:
- Mechanical change only — same logic, same control flow
- Update all references: definitions, imports, comments, docstrings, tests, README
- Do NOT touch any other code in the same files
- Do NOT reformat
- Do NOT remove "unused" imports flagged as a side effect
- After: run the test suite and confirm green

Output: unified diff, then test results.

The "do not touch any other code" clause is the difference between a clean rename PR and a 40-file horror.

Prompt 2 — Extract function (the small refactor)

In [FILE], the function [FN_NAME] is doing too much.
Extract the section starting at line [N] (the [WHAT IT DOES] logic) into
a new function called [NEW_FN_NAME].

Constraints:
- Preserve exact behaviour (no logic changes)
- Pass all currently-used variables as explicit parameters
- Return value: [DESCRIBE]
- Add a one-line docstring explaining when it's called
- Update the call site only
- Do NOT extract anything else, even if it's tempting

After: list the parameters and return type of the new function.

Prompt 3 — Dead code removal (with a safety net)

Identify dead code in [DIRECTORY]:
- Functions defined but never called
- Imports unused
- Exported names with zero importers
- Branches reachable only via deprecated flags

For each finding:
- file:line
- evidence (grep results showing zero callers)
- confidence (high / medium / low — what could you be missing?)

Do NOT delete anything yet. Output as a markdown table.
I'll review and tell you which to remove.

Why the two-phase split? Claude's dead-code detection is good but not perfect — dynamic imports, reflection, and string-built names trip it up. Reviewing the table first lets you veto false positives before deletion.

Prompt 4 — The "small diff" refactor

Refactor [FN_NAME] in [FILE] to fix [SPECIFIC PROBLEM] with the smallest
possible diff.

Hard limits:
- Diff under 30 changed lines
- No renames anywhere
- No formatting changes
- No changes to functions called by [FN_NAME]
- No new files
- No new dependencies

If you can't fit it in 30 lines, propose a multi-step plan instead.

Prompt 5 — The migration refactor (multi-step)

I want to migrate [DIRECTORY] from [OLD PATTERN] to [NEW PATTERN].

Phase 1 (this prompt): plan only.
Output a 5–7 step migration plan where:
- Each step touches at most 5 files
- Each step leaves the codebase compiling and tests passing
- Each step has a single semantic theme (don't mix concerns)
- The last step removes the old pattern entirely

For each step: title, files touched, what changes, rollback if it goes wrong.
Do NOT write code in this prompt. Wait for "execute step 1".

This is the right way to do refactors larger than a single PR. Sequential reviewable steps beat one giant change that's impossible to revert cleanly.

Prompt 6 — Pattern modernisation (e.g. callbacks → async/await)

Convert callback-style functions in [FILE] to async/await.

Per function:
- Wrap callback-using internals with util.promisify or equivalent
- Convert the public signature to async (returning Promise)
- Update callers in the same file
- Do NOT update callers in other files — list them instead, I'll do separate PRs

Output:
1. Diff of [FILE]
2. List of external caller file:line that I need to update next

Prompt 7 — Reduce cyclomatic complexity

Function [FN] in [FILE] has cyclomatic complexity of [N].
Reduce it to under 10 without changing behaviour.

Approach order:
1. Early returns / guard clauses
2. Extract nested conditionals to predicate functions
3. Replace switch/if-chain with a lookup map when the cases are pure data
4. Only if 1–3 don't suffice: split into multiple functions

Show the diff. Run tests. Confirm green.

The pattern for safe Claude Code refactors

30 prompts in one PDF

These refactor prompts are 7 of the 30 in the Claude Code Power Prompts pack. The PDF groups them by workflow (review, debugging, testing, architecture, docs, devops) with a TIP box per prompt. £3 launch price tonight (first 10 buyers), then £5. Paste into CLAUDE.md once, Claude reads it every session.

Grab the PDF →

Frequently asked questions

Why do my Claude Code refactors keep changing unrelated code?
Because the prompt doesn't bound the scope. Add explicit 'do not touch' clauses: file allow-lists, banned change categories (no renames, no reformat), and a hard line budget. Claude reliably respects negative constraints when stated upfront.
Should I refactor in one big prompt or many small ones?
Many small ones. Each refactor prompt should produce a diff small enough to read in under 5 minutes. If Claude proposes 400+ lines of changes, push back: 'Split this into 3 sequential refactors. Output only the first.'
Can Claude Code refactor across language boundaries (e.g. update TypeScript types and the Python SDK consumer)?
Yes, but treat each language as a separate phase. Refactor Phase 1: TypeScript types only, run typecheck. Phase 2: Python consumer, run mypy. Don't merge phases — debugging a multi-language refactor in one diff is painful.

Free tools

Cost Calculator → API Cookbook → Diff Summarizer → Skills Browser →

More examples

Claude API Python QuickstartClaude API Node.js / TypeScript QuickstartClaude API Streaming in PythonClaude API Streaming in Node.js / TypeScriptClaude API Tool Use in PythonClaude API Tool Use in Node.js / TypeScript