Refactor
CLI for managing AI agent skills — install, create, and share reusable SKILL.md definitions with automatic script dependency resolution
npx -y skills add marco-souza/skills --skill refactorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Perform safe refactoring operations while preserving behavior and maintaining code integrity. Use when: renaming identifiers, extracting functions/modules, inlining code, moving files, or restructuring code without changing functionality. Do NOT use when: adding new features, fixing bugs (use standard editing), or making breaking API changes.
SKILL.md
7.4 KB, as published. Nobody here has run it
Refactor
Execute safe refactoring operations with verification at each step. Refactoring changes code structure without altering external behavior.
Core Principle
Preserve behavior. Every refactoring must pass tests before and after. If behavior changes, it's not refactoring—it's a rewrite.
Refactoring Operations
Rename
Rename variables, functions, classes, files, or directories while maintaining all references.
When to use:
- Identifier name is unclear or violates naming conventions
- Code review feedback on naming
- Aligning names with business domain
Steps:
- Find all occurrences (definitions + usages)
- Verify the scope (global vs local)
- Rename atomically (all at once)
- Run tests to confirm behavior unchanged
# Find all usages before renaming
grep -r "oldName" --include="*.ts" --include="*.js" --include="*.py"
Extract
Pull out a code block into a new function, method, class, or module.
When to use:
- Function is too long (>30 lines)
- Code block is duplicated elsewhere
- Logic can be reused in other contexts
- Improving readability by naming complex operations
Steps:
- Identify the code block to extract
- Determine inputs (parameters) and outputs (return value)
- Create the new function/module
- Replace original code with a call to the new function
- Verify tests still pass
Extraction targets:
- Function/method extraction
- Class extraction
- Module/file extraction
- Interface/type extraction
Inline
Replace a function call with the function body.
When to use:
- Function is trivial (one-liner)
- Function is called only once
- Indirection adds unnecessary complexity
- Making code easier to follow
Steps:
- Verify the function has no side effects
- Copy function body to call site
- Replace arguments with actual values
- Remove the now-unused function
- Run tests
Move
Relocate code to a more appropriate location in the codebase.
When to use:
- Code belongs in a different module/package
- Organizing by feature instead of type
- Reducing coupling between modules
- Aligning with project architecture
Steps:
- Identify the target location
- Update all import paths
- Ensure no circular dependencies
- Move the file/code
- Update tests and documentation
Safety Checklist
Before any refactoring, verify:
# 1. Ensure clean git state
git status
git stash # or commit work-in-progress
# 2. Run existing tests to establish baseline
# Pick the appropriate test command for your project
npm test 2>/dev/null || go test ./... 2>/dev/null || pytest 2>/dev/null || cargo test 2>/dev/null
# 3. Create a checkpoint
git checkout -b refactor/<description>
Pre-refactoring checklist:
- All tests pass on current code
- Git working directory is clean (or changes stashed)
- You understand the code's current behavior
- You've identified all usages of code being refactored
- You have a rollback plan (git)
Step-by-Step Workflow
Phase 1: Preparation
-
Understand current behavior
- Read the code thoroughly
- Run existing tests
- Note edge cases and dependencies
-
Plan the refactoring
- Choose the operation type (rename/extract/inline/move)
- Identify all affected files
- Estimate risk level
-
Set up safety net
# Ensure tests exist # If no tests, consider adding characterization tests first # Create refactoring branch git checkout -b refactor/<description>
Phase 2: Execution
-
Make the change incrementally
- One logical change per commit
- Small, reviewable steps
- Never mix refactoring with feature changes
-
Verify after each step
# Run tests npm test 2>/dev/null || go test ./... # Verify build succeeds npm run build 2>/dev/null || go build ./... -
Commit frequently
git add -A git commit -m "ref: <what changed>"
Phase 3: Verification
-
Run full test suite
# Comprehensive verification npm test 2>/dev/null && npm run lint 2>/dev/null -
Manual smoke test (if applicable)
- Start the application
- Verify critical paths work
- Check edge cases
-
Clean up
# Remove any dead code # Update documentation if needed # Merge or create PR
Common Patterns
Pattern: Extract Function
// Before
function processOrder(order: Order) {
// 50 lines of validation
// 30 lines of calculation
// 20 lines of persistence
}
// After
function processOrder(order: Order) {
const validated = validateOrder(order);
const calculated = calculateTotals(validated);
return persistOrder(calculated);
}
Pattern: Move to Module
# Before: utils.js has 500 lines
# After: Split into organized modules
mkdir -p src/utils/validation
mkdir -p src/utils/formatting
# Move validation functions
mv src/utils/validateUser.js src/utils/validation/
mv src/utils/validateOrder.js src/utils/validation/
# Update imports
find . -name "*.ts" -exec sed -i 's|from.*utils/validateUser|from../utils/validation/validateUser|g' {} \;
Pattern: Rename with IDE Support
# For large codebases, use language server
# TypeScript
npx tsserver --rename <file> <oldName> <newName>
# Or use find + sed for simpler cases
grep -rl "oldFunctionName" src/ | xargs sed -i 's/oldFunctionName/newFunctionName/g'
Edge Cases
Circular Dependencies
When moving code creates circular imports:
- Extract shared types/interfaces to a separate module
- Use dependency injection
- Create a facade module
Breaking Changes
If refactoring must change public API:
- Create new API alongside old
- Deprecate old API
- Migrate callers gradually
- Remove old API in future release
Large-Scale Refactoring
For codebase-wide changes:
- Script the change (sed, ast-grep, codemods)
- Run on entire codebase at once
- Commit as single atomic change
- Verify everything still works
Troubleshooting
Tests Fail After Refactoring
# 1. Check what changed
git diff HEAD~1
# 2. Verify test expectations
# Look for tests that assert implementation details
# 3. Consider if test needs updating (rare)
# Only if refactoring exposed test as brittle
Build Errors
# TypeScript: Check for missing imports
npx tsc --noEmit
# Go: Check for unused imports
goimports -l .
# General: Search for references to old names
grep -r "oldName" --include="*.ts" --include="*.js" --include="*.go"
Performance Regression
# Profile before and after
# Compare key metrics
# Ensure refactoring didn't introduce N+1 queries or unnecessary copies
Best Practices
- Small steps — One logical change per commit
- Tests first — Never refactor without passing tests
- Version control — Use branches for risky refactoring
- No behavior changes — Refactor only, then change behavior separately
- Document intent — Commit messages explain WHY, not WHAT
- Review carefully — Refactoring bugs are subtle
- Incremental rollout — For large changes, merge progressively