refactor

name	refactor
description	Restructure code without changing behavior. Triggers: "rename X to Y", "move X to Y", "extract X into Y", "clean up / split / deduplicate code" — one transformation at a time, tests kept green.

A refactor that changes behavior is not a refactor — it's a bug risk wearing a refactor's clothes. Keep structural and behavioral changes in separate commits always.

Scope rules — read before touching anything

• One transformation per pass. Never combine rename + extract + move in a single step.
• No opportunistic fixes. If you see a bug, a missing test, or a style inconsistency while refactoring, write it to a TODO file and continue. Fix it in a separate commit after the refactor is committed.
• No incidental reformatting. Do not change indentation, trailing commas, import order, or quote style unless the transformation requires it. Noise in the diff obscures real changes and breaks reviewers.
• Feature creep is a failure mode. If the transformation turns into "while I'm here I'll also…" — stop. Complete the stated transformation and nothing else.

Steps

1. Green gate. Call skill("verify") and follow its body to run the project's tests. Do not proceed without loading it.

   • If red: stop — refactoring on a broken suite is untrackable; you cannot tell whether your change introduced failures. Ask the user to fix or accept the current red baseline before continuing.
   • If no tests exist: note this explicitly. Proceed with extra caution — you have no automated safety net. Limit each transformation to the smallest possible diff, and manually verify the observable behavior (run the program, call the function, check the output) before committing.

2. Name the transformation. One sentence: "rename foo → bar", "extract from into ", "split into and by concern". Write it down; this sentence becomes your commit message subject.