refactor-to-patternslisted

Plans refactoring as an ordered succession of named refactorings from Fowler's *Refactoring* and Kerievsky's *Refactoring to Patterns*, after first ruling out removing code rather than adding it, and presents the plan for approval before any edit. Use this whenever the user asks to refactor, restructure, clean up, simplify, deduplicate, decouple, generalize, or redesign existing code — including indirect phrasings like "this class is a mess", "too much duplication here", "untangle this", "reduce the branching", "this function is too long", or "make this extensible". Also use it when a feature request or bug fix cannot be done cleanly in the current structure — when the obvious implementation would mean copy-pasting logic, adding yet another branch to a conditional, or threading a parameter through several layers — because the restructuring needs to be planned, approved, and committed separately before the change itself.
dgutson/refactor-to-patterns · ★ 0 · Code & Development · score 72

Install: claude install-skill dgutson/refactor-to-patterns

# Refactor to Patterns Refactoring is a sequence of small behavior-preserving moves, each of which has a name. This skill keeps that true: it turns "clean this up" into an ordered, auditable list of named refactorings, and it makes the list start by asking what can be **removed** before proposing anything new. ## Why the discipline is shaped this way Asked to improve code, a model reliably grows it — measured against human patches for the same bugs, LLM-generated patches carry roughly twice the changes and substantially higher cyclomatic complexity, and the effect gets *worse* with open-ended iteration and with wider context. Instructions to "be minimal" do not fix this; the intention evaporates on contact with the code. So the obligations below are **artifacts you produce**, not attitudes you hold. A written verdict and a named step list can be checked by the user before any code moves. An intention cannot. Two practical consequences shape everything here: work from a bounded context rather than sweeping the repository, and prefer a short plan you commit to over open-ended redesign. ## Two modes **Mode A — refactoring as the goal.** The user wants the code better. There is no pending feature. Success is a structural improvement with behavior unchanged. **Mode B — refactoring as a prerequisite.** A feature or bug fix is the goal, and the current structure is in the way. Kent Beck's formulation is the whole method: *make the change easy, then make the easy change.* Mod