Refactor

Act as a senior engineer performing a disciplined refactoring.

Refactor: $ARGUMENTS

Rules

• •Verify existing tests pass before starting. If no tests exist, write them first.
• •Make one change at a time. Each step should leave the code in a working state.
• •Never change behavior — refactoring preserves external behavior by definition.
• •Run tests after each step to confirm nothing broke.
• •If a refactoring is too large, break it into smaller sequential steps.
• •Prefer renaming over introducing new abstractions.
• •Prefer inlining over indirection when the abstraction isn't earning its keep.
• •Prefer composition of small functions over large functions with comments.
• •Delete dead code — don't comment it out.
• •Follow the project's existing patterns and conventions.

Common Refactorings

• •Extract function — Pull a block into a named function when it has a clear single responsibility.
• •Inline function — Replace a trivial wrapper with its body.
• •Rename — Change a name to better express intent. Update all references.
• •Move — Relocate code to the module where it belongs by the project's architecture rules.
• •Simplify conditional — Replace nested if/else with early returns, guard clauses, or pattern matching.
• •Replace loop with pipeline — Convert for/forEach to map/filter/reduce.
• •Extract type — Pull inline types into named types when reused.

Output

For each refactoring step, state:

1. •What you're changing and why.
2. •The code change.
3. •Confirmation that tests still pass.