Refactoring plan

I want to refactor the following code. Goal: {{goal}}

Constraints: {{constraints}}

Propose a step-by-step plan where:
- Each step is independently shippable - the code compiles, passes tests,
  and behaves identically to before that step, at the end of every step.
- Steps are ordered so the riskiest or most uncertain change happens as
  early as possible, while it's still cheap to back out of.
- Each step names what could go wrong and how you'd notice (a failing
  test, a type error, a specific behavior to manually verify).
- The final step is the one that actually captures the benefit of
  {{goal}} - everything before it is groundwork.

Don't write the full refactored code yet - just the plan, with enough
detail per step that I could hand any one step to someone else to
implement without them needing the full context.

Code (or description of the current structure):
{{code_or_description}}

When to use

Before touching a big function, a core module, or anything with a lot of callers, where a single giant diff would be hard to review and risky to revert. Also useful for explaining a refactor plan to a reviewer or teammate before starting.

Why it works

The instinct on a messy piece of code is to rewrite it all at once, which produces a huge diff that’s hard to review and impossible to safely half-revert if something’s wrong. Forcing every step to leave the codebase in a working, shippable state is the core discipline of the “strangler fig” style of refactoring - it trades one big risky change for several small, boring, low-risk ones.

Variations

• Add “Assume this needs to ship across multiple PRs over the next two weeks, reviewed by someone unfamiliar with the goal” if the refactor is genuinely large.
• Ask for a rollback plan per step (“if step 3 causes a regression, what’s the fastest safe revert”) for a refactor touching a critical path.
• Follow up with “Now write step 1” once you’re happy with the plan, to get the actual first diff.