Refactoring

Overview

Change the internal structure of code without changing its observable behavior. Restructuring and behavior change are two different activities — never do both in one commit.

The cardinal rule

Behavior-preserving, tests green before AND after. If you can't prove behavior is unchanged, you're not refactoring — you're rewriting, and you need different discipline (characterization tests, feature flags; see /loom-code-migration).

Corollaries an expert never violates:

1. Tests are the safety net. Run them before you touch anything (establish green). If there are none for the code you're changing, write characterization tests first (below) — do not refactor untested legacy blind.
2. Tiny reversible steps. One mechanical move at a time; re-run tests after each. When something breaks, inspect the small current diff and use the repository's approved recovery workflow rather than discarding unrelated work.
3. Separate refactor commits from behavior-change commits. A refactor: commit must be a no-op at runtime — reviewers can trust the diff without re-verifying logic. Mixing a bug fix into a rename hides the fix and poisons git bisect. (Commit mechanics: /loom-git-workflow.)
4. Don't change tests and production code in the same step. If a refactor "requires" editing a test's assertions, behavior changed — stop and reconsider.

Not this skill