Refactor

Concept of the skill

Behavior-preserving restructuring of existing code — extracting functions, reducing duplication, renaming for clarity, splitting modules, and tightening structure, with every change verified against before/after behavior so external contracts stay identical.

Coverage

• Behavior preservation: identifying the external contract that must remain stable before any change
• Duplication reduction: consolidating repeated logic without over-abstraction
• Decomposition: extracting functions, modules, or types to improve readability and reuse
• Naming improvements: renaming so identifiers carry their real meaning
• Structure improvements: reorganizing file and module boundaries when the current layout obscures intent
• Verification before and after: running the same behavioral checks on both sides of the change

Philosophy of the skill

Refactoring pays off only when the shape of the code has diverged from the shape of the problem. Before that point it is risk without reward — every move invites a regression, and "cleaner" is a preference, not a justification. The honest test for a legitimate refactor is not "this feels better" but "the next concrete change will be materially easier because of this one." If you cannot name the next change, stop — you are rearranging, not refactoring, and the safest rearrangement is none.

Workflow