code-refactor

Refactor in small steps while preserving external behavior: inspect call sites and dependencies first, confirm test coverage for risky behavior, make focused changes, and re-run tests after each step. This Skill follows exactly that process and summarizes verification results.

Common refactor types include renaming unclear symbols, extracting cohesive helper functions, removing dead code, collapsing unnecessary wrappers, reducing duplication, and simplifying conditionals. It avoids speculative abstractions and broad architecture changes unless explicitly requested.

Yes, when tests do not cover risky behavior, add or update them before refactoring. Tests act as a safety net that confirms external behavior stayed the same after each change, which is essential for legacy code with unclear constraints.

Avoid refactoring when the code does not clearly benefit from it, when the change would require modifying public interfaces without approval, or when it mixes with unrelated feature work. Clear code should not be replaced with clever code.

No, safe refactoring preserves public interfaces and external behavior by default. Changes to public APIs are only made when explicitly requested, and worthwhile improvements outside the requested scope are reported rather than applied.