refactoring

Guides behavior-preserving code refactoring with proof contracts and incremental safe steps.

1|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/kreek/consult --skill refactoring-kreek
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: refactoring
Source: https://github.com/kreek/consult/tree/main/plugin/skills/refactoring
Command: npx skills add https://github.com/kreek/consult --skill refactoring-kreek

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Refactoring often breaks working code because structural changes get mixed with behavior changes, preservation claims go unverified, and big-bang rewrites leave the system unshippable. This Skill enforces a disciplined process where every refactor keeps tests green and every preservation claim is backed by evidence. ## Core Features & Use Cases - Structural/Behavioral Separation: Enforces the rule that every commit is either structural or behavioral, never both, so changes stay reviewable and reversible. - Proof Contracts: Requires each behavior-preservation claim to name the unchanged behavior, invariant, public boundary, and before/after evidence, adding characterization tests where coverage is missing. - Safe Migration Patterns: Guides parallel change (expand, migrate, contract), branch by abstraction, rename maps, and verified deletion of old paths instead of big-bang rewrites. - Use Case: When extracting a module from a legacy codebase, the Skill walks you through naming the coupling being separated, writing characterization tests, migrating callers incrementally, and proving no traffic remains on the old path before deleting it. ## Quick Start Use the refactoring skill to plan a safe, behavior-preserving refactor of the legacy payment module with characterization tests and incremental commits.

Frequently Asked Questions about refactoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor legacy code without breaking behavior?▼

Keep tests green before and after each step, and never mix structural and behavioral changes in one commit. Add characterization tests where coverage is missing, and back every preservation claim with a proof contract naming the unchanged behavior and evidence.

How to safely rename or migrate a public interface?▼

Use parallel change: expand the interface, migrate callers, then contract. Write a rename map separating private symbols, file paths, runtime keys, and persisted names, and verify all callers and traffic have moved before deleting old paths.

When should I avoid a big-bang rewrite?▼

Avoid rewrites unless the scope is small, disposable, and explicitly approved. Instead take the next safe slice or use branch by abstraction so the system stays shippable at every commit.

When should I not use the refactoring skill?▼

Do not use it for behavior-first feature work, which belongs to the proof skill, or for commit grouping and history surgery after changes exist, which belongs to the commit or git-workflow skills.

Why is shorter code not always simpler during refactoring?▼

Shorter code is simpler only when it hides no state, side effects, compatibility shims, ownership changes, or independent behavior. Simplification must name the cost being removed, such as hidden mutable state or a duplicated rule with divergent meaning.