software-code-refactoring

Apply one refactoring at a time and run the test suite after each change. If a test fails, revert that specific refactoring immediately rather than modifying the test, since a failure means the transformation changed behavior.

In the refactor phase of red-green-refactor, keep the public API unchanged and focus on internal improvements like extracting duplicated logic, renaming unclear variables, and flattening nested conditionals. Verify compilation after each step and run the full test command at the end.

Yes, it works with any language or framework. It discovers the build system and conventions from files like Cargo.toml, package.json, or pyproject.toml, then uses the appropriate check command such as cargo check, tsc --noEmit, or py_compile.

The change that caused the failure is reverted immediately, and tests are re-run to confirm the revert is clean. The failed refactoring is recorded in the summary with an explanation of why it was unsafe, and a safer alternative may be applied instead.

No, public function signatures, type names, and module exports are never changed unless explicitly requested. Only internal restructuring is performed, though beneficial public API changes can be noted as recommendations in the summary.

Skip refactoring when the code is already clean and follows codebase conventions, when changes would degrade readability, or when performance-sensitive hot paths could be affected. Unnecessary changes add risk without measurable improvement.