Refactoring Safely

Change structure and design in small steps with tests so behavior stays the same and risk is low.

When to Activate

User asks to "refactor", "clean up", or "improve without changing behavior"
Extracting functions, renaming, or reorganizing code
Paying down tech debt in a controlled way
Preparing code for a feature (e.g. extract interface so new implementation can be added)

Behavior preserved — Observable behavior (outputs, API, side effects) must not change. Rely on tests and, if needed, quick manual checks. If there are no tests, add at least smoke or critical-path tests before large refactors, or note the risk.
Small steps — One kind of change per step (e.g. rename, extract function, move file). Commit or checkpoint after each step so you can revert easily.
Test first — Ensure tests exist and pass before refactoring. After each step, run the full test suite. If tests fail, fix or revert before continuing.
No feature work in same change — Do not mix refactor with new features or bug fixes. Separate PRs or commits so "behavior unchanged" is obvious from the diff.