Refactoring

Engineering quality focused skills for AI coding agents that keep humans in the loop.

Install

npx -y skills add kreek/consult --skill refactoring

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

Copied from the file, not written here

Use for refactoring, behavior-preserving change, tests, and safe rewrites.

4.4 KB, as published. Nobody here has run it

GREEN BEFORE THE REFACTOR. GREEN AFTER EACH STEP. NEVER MIX STRUCTURE AND BEHAVIOR IN ONE COMMIT.

Changing structure while preserving behavior: legacy refactors, large renames, extractions, migrations, branch by abstraction, strangler fig, Mikado planning, characterization tests, or big-bang rewrite avoidance.

Behavior-first feature work; use proof.
Commit grouping or git history surgery after changes already exist; use git-workflow.

Preserve behavior first; add characterization tests where coverage is missing. Separate structural from behavior changes: every commit is one or the other, never both.
Name the coupling before changing structure: data shape, side effect, module boundary, ownership, time, transport, persistence, or compatibility.
Make every step small, reversible, and shippable.
Validate the target shape before moving large amounts of code.
For public interfaces, use parallel change: expand, migrate callers, then contract. Ask which callers, data, and releases must keep working before adding shims, dual paths, or migration complexity.
Delete old paths only when traffic/callers have moved and verification proves it.
Simplification is refactoring: remove accidental complexity only after naming the behavior preserved and the coupling reduced.

Define the current behavior that must not change. Add or identify tests that catch regressions at the public boundary.
Name the concern being separated and its current coupling point.
Pick the smallest safe pattern: rename, extract, move, parallel change, branch by abstraction, or strangler. For broad renames, write a rename map first: separate private symbols, file paths, runtime/public keys, persisted names, docs, and compatibility cleanup.
Record a preservation Proof Contract: unchanged behavior claim, relevant invariant, public boundary, before/after check, evidence.
For simplification, remove only complexity that has a named cost: hidden mutable state, unnecessary layer, broad helper, scattered behavior, compatibility shim, dead flag, or duplicated rule with divergent meaning.
Make one structural step, run focused tests, commit. Track any old path left behind with owner and removal condition.

Tests were green before the refactor; characterization coverage exists for legacy behavior touched.
The coupling being separated was named before code moved.
Each commit is structural or behavioral, not both; the system is shippable at every commit.
Public interface changes use expand-contract or compatibility shims; old and new paths both work during migration.
Backward compatibility expectations were confirmed or inherited from an explicit public contract before compatibility machinery was added.
Simplification claims name the removed complexity and the preserved behavior; behavior preservation has before/after evidence.
Deleted tests were replaced by equal or stronger behavior coverage.
Leftover migration/deletion work has owner and deadline.
Every behavior-preservation claim has before/after proof evidence, or the refactor is reported as unproven.

Use these when the shortcut thought appears:

Name behavior-preservation proof and add characterization where coverage is missing.
Split structural and behavioral changes before committing.
Extract a helper/layer only after naming the behavior, state, effect, or boundary being separated.
Treat shorter code as simpler only when it does not hide state, effects, compatibility, ownership, or independent behavior.
Commit renames separately from extractions when possible.
Put opportunistic tweaks in separate behavior commits or leave them out.
Prove no callers remain before deleting old paths, or use expand-contract migration.
Replace big-bang rewrites with the next safe slice or branch-by-abstraction path.