gof-refactor-to-pattern

One-line summary

Take existing code and step-by-step move it toward a target GoF pattern — small commits, behavior preserved at every step, tests green between each.

When to use this skill

• The user knows the destination pattern and wants the path.
• A code smell has a known pattern-shaped fix (big switch on enum → State; primitive flag explosion → Decorator).
• Migration from procedural / transaction-script code to OO with patterns.

When NOT to use this skill

• The user doesn't know which pattern fits — route to gof-identify.
• The user wants a review, not a refactor — route to gof-review.
• The user wants the pattern in new code → route to gof-implement style (here, that maps to gof-kotlin-idioms for direct code).

Core content

General discipline: never combine a refactor with a feature change in one commit. Each refactor step must keep behavior identical and pass tests; if there are no tests, write characterization tests first.