Refactoring

Forward counterpart (designing before code exists): @code-designing.

Multi-rule procedures (sequencing, god-object decomposition, package decomposition): reference.md in this directory.

Case law (deep worked studies):

• Storify → leaf type discovery: ../../examples/storify-leaf-type.md
• Over-abstraction rejection + cheaper alternatives: ../../examples/overabstraction-cidr.md
• Incremental global elimination: ../../examples/dependency-rejection.md
• Duplicated kind-switch → interface dispatch (and the kept-switch rejection): ../../examples/anti-if-dispatch.md
• Type switch over an owned interface → fill-style method (and the dependency-direction rejection): ../../examples/switch-to-polymorphism.md

find <dir> -maxdepth 1 -type f -name '*.go' -not -name '*_test.go' -not -name '*_gen.go' -not -name '*.pb.go' | wc -l

≤7 green — fine. 8–12 yellow — design review before the next file lands. ≥13 red — must decompose. Either zone: run the 3-step design review in reference.md → "Package decomposition" (it is a design review — missing domain types are the disease, file count the symptom). Invoke @code-designing to validate extracted types.

Fowler's preparatory refactoring — "make the change easy, then make the easy change": reshape code an approved plan is about to touch, before the first RED, so the feature lands as add-only. Invoked by @linter-driven-development (Phase 1.5, or Phase 2 RED friction) or /go-ldd-prepare, with a DESIGN PLAN, the touch-point file list, and findings that already passed the four PREPARE gates (multiply / safe / bounded / skeptic — the gates live in @linter-driven-development <phase_1_5_prepare>; this mode trusts their verdicts and re-runs none of them). Fully autonomous — no user confirmation, same as the rest of this skill.

Differences from failure-driven operation:

• The trigger is the plan, not the linter. Targets are usually lint-green; "still failing → next move" does not apply. Route each finding by its rule (the same <routing_table> rules own the same fix patterns) and apply.
• Safety before motion. Uncovered paths get characterization tests through the public API first (@testing); the full suite — not just the touched package — runs green after every move, because prep edits existing behavior by definition.
• Stopping criterion — landing shape, not lint. Stop when the planned change lands as add-only or near-add-only: a new variant = one new file plus one case at the dispatch boundary (R11); new behavior = a method on an existing type (R1); new code = testable without touching globals (R8). Re-check against the plan after each move; shape reached → STOP, even with findings left — those were never preparation and belong to Phase 4's advisory report.
• Commits are segregated. Prep work lands in its own commit(s), never mixed with feature code — the reviewer sees behavior-preserving reshaping and new behavior as separate diffs.

changed_files=$({ git diff --name-only; git diff --cached --name-only; } | sort -u)
[ -n "$changed_files" ] && printf '%s\n' "$changed_files" | xargs grep "//nolint" 2>/dev/null

Any hit → remove the directive and fix properly. Genuine false positives belong in .golangci.yaml exclusions — with user approval, never unilaterally.

Failures Routed:

1. [linter] → [rule] → [move applied]: [what changed]

Types Created (R1 verdict): [Type] — [why juicy] → @testing invoked Types Rejected (not juicy): [Type] — [cheaper alternative used]

Metrics: cyclomatic [before]→[after], LOC [before]→[after], nesting [before]→[after] Files Modified: [file] (+X, -Y)

STATUS: [linter green / still failing: N issues / escalated to @code-designing]

</output_format>

<integration>
**Invoked by**: @linter-driven-development (Phase 1.5 / RED friction → `<preparatory_mode>`;
Phase 3, lint failures), or the caller acting
on accepted @pre-commit-review findings (@linter-driven-development Phase 4 accepted
findings, or the user) — @pre-commit-review reports only and never invokes fix skills.
**Invokes**: @code-designing (new types/design needed), @testing (after every extraction
— mandatory), @pre-commit-review (after lint passes). **Loop**: lint fails → @refactoring
→ re-lint → @pre-commit-review → repeat until both pass.
</integration>