Proactively monitors file sizes and suggests refactoring BEFORE editing. Auto-invoked when files exceed size thresholds (150/200/300 lines) or complexity patterns detected. Works across JavaScript/TypeScript, Python, and general codebases. Prevents accidental complexity growth.
Resources
10Install
npx skillscat add womendefiningai/claude-code-skills/code-refactoring Install via the SkillsCat registry.
Code Refactoring Skill
๐ฏ Purpose: Prevent Complexity Before It Becomes a Problem
Problem this solves: "I rarely know when to refactor, typically get caught by accident"
Solution: AI proactively monitors file sizes and complexity patterns, alerting you BEFORE making changes that would worsen the problem.
Works with: JavaScript/TypeScript (React, Node), Python, and general codebases.
๐ CRITICAL FIRST STEP: Check for File Watcher Alerts
BEFORE doing anything else when this skill is invoked, ALWAYS check for unread alerts from the background file watcher:
node ~/.claude/plugins/marketplaces/custom-skills/code-refactoring/scripts/check-alerts.jsWhy this is critical:
- The file watcher runs in the background monitoring code file sizes
- It writes alerts to
watcher-alerts.jsonwhen files are edited and exceed thresholds - These alerts tell you which files the user just edited that need refactoring attention
- You must check these alerts FIRST to provide real-time feedback
If alerts exist:
- Display the alerts using the check-alerts.js script output
- Ask the user if they want help refactoring the alerted files NOW or LATER
- Then proceed with the rest of the skill workflow
If no alerts:
- Continue with normal skill workflow (checking file sizes manually, etc.)
User can also manually check alerts with: /check-refactor-alerts
๐ค AUTO-INVOKE CONDITIONS (AI Should Check These)
1. Before Editing Files (PREVENTIVE)
When AI is about to edit a file, check size first:
# Check file size before editing
wc -l [target-file]
# If result:
# 150-200 lines โ โ ๏ธ WARN: Getting large, plan extraction
# 200-300 lines โ ๐จ ALERT: Should split before adding more
# 300+ lines โ ๐ STOP: Must refactor before editingExample workflow:
User: "Add new feature to UserProfile.tsx"
AI: *Before editing, checks file size*
AI: *Sees 280 lines*
AI: *Auto-invokes code-refactoring skill*
Skill: "๐จ UserProfile.tsx is 280 lines. Before adding features:
- Extract data to separate file
- Split modal into separate component
- Then add new feature safely"2. During File Creation (PROACTIVE)
While creating new code file, track size:
- At 100 lines โ โ Good, continue
- At 150 lines โ โ ๏ธ Pause, suggest structure
- At 200 lines โ ๐จ Stop, extract now
Example workflow:
AI: *Creating new DashboardService.py*
AI: *Reaches 150 lines*
AI: *Auto-invokes code-refactoring skill*
Skill: "โ ๏ธ File reached 150 lines. Before continuing:
1. Extract data/config to constants file
2. Move helper functions to utils module
3. Continue with cleaner structure"3. After Reading Files (REACTIVE)
When AI reads a file and discovers size issues:
# After reading, if file >300 lines, suggest refactor
wc -l filename
# If >300 lines, proactively suggest refactor BEFORE user asks for changesExample workflow:
User: "Take a look at the analytics module"
AI: *Reads analytics.py*
AI: *Sees 450 lines*
AI: *Auto-invokes code-refactoring skill*
Skill: "๐ analytics.py is 450 lines (150 lines over limit).
Refactor plan:
1. Extract constants to analytics_config.py (50 lines)
2. Create AnalyticsChart class (100 lines)
3. Create AnalyticsProcessor class (120 lines)
4. Keep Analytics as orchestrator (180 lines)
Should I proceed with refactoring before making other changes?"4. Pattern Detection (AUTOMATIC)
AI should automatically detect these patterns and invoke skill:
Universal Patterns (All Languages)
- โ Large data structures (>20 lines) โ Suggest separate config/data file
- โ Complex conditionals (5+ branches) โ Suggest strategy pattern or dispatch table
- โ Deeply nested logic (>3 levels) โ Suggest extraction
- โ Repeated code blocks โ Suggest function/method extraction
- โ Long parameter lists (>5 params) โ Suggest config object or builder pattern
JavaScript/TypeScript/React Patterns
- โ 5+ data items hardcoded โ Suggest data file extraction
- โ 4+ useState/useEffect hooks โ Suggest custom hook extraction
- โ Modal/Dialog code โ Suggest separate component
- โ Complex form (10+ fields) โ Suggest separate form component
- โ Large switch statements โ Suggest lookup table or component map
Python Patterns
- โ Class >300 lines โ Suggest splitting into multiple classes
- โ Function >50 lines โ Suggest breaking into smaller functions
- โ Module >500 lines โ Suggest splitting into package
- โ Too many methods (>15) โ Suggest composition or mixins
- โ Complex init (>20 lines) โ Suggest factory method or builder
๐ File Size Guidelines (Language-Specific)
JavaScript/TypeScript/React Components
- 100-200 lines: โ Perfect for most components
- 200-300 lines: โ ๏ธ Good for complex components, watch closely
- 300+ lines: ๐ MUST split into logical sub-components
Python Modules
- 150-250 lines: โ Good module size
- 250-400 lines: โ ๏ธ Consider splitting by responsibility
- 400+ lines: ๐ Split into multiple modules or package
Python Classes
- 100-200 lines: โ Well-focused class
- 200-300 lines: โ ๏ธ Check single responsibility principle
- 300+ lines: ๐ Split into multiple classes or use composition
General Files (Any Language)
- 150-250 lines: โ Maintainable size
- 250-400 lines: โ ๏ธ Getting complex
- 400+ lines: ๐ Refactor needed
๐ Refactoring Analysis Template
When skill is invoked, provide this analysis:
## Code Refactoring Analysis: [Filename]
**Current State:** [X] lines - [โ
Good / โ ๏ธ Warning / ๐ Critical]
**Identified Issues:**
- File size issues (>200 or >300 lines)
- Complex nested logic / too many responsibilities
- Language-specific patterns (hooks, data arrays, classes, etc.)
**Refactoring Recommendations:**
1. Extract [what] to [new-file] (saves [X] lines, [X] mins)
2. Extract [what] to [new-file] (saves [X] lines, [X] mins)
**Result:** Main file โ [target] lines | Risk: [Low/Med/High] | Time: [X] mins
**Proceed?** [Yes/No/Later/Review]For complete template with all fields, see FORMS.md
๐จ Automatic Splitting Triggers
When ANY of these conditions occur, AUTO-INVOKE this skill:
Universal Triggers (All Languages)
- โ File reaches 150 lines โ Suggest extraction points
- โ File reaches 200 lines โ Alert and plan refactor
- โ File reaches 300 lines โ Stop and refactor first
- โ Complex nested logic detected
- โ Repeated code patterns found
JavaScript/TypeScript Triggers
- โ Component reaches 150 lines โ Extract next section
- โ 3+ useState hooks โ Extract to custom hook
- โ Large data array โ Move to data file immediately
- โ Modal/Dialog code โ Separate component from start
- โ Complex form โ Separate form component immediately
Python Triggers
- โ Class reaches 250 lines โ Plan class split
- โ Function reaches 40 lines โ Suggest breaking down
- โ Module reaches 350 lines โ Plan module split
- โ 10+ methods in class โ Consider composition
- โ Complex init โ Suggest factory pattern
๐ Quick Decision Matrix
When to extract what (Quick Reference):
JavaScript/TypeScript/React:
- Data file: 5+ items, arrays >20 lines, config objects
- Sub-component: Modal/dialog, complex list items, distinct UI sections
- Custom hook: 4+ useState, complex logic, reusable state
Python:
- Config file: 5+ variables, large data (>20 lines), magic numbers
- New class: Class >300 lines, multiple responsibilities, 10+ methods
- Utility function: Repeated logic, pure functions, generic operations
- New module: File >400 lines, distinct responsibilities, testable independently
For detailed extraction patterns and examples, see REFERENCE.md
๐ก Proactive Suggestions
AI should auto-suggest at these milestones:
- New file: Monitor size, alert at 150 lines
- 100 lines: Looking good, will alert at 150
- 150 lines: โ ๏ธ Check if should extract before continuing
- 200 lines: ๐จ Recommend refactoring now
- Reading large file: Offer refactoring plan before changes
๐ง EXECUTION PHASE (After User Approval)
IMPORTANT: This skill can EXECUTE refactoring, not just suggest it!
Step 1: Present Plan and Get User Approval
After analyzing file size and creating refactoring plan, always ask for approval:
## Refactoring Plan Ready
**File:** [filename] ([X] lines)
**Target:** Reduce to <[target] lines
### Proposed Changes:
1. Extract [data/component/class] to [new-file] (saves [X] lines)
2. Extract [component/function] to [new-file] (saves [X] lines)
3. Extract [hook/utility] to [new-file] (saves [X] lines)
**Result:** Main file reduced to ~[X] lines
**Estimated time:** [X] minutes
**Risk level:** Low (all changes are git-committed incrementally)
### Options:
**โ
Yes** - Execute refactoring now (recommended)
- I'll split the file step-by-step
- Each step will be tested and committed
- You can rollback if needed
- Then I'll continue with your original request
**โ No** - Skip refactoring
- I'll continue with your edit
- Warning: File will grow larger
- May become harder to maintain
**โฐ Later** - Save plan for later
- I'll save the plan to `refactoring-plan-[filename].md`
- You can execute it manually later
- I'll continue with your edit now
**๐ Review** - Show detailed step-by-step execution plan
- I'll explain exactly what will happen
- Then you can choose Yes/No/Later
**Your choice?**Step 2: Execute Refactoring (Only if User Says "Yes")
When user approves, execute refactoring incrementally:
- Create backup commit (safety first)
- Verify starting state (lint, type-check, test must pass)
- Execute step-by-step (extract โ verify โ commit for each change)
- Final verification (full test suite)
- Rollback automatically if any step fails
Key execution principles:
- โ Each step is atomic and committed separately
- โ Each step is verified before proceeding
- โ Automatic rollback on any failure
- โ User can cancel at any time
For detailed execution procedures, safety measures, rollback procedures, and examples, see REFERENCE.md โ "EXECUTION PHASE - Detailed Procedures"
Step 3: Continue With Original Request
After execution (success or skip):
Refactoring: โ
Complete (or โญ๏ธ Skipped)
Original request: "[user's request]"
Now proceeding with your request...๐ Integration with Other Skills
Works with:
ui-ux-audit- Check file sizes during UI auditstechnical-writing- Document refactored structureqa-testing- Ensure tests cover refactored code
Triggers:
- Before major edits to large files
- During file creation
- After reading files >200 lines
- When detecting size/complexity patterns
๐ CODEBASE AUDIT MODE (For Existing Technical Debt)
Use this mode when user asks to:
- "Audit the codebase" or "find large files"
- Check for "technical debt" or "existing problems"
- "Scan for refactoring opportunities"
- Review legacy/inherited codebase
- Plan major refactoring initiative
Audit Workflow (Brief):
- Scan for oversized files by language/type
- Categorize by severity (Critical >300, High 200-300, Medium 150-200, Good <150)
- Prioritize using formula: (Size/100) + (Change Frequency ร 2) + (Business Impact ร 3)
- Create refactoring roadmap with time estimates
- Execute incrementally (one file per sprint)
Quick scan commands:
# Find oversized files by type
find src -name "*.tsx" -exec wc -l {} \; | awk '$1 > 200' | sort -rn
# Use helper script
bash scripts/check-size.sh src/ '*.tsx'For detailed audit procedures, report templates, prioritization matrices, and batch analysis commands, see REFERENCE.md โ "CODEBASE AUDIT MODE - Detailed Procedures"
๐ Language-Specific Details
For detailed refactoring patterns specific to each language, see:
REFERENCE.md- Comprehensive language-specific guidesFORMS.md- Refactoring templates and checklists
To check file size quickly:
# Use the helper script
bash ~/.claude/plugins/marketplaces/custom-skills/code-refactoring/scripts/check-size.sh [filename]โ Success Criteria
Refactoring is successful when:
- โ Main file within target size for language
- โ All extracted files well-organized
- โ No broken imports or references
- โ All tests pass
- โ Functionality unchanged
- โ Code more maintainable and readable
- โ Clear separation of concerns
- โ Documentation updated
Remember: Prevention > Cure
This skill prevents "caught by accident" scenarios by:
- Checking BEFORE editing (preventive)
- Alerting DURING creation (proactive)
- Suggesting AFTER reading (reactive)
- Enforcing patterns automatically
The goal: Never again discover an oversized, complex file by accident.
Multi-language support: Works across JavaScript/TypeScript, Python, and general codebases with language-specific patterns.