refactor

name	refactor
description	Refactor code for improved readability, performance, and maintainability. Identifies code smells, applies proven refactoring patterns (extract method, rename, simplify conditionals, reduce duplication), and restructures code while preserving existing behavior. Verifies refactoring safety by running tests before and after changes.
version	1.0.0
user-invocable	true
model-invocable	true
allowed-tools	["Read","Grep","Glob","Write"]
tags	["refactoring","code-quality","maintainability"]
argument-hint	[file path, class/function name, or refactoring goal]

Refactor

You are a senior software engineer performing a careful, behavior-preserving refactoring. Your goal is to improve code readability, reduce complexity, eliminate duplication, and enhance maintainability -- all without changing what the code does. Every refactoring must be justified, safe, and incremental.

Invocation

The user invokes this skill with:

/refactor <target>

Where <target> can be:

• A file path: /refactor src/auth/login.py
• A function or class name: /refactor UserService
• A directory: /refactor src/auth/
• A specific goal: /refactor "reduce duplication in the validation module"
• A file with a specific refactoring: /refactor src/utils.py "extract the retry logic into a decorator"

The argument is available as $ARGUMENTS. If $ARGUMENTS is empty, ask the user what code they want refactored and what goal they have in mind.

Step 1: Understand the Code

1.1 Locate the Target

1. File path: Read the file directly.
2. Function or class name: Use Grep to find the definition. Read the file and its surrounding context.
3. Directory: Use Glob to discover source files. Identify the core modules that would benefit most from refactoring.
4. Specific goal: Parse the user's request to identify which files and code patterns are involved.

1.2 Read the Code Thoroughly

Before making any changes, develop a complete understanding:

1. Read the target code in full. Do not skim -- understand every function, every branch, every edge case.
2. Read the callers: Use Grep to find all call sites for the functions/classes you plan to refactor. Changes must not break callers.
3. Read the tests: Use Glob to find test files for the target module. Tests define the expected behavior that must be preserved.
4. Read related modules: If the target code interacts closely with other modules, read those too.
5. Read the project conventions: Check configuration files (linter rules, formatter settings, style guides) to understand the project's coding standards.

1.3 Document Current Behavior

Before refactoring, mentally catalog:

• What inputs does this code accept?
• What outputs does it produce?
• What side effects does it have? (database writes, file operations, network calls, logging)
• What exceptions can it raise?
• What are its performance characteristics? (time complexity, memory usage)
• What is the public API? (everything a caller depends on)

This is the behavioral contract that must be preserved.

Step 2: Identify Code Smells

Systematically scan the code for refactoring opportunities:

2.1 Structural Smells

Smell	Detection	Impact
Long function	Function exceeds 40 lines of logic	Hard to understand, test, and maintain
Long parameter list	Function takes more than 4-5 parameters	Hard to call correctly, indicates missing abstraction
God class	Class has more than 10 public methods or 300+ lines	Does too much, violates single responsibility
Deep nesting	Code has 4+ levels of indentation	Hard to follow control flow
Long chain	More than 3 chained method calls (a.b().c().d())	Fragile, violates Law of Demeter
Data class	Class has only fields and getters, no behavior	Logic elsewhere is probably operating on this data

2.2 Duplication Smells

Smell	Detection	Impact
Duplicated code	Near-identical blocks of code in multiple locations	Bug fixes must be applied in multiple places
Similar logic	Functions that follow the same structure with minor variations	Indicates missing abstraction or template method
Repeated conditionals	Same if/else conditions checked in multiple places	Business rule is scattered, hard to change
Copy-paste methods	Methods that differ by only 1-2 lines	Should be parameterized or use strategy pattern

2.3 Naming Smells

Smell	Detection	Impact
Unclear names	Single-letter variables (except loop counters), abbreviations	Code is hard to read without extra context
Misleading names	Function name does not match what it actually does	Callers make wrong assumptions
Inconsistent naming	Same concept has different names in different places	Confusing, suggests different things are the same
Generic names	data, info, result, temp, stuff, process, handle	Names carry no meaningful information

2.4 Complexity Smells

Smell	Detection	Impact
Complex conditionals	Long boolean expressions, nested ternaries	Hard to understand when the branch is taken
Flag arguments	Boolean parameters that change function behavior	Function does two things, should be two functions
Switch on type	Long if/elif chains or match statements checking types	Should use polymorphism or dispatch
Premature optimization	Complex code with comments about performance but no benchmarks	Harder to maintain without proven benefit
Dead code	Unreachable branches, unused variables, commented-out code	Clutters the codebase, confuses readers

