Refactor

---
name: refactor
description: >-
  Evidence-driven refactoring — where does structural improvement actually
  pay off, then make that change without changing behavior. Survey mode
  diagnoses by evidence, not aesthetics — git churn × complexity hotspots,
  the recurring-bug log, upcoming work — and verdicts each candidate
  REFACTOR/PREP/LEAVE/WATCH, where LEAVE is the default and "the textbook
  recommends it" is never a reason. Execute mode takes one approved
  candidate in small behavior-preserving moves, suite green after each.
  Keeps a debt register in out/refactor/tracker.md so repeat surveys open
  with what changed. Use for "clean up this module", "improve the
  architecture", "pay down tech debt" — e.g. "/refactor",
  "/refactor <target>". For new behavior use feature; for something broken
  use bugfix.
---

# refactor — earn it first, then preserve behavior

`/refactor` — survey the repo, emit a brief of where improvement pays off
`/refactor <target or goal>` — execute one candidate, safely

Answer one question: **where does structural improvement actually pay for
itself in this codebase — and how is that change made without changing
behavior?** The skill exists to prevent the two documented failure modes of
"improve the architecture": refactoring the wrong code (most ugly code is
never touched again, so cleaning it returns nothing), and **pattern-itis** —
applying design patterns because they're best practices rather than because
a problem here demands them, turning straight-line code into abstraction
lasagna.

## Survey mode — `/refactor`

### Step 1 — Evidence, not aesthetics

Candidates come from signals, never from "this code looks bad":

- **Hotspots** — churn × complexity. Churn from git itself:
  `git log --format= --name-only --since="12 months ago" | sort | uniq -c |
  sort -rn | head -30`, crossed with a complexity proxy (file length,
  indentation depth). Code that is both complex *and* frequently edited is
  where interest compounds; complex-but-cold code is a LEAVE by default.
- **The bug log** — `out/dev/bugfix-log.md` if present. A file that shows up
  repeatedly is structural debt announcing itself.
- **Upcoming work** — the user's stated goals, open specs and plans under
  `out/dev/`. These seed **PREP** candidates: make the change easy, then
  make the easy change — preparatory refactoring is the highest-payoff kind
  because the payoff is scheduled, not hoped for.
- **The map** — `AGENTS.md` gotchas and conventions; a documented gotcha is
  often a workaround for structure that could stop needing one.
- **Memory** — `out/refactor/tracker.md` if it exists: verdicts already
  made. A LEAVE with a reason isn't re-litigated unless its evidence
  changed; repeat surveys open with **"Since last survey"**.

### Step 2 — Verdicts, with the pattern gate

For each candidate: **REFACTOR / PREP / LEAVE / WATCH**.

- **LEAVE is the default.** Promotion needs positive evidence: churn, a
  recurring bug, or scheduled work in the area. "This violates a principle"
  alone promotes nothing — cold code keeps its sins.
- **The pattern gate:** a design pattern is vocabulary, not a goal. Every
  proposal that introduces one names the problem *in this codebase* (with a
  file:line locator and its evidence), why *this* pattern fits, and what
  simpler shape was considered first. "The textbook recommends it" is
  discarded, not weighed. Two quick tests: **the deletion test** — imagine
  deleting the module; if complexity vanishes it was a pass-through, if it
  reappears across N callers it was earning its keep — and **one adapter is
  a hypothetical seam, two are a real one**: don't introduce a seam until
  something actually varies across it.
- **The score is interface depth, not pattern count.** A proposal wins if
  interfaces get simpler and callers get dumber — abstractions that hide
  more than they add. A refactor that grows the number of things a reader
  must understand has failed even if every step was clean.
- Each REFACTOR/PREP carries: the problem + locator, the target shape, a
  sketch of the move sequence, effort, and risk. Candidates too big to stay
  behavior-preserving (real redesigns) are phrased as ready `/feature` or
  `/autopilot` handoffs instead — offered, never performed.

### Step 3 — Brief and register

Render the brief **in chat** per `references/brief-template.md` (read it
when you reach this step), save to `out/refactor/<slug>-<YYYY-MM-DD>.md`
(date via `date +%F`; create the folder if needed; committing is the user's
call), and update `out/refactor/tracker.md` — one row per candidate:
candidate · verdict · evidence · date · status. The user picks what to
execute; the survey never starts cutting on its own.

## Execute mode — `/refactor <target>`

### Step 1 — Safety net before scalpel

- Find the test command (`AGENTS.md`, manifests, CI config) and run the
  suite for a **green baseline**. A pre-existing red is reported and stops
  the run — refactoring on red has no arbiter.
- Area untested? Write **characterization tests** around exactly the code
  to be touched — pin current behavior *as it is, bugs included* — and
  commit them separately before any restructuring. Without them, "behavior
  preserved" is an opinion.

### Step 2 — Small named moves, green after each

Plan the sequence as named moves — extract function, move module, rename,
inline, introduce parameter object — then per move: apply it, run the
suite, checkpoint commit titled with the move. The rhythm is the safety:

- **Red after a step → revert that step.** Never patch forward to green — a
  patched-forward red is a behavior change wearing a refactor's name.
  Rethink the move or split it smaller.
- Every checkpoint leaves the tree shippable. There is no big-bang branch
  where everything is broken until the end.
- **Wide mechanical moves** (a rename or retype fanning across hundreds of
  call sites) sequence as **expand–contract**: add the new form beside the
  old so nothing breaks, migrate call sites in blast-radius-sized batches
  (per package or directory, checkpoint each), then contract — delete the
  old form once no caller remains. The tree stays shippable through the
  whole fan-out.

### Step 3 — Behavior-preserving is the definition

- **A bug found mid-refactor is logged** (`out/dev/bugfix-log.md`, offered
  as a ready `/bugfix` invocation) and its behavior deliberately preserved.
  Fixing it in flight changes behavior and poisons the diff's reviewability.
- No new features, no "while I'm here" improvements outside the stated
  goal, no public-interface changes the goal didn't name.

### Step 4 — Ship, then refresh the map

- Run **done** on the diff. The spec it reviews against is exactly:
  *behavior unchanged, structure goal met* — its evidence checklist and
  fresh-context review apply verbatim.
- Update the tracker row (status, date, commit).
- Structure changed means the map is stale: finish with `/map refresh`.

## Auto mode — under autopilot

Driven by **autopilot** (or explicit auto), the survey's brief-approval
becomes a self-approval on the record in the run's `log.md`, and only
candidates whose evidence survives the pattern gate proceed; anything
arguable parks. Execution changes nothing — the suite was already the
arbiter, and every hard rule above holds verbatim.

## State

`out/refactor/`: `tracker.md` (the debt register) and dated briefs. An
interrupted execution resumes from `git log` — the checkpoint commits *are*
the state — plus the tracker row; never from conversation memory.

## Guardrails

- **LEAVE is the default.** Payoff requires churn, bugs, or scheduled work;
  aesthetics promote nothing.
- **"The textbook recommends it" is never a reason.** A pattern needs a
  named, located problem in this codebase.
- **Behavior-preserving or it isn't refactoring.** Bugs are logged and kept,
  features wait, the goal bounds the diff.
- **Tests are the arbiter.** No suite → characterization tests first; red
  step → revert, never patch forward.
- **Interface depth is the score.** If callers didn't get simpler, adding a
  pattern made it worse — pattern count is not a metric.
- **The survey never cuts.** Diagnosis and execution are separate consents;
  the brief recommends, the user picks the target.