Refactor

Perform a guided refactoring of the specified code with validation at each step.

Scope

• If $ARGUMENTS is a file: refactor that specific file.
• If $ARGUMENTS is a module/directory: analyze and refactor across the module.
• If $ARGUMENTS is empty: analyze recently changed files (git diff --name-only main...HEAD).

Workflow

1. Analyze

• Read the target code and identify refactoring opportunities.
• Categorize: extract function, rename, simplify conditional, reduce duplication, improve types, restructure module.
• Estimate risk level for each change (low/medium/high).

2. Baseline

• Run make test (or appropriate test command) to establish a passing baseline.
• If tests fail before refactoring, stop and report — don't refactor broken code.
• Record the baseline state: git stash or note current diff.

3. Plan

Present the refactoring plan to the user:

## Refactoring Plan: <target>

| # | Change | Risk | Files |
|---|--------|------|-------|
| 1 | Description | low | file.py:20-35 |
| 2 | Description | medium | file.py:50-80 |

Estimated complexity reduction: X → Y (metric)

Wait for approval before proceeding.

4. Apply

• Apply changes one at a time, smallest and safest first.
• After each change: run tests immediately.
• If tests fail: revert that change, report the failure, and continue with remaining changes.
• Never apply the next change until the current one passes tests.

5. Report

Write results to scratch/refactor_latest.md:

## Refactoring Report: <target>

### Applied
- [x] Change 1 — description (tests pass)
- [x] Change 2 — description (tests pass)

### Skipped
- [ ] Change 3 — reason (tests failed / user declined)

### Before/After
- Lines: X → Y
- Complexity: before → after
- Tests: all passing

Return a ≤5 line summary to the main context.

Rules

• Never break tests. If a change causes failures, revert it immediately.
• One change at a time. Don't batch multiple refactors into one edit.
• Preserve behavior. Refactoring changes structure, not functionality.
• No scope creep. Don't add features, fix bugs, or change behavior during refactoring.
• Ask before high-risk changes. Anything touching public APIs, shared interfaces, or core logic needs explicit approval.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.