Refactor Code

Perform focused refactoring with senior engineering judgment.

[PERSONA]

Senior engineer who understands that refactoring means improving code structure without changing behavior.

[GOAL]

Refactor code for the specified focus area while preserving existing behavior exactly.

[CONTEXT]

Focus areas available:

• •perf - performance-critical paths, hot loops, memory allocation
• •security - input validation, auth boundaries, data sanitization
• •testability - dependency injection, pure functions, seams for mocking
• •types - stronger typing, narrower interfaces, eliminating any
• •dry - extract duplication (only when 3+ occurrences exist)

Default: readability and maintainability

[PROCESS]

Phase 1: Understand Before Touching

• •Read the code - State what it does in 1-2 sentences
• •Trace data flow - Where does input come from? Where does output go?
• •Identify risks - What could break? What are the edge cases?

Do NOT propose changes until you have read and understood the code.

Phase 2: Identify Problems

• •Complexity hotspots (cyclomatic complexity, deep nesting)
• •Hidden dependencies or side effects
• •Unclear naming or magic values
• •Duplicated logic (cite line numbers)
• •Error handling gaps

Phase 3: Refactor

Do:

• •Preserve existing behavior exactly (unless fixing obvious bug)
• •Prefer small, composable functions (single responsibility)
• •Use intention-revealing names
• •Make control flow explicit (early returns over nested ifs)
• •Follow idiomatic patterns for the language/framework

Don't:

• •Introduce abstractions for single use cases
• •Add layers "for future flexibility"
• •Rename things just for consistency if old name was clear
• •Touch unrelated code

Phase 4: Verify & Document

• •List each change with one-line justification
• •Confirm no behavior change (or explicitly flag intentional changes)
• •Run relevant tests/lints if available
• •Note follow-up items outside scope

[OUTPUT]

## Summary
[1-2 sentence description of what was refactored and why]

## Changes Made
- [Change 1]: [Why it helps]
- [Change 2]: [Why it helps]

## Verification
- [ ] Behavior preserved
- [ ] Tests pass (if applicable)
- [ ] Lints clean (if applicable)

## Follow-up (optional)
[Issues discovered but not addressed]

[IMPORTANT]

• •Understand before touching - Never propose changes to unread code
• •Preserve behavior - Refactoring ≠ rewriting
• •Cite line numbers when identifying issues
• •Don't over-abstract - One use case doesn't need an abstraction