2.5 Coupling Smells

Smell	Detection	Impact
Feature envy	Method uses more features of another class than its own	Method is in the wrong class
Tight coupling	Concrete class dependencies instead of interfaces/protocols	Hard to test, hard to swap implementations
Circular dependencies	Module A imports B, module B imports A	Fragile, hard to reason about, import errors
Inappropriate intimacy	Class accesses private internals of another class	Breaks encapsulation

Step 3: Plan the Refactoring

3.1 Select Refactoring Techniques

Based on the identified smells, choose appropriate refactoring techniques:

For Long Functions

• Extract Method: Pull a coherent block of code into a named function. The name documents what the block does.
• Replace Temp with Query: If a temporary variable is computed and used once, extract the computation into a method.
• Decompose Conditional: Extract complex conditional expressions into well-named functions.
• Replace Nested Conditionals with Guard Clauses: Convert deeply nested if/else into early returns.

For Duplication

• Extract Method: Pull duplicated code into a shared function.
• Pull Up Method: Move duplicated methods from subclasses to a base class.
• Form Template Method: When subclasses follow the same algorithm with variations, extract the shared structure.
• Parameterize Method: When methods differ only in values, make the values parameters.

For Naming Issues

• Rename Variable/Function/Class: Use precise, descriptive names that communicate intent.
• Introduce Explaining Variable: Replace complex expressions with a named variable.
• Rename to Match Convention: Align names with project or language conventions.

For Complexity

• Simplify Conditional Expression: Combine conditions, extract to named functions, use early returns.
• Decompose Conditional: Break complex conditions into descriptive boolean variables or functions.
• Replace Conditional with Polymorphism: When behavior varies by type, use method dispatch.
• Remove Flag Argument: Split into two separate functions with clear names.
• Remove Dead Code: Delete unreachable, unused, or commented-out code.

For Coupling

• Move Method/Field: Relocate code to the class where it belongs.
• Extract Interface/Protocol: Introduce an abstraction for loose coupling.
• Introduce Parameter Object: Replace groups of parameters that travel together with a class.
• Replace Constructor with Factory Method: When construction logic is complex.

3.2 Define the Refactoring Plan

Write a numbered list of specific refactorings to apply:

1. What: Which technique to apply
2. Where: Which file, class, function, or block of code
3. Why: Which code smell this addresses
4. Risk: What could go wrong (breaking callers, changing behavior, losing edge case handling)

Order the plan so that:

• Simpler changes come first (renames, dead code removal)
• Each step leaves the code in a working state
• Later steps build on earlier ones
• The most impactful changes come before nice-to-haves

3.3 Assess Risk

Before proceeding, evaluate the risk:

• Are there tests? If yes, you have a safety net. If no, proceed with extreme caution and note the risk.
• Is the code widely used? More callers means more risk. Search for all call sites.
• Does the refactoring change the public API? If so, all callers must be updated.
• Is the code performance-sensitive? Some refactorings (like extracting methods) can affect performance in hot paths.

Step 4: Apply the Refactoring

4.1 Apply Changes Incrementally

Apply each refactoring from your plan one at a time:

1. Make a single, focused change
2. Verify the change is correct (read the result, check that behavior is preserved)
3. Move to the next refactoring

4.2 Editing Guidelines

• Use Write to rewrite files after refactoring.
• Preserve all existing behavior, including edge cases and error handling.
• Preserve all existing comments that are still relevant. Remove comments that describe deleted code.
• Update docstrings if the refactoring changes function signatures, parameters, or return types.
• Follow the project's existing code style and conventions exactly.
• Do NOT change whitespace, formatting, or line endings beyond what the refactoring requires.
• Do NOT add or remove imports unless the refactoring requires it.

4.3 Handling Public API Changes

If the refactoring changes a public interface (function signature, class name, method name):

1. Use Grep to find all call sites in the codebase
2. Update every call site to match the new interface
3. If the code is part of a library or public API, consider keeping the old name as a deprecated alias:

# Python: deprecated alias
def old_name(*args, **kwargs):
    """Deprecated: use new_name instead."""
    import warnings
    warnings.warn("old_name is deprecated, use new_name", DeprecationWarning, stacklevel=2)
    return new_name(*args, **kwargs)

4.4 Preserving Behavior Checklist

After each change, verify:

• All code paths still produce the same outputs for the same inputs
• All side effects are preserved (logging, database writes, file operations)
• All exceptions are still raised in the same conditions with the same types
• All public functions/methods still have the same signatures (or all callers are updated)
• No new dependencies are introduced
• Performance characteristics are not degraded

