Refactor without breaking

Reshapes code in small verifiable steps, without sneaking behaviour changes along the way.

Cuándo se usa

When a file has grown unwieldy or you are about to touch something scary.

SKILL.md

# Refactor without breaking

Refactoring means changing shape without changing behaviour. The moment the two
get mixed, nobody can tell what broke what.

## Before touching anything

- Make sure there is a way to verify: tests, a build command, or a screen you can
  look at. If there is none, create the smallest one first.
- Write down what the code does today, odd behaviours included. Some of those are
  bugs; others are the reason something works.

## While working

- One change per step, verifying between steps: rename, extract, move. Never all
  three at once.
- No silent behaviour changes. If you find a bug on the way, note it and fix it
  separately.
- Extract a function only when you can give it an honest name. If the best name
  you can think of is doStuff, it is not clear yet.
- Do not rename things for taste in files you are not touching: it inflates the
  diff and hides what matters.

## When you finish

Say what moved and what you checked to know nothing broke. If something was left
half done, say it is half done.