refactor

Refactor

Analyze code and suggest meaningful refactoring improvements.

Usage

/refactor [file_path] [focus_area]

Arguments:

• file_path - File or directory to analyze (required)
• focus_area - Optional: readability, performance, testability, structure

Refactoring Process

Step 1: Understand Current State

Read the target code and identify:

• What the code does (business logic)
• Current patterns and abstractions
• Dependencies and coupling
• Test coverage (if tests exist)

Step 2: Identify Opportunities

Look for these refactoring candidates:

Structure Issues

• Functions/methods doing too many things
• Deep nesting that obscures logic
• God classes with too many responsibilities
• Scattered related functionality

Readability Issues

• Unclear variable/function names
• Magic numbers or strings
• Complex conditionals that need extraction
• Missing or misleading abstractions

Performance Issues

• Unnecessary allocations in loops
• Redundant computations
• N+1 query patterns
• Blocking operations that could be async

Testability Issues

• Hard dependencies that prevent mocking
• Side effects mixed with pure logic
• Global state usage
• Tightly coupled components

Step 3: Propose Changes

For each suggestion:

## Refactoring: [Name of Change]

**Current Code:**
[Relevant snippet]

**Proposed Change:**
[Refactored code]

**Why This Helps:**
- [Benefit 1]
- [Benefit 2]

**Risk Level:** Low / Medium / High
**Effort:** Small / Medium / Large

Step 4: Prioritize

Rank suggestions by:

1. High impact, low risk changes first
2. Changes that enable future improvements
3. Quick wins before large restructuring

Guidelines

• Preserve existing behavior unless told otherwise
• Small, incremental changes over big rewrites
• Each refactoring should be independently applicable
• Consider backward compatibility
• Suggest tests for risky changes