tech-debt-reducer
Skill1 starsChanged 11 months agoMITView on GitHub
Systematic technical debt reduction and code optimization agent. Use when refactoring code, reducing complexity, eliminating code smells, improving performance, cleaning up unused code, or modernizing legacy patterns. Handles dependency updates, architecture improvements, and codebase health metrics.
In this repository4 other files it gives its agents.
- AGENTS.MDAGENTS.md
- advanced-debuggingSkill
- oneplanSkill
- skill-generatorSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
Before any refactoring, assess the current state:
- Distinctive: line 66
Use the Impact vs Effort matrix:
- Distinctive: line 191
After completing debt reduction work:
- Distinctive: line 228
Stop and reassess if:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
🔧 Tech Debt Reducer
Systematic approach to identifying, prioritizing, and eliminating technical debt while improving code quality and performance.
Quick Reference
| Task | Command/Action |
| Analyze complexity | Run scripts/analyze-complexity.ts |
| Find unused code | Run scripts/find-unused.ts |
| Detect code smells | Run scripts/detect-smells.ts |
| Generate debt report | Run scripts/debt-report.ts |
| Prioritize debt items | Follow "Prioritization Matrix" section |
Core Methodology
Phase 1: Assessment (ALWAYS FIRST)
Before any refactoring, assess the current state:
## 📊 Tech Debt Assessment
### Codebase Metrics
- **Total Files**: [count]
- **Lines of Code**: [count]
- **Average Complexity**: [score]
- **Test Coverage**: [percentage]
- **Dependency Age**: [stats]
### Identified Issues
| Category | Count | Severity | Effort |
|----------|-------|----------|--------|
| Code Smells | X | High/Med/Low | S/M/L |
| Unused Code | X | Low | S |
| Complex Functions | X | Med | M |
| Outdated Deps | X | High | M |
| Missing Types | X | Med | S |Phase 2: Categorization
Classify debt into categories:
| Category | Description | Examples |
| Architecture | Structural issues | Circular deps, wrong abstractions |
| Code Quality | Maintainability issues | Long functions, duplicate code |
| Performance | Speed/memory issues | N+1 queries, memory leaks |
| Security | Vulnerability issues | Outdated deps, exposed secrets |
| Testing | Coverage gaps | Missing tests, flaky tests |
| Documentation | Knowledge gaps | Missing docs, outdated comments |
Phase 3: Prioritization Matrix
Use the Impact vs Effort matrix:
High Impact │ Quick Wins │ Strategic
│ (Do First) │ (Plan Carefully)
────────────┼────────────────┼─────────────────
Low Impact │ Fill-ins │ Avoid
│ (If Time) │ (Not Worth It)
└────────────────┴─────────────────
Low Effort High EffortPriority Formula: Score = (Impact × Risk) / Effort
Phase 4: Refactoring Patterns
See references/REFACTORING_PATTERNS.md for detailed patterns.
Safe Refactoring Workflow
1. ✅ Ensure tests exist (or write them first)
2. 📸 Create snapshot/checkpoint (git commit)
3. 🔧 Apply ONE refactoring at a time
4. 🧪 Run tests after each change
5. 📝 Commit with descriptive message
6. 🔄 RepeatCode Smell Detection
Common Smells and Fixes
| Smell | Detection | Fix |
| Long Function | >50 lines | Extract methods |
| Large Class | >300 lines | Split into smaller classes |
| Long Parameter List | >4 params | Use parameter object |
| Duplicate Code | Similar blocks | Extract common function |
| Dead Code | Unreachable code | Remove safely |
| Magic Numbers | Hardcoded values | Extract constants |
| God Object | Does too much | Single responsibility |
| Feature Envy | Uses other class data | Move method |
TypeScript-Specific Smells
| Smell | Example | Fix |
any abuse | data: any | Proper types |
| Missing null checks | obj.prop | Optional chaining ?. |
| Type assertions | as Type | Type guards |
| Implicit any | No param types | Explicit types |
| No return types | Functions without | Add return types |
Performance Optimization
Quick Wins
// ❌ Bad: Multiple re-renders
const items = data.filter(x => x.active).map(x => x.name);
// ✅ Good: Single pass with reduce
const items = data.reduce((acc, x) => {
if (x.active) acc.push(x.name);
return acc;
}, []);
// ❌ Bad: Creating functions in render
<Button onClick={() => handleClick(id)} />
// ✅ Good: useCallback or handler
const handleButtonClick = useCallback(() => handleClick(id), [id]);
// ❌ Bad: Missing memoization
const expensiveValue = computeExpensive(data);
// ✅ Good: useMemo for expensive computations
const expensiveValue = useMemo(() => computeExpensive(data), [data]);Database Query Optimization
// ❌ Bad: N+1 Query
const users = await prisma.user.findMany();
for (const user of users) {
const posts = await prisma.post.findMany({ where: { userId: user.id } });
}
// ✅ Good: Include related data
const users = await prisma.user.findMany({
include: { posts: true }
});
// ✅ Better: Select only needed fields
const users = await prisma.user.findMany({
select: { id: true, name: true, posts: { select: { title: true } } }
});Dependency Management
Update Strategy
- Check outdated:
npm outdated - Review changelogs for breaking changes
- Update in order: patch → minor → major
- Test after each major update
Cleanup Unused Dependencies
# Find unused dependencies
npx depcheck
# Analyze bundle size
npx webpack-bundle-analyzer
# Check for duplicates
npm dedupeOutput Template
After completing debt reduction work:
## 🔧 Tech Debt Report
### 📊 Before/After Metrics
| Metric | Before | After | Change |
|--------|--------|-------|--------|
| Complexity | X | Y | -Z% |
| Lines of Code | X | Y | -Z% |
| Test Coverage | X% | Y% | +Z% |
| Bundle Size | X KB | Y KB | -Z% |
### ✅ Changes Made
1. [Description of change 1]
2. [Description of change 2]
### 🧪 Tests
- [ ] All existing tests pass
- [ ] New tests added for refactored code
- [ ] No regressions detected
### 📝 Follow-up Items
- [ ] Item that needs future attentionSafety Guidelines
- ❌ NEVER refactor without tests
- ❌ NEVER make multiple unrelated changes in one commit
- ❌ NEVER refactor and add features simultaneously
- ✅ ALWAYS commit working state before refactoring
- ✅ ALWAYS run tests after each change
- ✅ ALWAYS preserve external behavior
Escalation Criteria
Stop and reassess if:
- Tests start failing unexpectedly
- Refactoring scope grows beyond initial estimate
- Performance degrades after optimization
- Breaking changes affect public API
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

