What this prompt does
This prompt turns a sprawling, multi-file refactor into a reviewable plan instead of one unmanageable diff. You describe the [refactor_scope], the [language], and roughly how many files are affected with [file_count], and the AI analyzes the [current_pattern], explains why it needs changing, proposes the [target_pattern], and orders the migration file-by-file by dependency graph. For each file it shows the old code beside the new code so you approve before applying.
The structure works because it refuses the one-giant-diff trap that makes large refactors impossible to review. By ordering work along the dependency graph, shared interfaces and types get updated first, so type errors do not cascade through every consumer at once. The prompt explicitly asks for the imports and re-exports that will break and how to fix them, a verification step using your [test_command] after each file change, and a rollback checklist in case regressions appear. That last piece exists because regressions during a large refactor are normal, not exceptional, and you want a documented exit plan before you start touching code. Applying changes in small, reviewable batches rather than one massive diff is the throughline of the whole approach.
When to use it
- A refactor spans dozens of files and a single diff would be impossible to review carefully
- You are migrating between framework patterns such as router styles, state libraries, or API shapes
- Shared types or interfaces sit at the center of the change and risk cascading type errors
- You need to keep the app compiling and working after every batch, not only at the very end
- A teammate must review the change incrementally rather than in one overwhelming pull request
- You want a documented rollback path ready before touching production code
Example output
You get a dependency-ordered migration plan: first the shared interfaces and types to change, then a per-file list where each entry shows the old code, the new code, and the imports that break. It ends with the [test_command] to run between files and a rollback checklist. The work is explicitly meant to land in small, reviewable batches rather than a single sweeping commit.
Pro tips
- Make
[current_pattern]and[target_pattern]concrete with real file paths and API names so the generated diffs are accurate - Keep
[file_count]honest — an undercount leads the AI to propose batches that are too large to review - Set
[test_command]to something fast (a type-check plus a focused test run) so you can verify after every single file - Apply the plan strictly in the dependency order it gives; skipping ahead is exactly what triggers cascading type errors
- When a diff looks wrong, push back and ask for the change on just that one file before continuing
- Keep the rollback checklist visible while you work rather than buried in the chat history
