| name | refactor |
| description | Guided refactoring workflow for improving existing code without changing behavior. Ensures tests pass before and after changes. |
| user-invocable | true |
Refactor Skill
You are facilitating the Refactoring process. Your role is to guide code improvement while preserving existing behavior.
Purpose
Refactoring ensures:
- Code quality improves without behavior changes
- Tests verify functionality stays intact
- Changes are incremental and reversible
- Documentation reflects the new structure
Refactoring Flow
IDENTIFY TARGET -> TEST BASELINE -> PLAN CHANGES -> INCREMENTAL REFACTOR -> VERIFY -> COMPLETE
Refactoring Principles
Key Rules
- Test First: All existing tests must pass before starting
- Small Steps: Each change should be small and reversible
- Behavior Preserved: Functionality must not change
- Run Tests Often: Verify after each step
Red-Green-Refactor Cycle
1. Ensure tests pass (GREEN)
2. Make a small refactor
3. Run tests (should stay GREEN)
4. If tests fail (RED), revert and try smaller change
5. Repeat until refactor complete
Workflow
Phase 1: Identify Target
- Parse the refactoring request
- Identify target files/modules
- Document current structure
- List what needs improvement
Phase 2: Test Baseline
- Run all existing tests
- Document test coverage
- Identify any failing tests (fix first)
- Create baseline test results
IMPORTANT: If tests don't pass, fix them before refactoring.
Phase 3: Plan Changes
Create refactoring plan with:
- Specific changes to make
- Order of changes (dependencies)
- Risk level for each change
- Rollback points
Phase 4: Incremental Refactor
For each change:
- Make the smallest possible change
- Run tests immediately
- Commit if tests pass
- Document the change
Phase 5: Verify
- Run full test suite
- Check coverage hasn't decreased
- Verify behavior unchanged
- Check performance impact
Phase 6: Complete
- Update documentation
- Clean up any temporary code
- Final commit
- Report results
Refactor Plan Template
# Refactor Plan: [Target]
## Objective
[What improvement is being made]
## Target Files
- [File 1]
- [File 2]
## Test Baseline
- Tests passing: [count]/[total]
- Coverage: [percentage]
## Changes Planned
### Change 1: [Name]
- **File**: [path]
- **Description**: [what change]
- **Risk**: Low/Medium/High
- **Depends on**: [previous change ID or "none"]
### Change 2: [Name]
- **File**: [path]
- **Description**: [what change]
- **Risk**: Low/Medium/High
- **Depends on**: Change 1
## Rollback Points
- [Commit ID]: [description of what was complete]
## Verification Steps
1. [Verification step 1]
2. [Verification step 2]
## Expected Outcome
[What the code will look like after]
## Status
DRAFT | TESTING | IN_PROGRESS | VERIFYING | COMPLETE
Common Refactoring Patterns
Extract Function
def process_order(order):
def process_order(order):
validate_order(order)
calculate_totals(order)
save_order(order)
Extract Class
class User:
class User:
class UserAuth:
class UserNotifications:
Rename for Clarity
def calc(x, y):
return x * y + 10
def calculate_adjusted_price(base_price, quantity):
return base_price * quantity + SERVICE_FEE
Reduce Duplication
def validate_email(email):
if not email or '@' not in email:
return False
return True
def validate_phone(phone):
if not phone or len(phone) < 10:
return False
return True
def validate_required(value, rules):
if not value:
return False
for rule in rules:
if not rule(value):
return False
return True
Risk Levels
| Risk | Description | Approach |
|---|
| Low | Localized, simple change | Single commit |
| Medium | Multiple files, same patterns | Small commits, frequent tests |
| High | Complex changes, many files | Very small steps, checkpoints |
Anti-Patterns to Avoid
- Big Bang Refactor: Changing everything at once
- Refactor Without Tests: No safety net
- Mixed Refactor + Feature: Changing behavior during refactor
- Skip Verification: Not running tests after each change
Usage
/refactor [target] [objective]
Example:
/refactor src/backend/services/user_service.py extract authentication logic
Coordination
- Domain-specific refactors: Domain lead approval
- Cross-domain refactors: architect-lead approval
- Breaking internal APIs: Both leads must approve
- Database schema refactor: backend-lead + database-dev