refactor-safety

Guides behavior-preserving code refactors with characterization tests, atomic commits, and call-site verification.

2|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/FluxonLab/Skillry --skill refactor-safety-fluxonlab
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: refactor-safety
Source: https://github.com/FluxonLab/Skillry/tree/main/plugins/core-operations/skills/05-refactor-safety
Command: npx skills add https://github.com/FluxonLab/Skillry --skill refactor-safety-fluxonlab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Structural code changes often cause silent behavior regressions, scope creep, and untraceable bugs when moves, renames, and logic edits are mixed together. This Skill enforces a disciplined refactor process that locks in existing behavior with tests before any change and keeps every step independently verifiable and reversible. ## Core Features & Use Cases - Green baseline and characterization tests: Record pass/fail counts and coverage before touching code, and pin current behavior with tests committed first. - Atomic step sequencing: Split renames, file moves, signature changes, and logic edits into separate commits, re-running scoped tests after each one. - Call-site and hidden-consumer mapping: Find every caller with git grep, then check string literals, dynamic imports, mocks, fixtures, docs, and CI files that compilers miss. - Risk-tiered rigor: Calibrate the safety net from low-risk local renames up to critical ORM or auth migrations requiring feature flags and staged rollouts. - Use Case: When renaming an exported pricing function used across a package, map all call sites, commit the file move and symbol rename separately, verify each caller, and prove behavior is preserved with an identical before/after test result. ## Quick Start Ask the AI to refactor the pricing module by renaming calcPrice to priceCalculator while preserving behavior, following the refactor-safety procedure with a recorded test baseline and atomic commits.

Frequently Asked Questions about refactor-safety

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

FAQPage Schema
How do I refactor code safely without changing behavior?▼

Establish a green test baseline first, write characterization tests that pin current outputs, then apply changes as atomic commits (move, rename, signature, logic separately) with tests re-run after each step. The before and after suite results must be identical to prove behavior was preserved.

What are characterization tests in refactoring?▼

Characterization tests call the current function with realistic inputs and assert the current output, even if it looks wrong. They pin the existing contract before changes and are committed first, then cleaned up once proper unit tests exist for the new structure.

When should I rewrite code instead of refactoring it?▼

Choose a rewrite when the code has no tests, depends on a discontinued library, or its control flow cannot be reasoned about. If you cannot predict the current output well enough to write a characterization test, rewrite against a spec behind a feature flag instead.

How do I find all callers of a function before renaming it?▼

Use git grep or IDE find-usages to list static call sites, then separately search string literals, dynamic require/import expressions, mocks, fixtures, config files, and CI workflow YAML. Compilers and IDEs miss reflection-based and string-keyed consumers.

Why should a rename and a logic change be separate commits?▼

Combining a move or rename with logic edits makes git bisect useless because you cannot tell which change introduced a regression. Atomic commits keep each step independently verifiable and give you a clean rollback path.

When is a full refactor safety process not needed?▼

Skip it for one-line changes in fully-tested leaf functions with no external callers, throwaway prototype code, or bug fixes where behavior must intentionally change. Also stop if you cannot run the test suite, since refactoring without a safety net is a rewrite.