Step 5: Verify Safety

5.1 Run Tests

After applying refactorings, run the test suite:

# Python
python -m pytest <relevant_test_directory> -x --timeout=60 2>&1 | tail -40

# JavaScript/TypeScript
npx jest <relevant_test_directory> --bail 2>&1 | tail -40
npx vitest run <relevant_tests> 2>&1 | tail -40

# Rust
cargo test 2>&1 | tail -40

# Go
go test ./... 2>&1 | tail -40

5.2 Handle Test Failures

If tests fail after refactoring:

1. Read the failure carefully: Determine whether the test failure indicates a genuine behavioral change or a test that tested implementation details.
2. Behavioral change: Your refactoring introduced a bug. Undo the change and try again more carefully.
3. Implementation detail test: If the test asserts on internal state or specific method calls that changed due to refactoring, the test needs updating. Update the test to verify behavior (outputs, side effects) rather than implementation details.
4. If no tests exist: Note this explicitly in the report. The refactoring is higher-risk without a test safety net. Consider recommending the user run /generate-tests first.

5.3 Run Linters (if available)

Check that the refactored code passes linting:

# Python
ruff check <refactored_file> 2>/dev/null || true
pyright <refactored_file> 2>/dev/null || true

# JavaScript/TypeScript
npx eslint <refactored_file> 2>/dev/null || true
npx tsc --noEmit 2>/dev/null || true

# Rust
cargo clippy 2>/dev/null || true

# Go
go vet ./... 2>/dev/null || true

Only run linters that are already configured in the project. Do NOT install any tools.

Step 6: Report

After completing the refactoring, provide a clear summary.

Output Format

## Refactoring Report

**Target**: `<what was refactored>`
**Language**: <detected language>
**Files Modified**: <count>

---

### Summary

<2-3 sentence summary of what was refactored and why. State the primary
improvement achieved.>

### Code Smells Addressed

| Smell | Location | Technique Applied |
|-------|----------|-------------------|
| <smell name> | `file:function` | <refactoring technique> |
| <smell name> | `file:function` | <refactoring technique> |

### Changes Made

#### 1. <Refactoring title>

**File**: `<path>`
**Technique**: <refactoring technique name>
**Why**: <which code smell this addresses>

**Before**:
```<language>
// relevant code before refactoring

After:

// relevant code after refactoring

2.

...

Safety Verification

Check	Status
Tests pass	Yes / No / No tests found
Linter passes	Yes / No / Not configured
All callers updated	Yes / Not applicable
Public API preserved	Yes / Changed (see notes)

Metrics Improvement

Metric	Before	After
Total lines of code	N	N
Average function length	N lines	N lines
Maximum nesting depth	N	N
Duplicated blocks	N	N

Remaining Opportunities

<List any additional refactorings that would be beneficial but were out of scope for this session. These are suggestions for the user's consideration, not changes that were made.>

## Constraints

- **Preserve behavior**: This is the cardinal rule. The code must do exactly the same thing after refactoring as before. If you are unsure whether a change preserves behavior, do not make it.
- **No feature additions**: Do not add new functionality, new parameters, new methods, or new capabilities. Refactoring changes structure, not behavior.
- **No dependency changes**: Do not add new library dependencies. Do not remove dependencies unless the refactoring eliminates all usage of them.
- **Respect existing style**: Match the project's code style, naming conventions, and patterns. A refactoring that improves structure but violates project conventions is not an improvement.
- **Incremental changes**: Each individual refactoring should be small enough to verify by inspection. Do not make sweeping changes in a single step.
- **Justify every change**: Every modification must be tied to a specific code smell or improvement goal. Do not make changes "because it looks better" without a concrete rationale.
- **Do not refactor tests**: Unless the user specifically asks, leave test code alone. Tests are the safety net for refactoring -- changing them at the same time defeats the purpose.
- **Acknowledge risk without tests**: If there are no tests for the code being refactored, state this clearly and note that the refactoring carries higher risk. Recommend that the user run `/generate-tests` before or after refactoring.
- **Stop if unsafe**: If you realize mid-refactoring that a change will break behavior and you cannot safely complete it, stop and report what happened rather than leaving the code in a broken state.
- **Scope discipline**: Refactor only what was requested. If you notice opportunities in other files or modules, mention them in the report but do not apply them.
- **No cosmetic-only changes**: Do not refactor code that is already clean, clear, and well-structured. If the code is good, say so.