refactorlisted

# /refactor — pin behaviour → transform → prove equivalence A refactor that quietly changes behaviour is a bug with good PR copy. The gate here is the one thing that distinguishes the two: **behaviour is pinned in tests written before the change, and those tests pass unmodified afterwards.** If a test had to be edited to make the refactor pass, it wasn't a refactor. Input (**$ARGUMENTS**): what to restructure **and why**. The motivation is not optional — Stage 5 has to judge whether the structure actually improved, and "it's cleaner" is not reviewable. If it's empty, ask what hurts and what it's costing. **If the ask is "rename/replace X with Y across N call sites", stop and run `/migrate` instead.** That is a census job: it's provable by re-grepping for the old pattern and finding nothing. A refactor has no such grep, which is exactly why it needs behaviour pinned first. --- ## Config (override only if the repo needs it) - `BASE_BRANCH` = the repo's default branch. `WORKTREE_DIR` = `../<repo>--refactor-<slug>`. `BRANCH` = `refactor/<slug>`. - `MAX_FIX_ROUNDS` = `3`. `MERGE_MODE` = `manual` (stop at a reviewed PR; `auto` opt-in). - **Quality bar / test commands** = whatever the repo's README / CLAUDE.md / test config states. - The orchestrator owns all git/gh; agents never push. ## Stage 0 — Scope, motivation, and the `/migrate` escape hatch Name the target precisely (files, module, the seam being introduced) and state the motivation in one sentence. Check the escap