Refactor

Change a design without letting the old one leak into the new. Agents write code that looks like the code around them, so the shape a refactor leaves behind is the one every later change copies. Design is more than half of this work.

Choose the mode

Refactor when the design is sound where it matters and the change can move in steps that each keep the tests green. If the code would be broken for longer than one step, it is not a refactor: stop and choose.
Rewrite when the design is wrong across modules whose patterns interlock, so fixing one module leaves the old shapes in its neighbors for the next agent to copy. A rewrite needs requirements that say what done is, a spec or its acceptance criteria. Without them, write them first with the owner, or refactor.

Decide from the fix history, the backlog and the requirements, never from reading the code a rewrite would replace. For a refactor, design-review's module review then finds the causes to remove; a concern that spans folders, such as navigation, is scoped by what it does, not by file prefix.

The repo's own rules hold throughout: its commit gate, its docs-with-behavior rule, its glossary. This skill never overrides them. Where docs contradict the code or each other, the owner decides which is right; list each contradiction for them rather than picking one.