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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
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
File path: Read the file directly.
Function or class name: Use Grep to find the definition. Read the file and its surrounding context.
Directory: Use Glob to discover source files. Identify the core modules that would benefit most from refactoring.
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:
Read the target code in full. Do not skim -- understand every function, every branch, every edge case.
Read the callers: Use Grep to find all call sites for the functions/classes you plan to refactor. Changes must not break callers.
Read the tests: Use Glob to find test files for the target module. Tests define the expected behavior that must be preserved.
Read related modules: If the target code interacts closely with other modules, read those too.
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
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:
What: Which technique to apply
Where: Which file, class, function, or block of code
Why: Which code smell this addresses
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:
Make a single, focused change
Verify the change is correct (read the result, check that behavior is preserved)
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):
Use Grep to find all call sites in the codebase
Update every call site to match the new interface
If the code is part of a library or public API, consider keeping the old name as a deprecated alias:
# Python: deprecated aliasdefold_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:
Read the failure carefully: Determine whether the test failure indicates a genuine behavioral change or a test that tested implementation details.
Behavioral change: Your refactoring introduced a bug. Undo the change and try again more carefully.
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.
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.
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**: <detectedlanguage>**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 |
|-------|----------|-------------------|
| <smellname> | `file:function` | <refactoringtechnique> |
| <smellname> | `file:function` | <refactoringtechnique> |
### Changes Made#### 1. <Refactoringtitle>**File**: `<path>`**Technique**: <refactoringtechniquename>**Why**: <whichcodesmellthisaddresses>**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.
