home / skills / mcouthon / agents / tech-debt
This skill helps identify and eliminate technical debt by auditing code for smells, dead code, and unused imports, improving maintainability.
npx playbooks add skill mcouthon/agents --skill tech-debtReview the files below or copy the command above to add this skill to your agents.
---
name: tech-debt
description: "Use when finding code smells, auditing TODOs, removing dead code, cleaning up unused imports, or assessing code quality. Triggers on: 'use tech-debt mode', 'tech debt', 'code smells', 'clean up', 'remove dead code', 'delete unused', 'simplify'. Full access mode - can modify files and run tests."
allowed-tools: [Read, Edit, Write, Bash, Grep, Glob, LSP]
---
# Tech Debt Mode
Identify, catalog, and eliminate technical debt.
## Core Philosophy
> "Deletion is the most powerful refactoring."
**The 40% Rule**: In AI-assisted coding, expect to spend 30-40% of your time on code healthβreviews, smell detection, and refactoring. Without this investment, vibe-coded bases accumulate invisible debt that slows agents and breeds bugs. Schedule regular code health passes, not just reactive fixes.
Every line of code:
- Must be understood
- Must be tested
- Must be maintained
- Can contain bugs
**Less code = less of all the above.**
## Debt Indicators to Find
| Category | What to Look For |
| ---------------- | --------------------------------------------- |
| **Comments** | TODO, FIXME, HACK, XXX, "temporary" |
| **Code Smells** | Duplicated blocks, long functions (>50 lines) |
| **Type Issues** | Missing hints, `Any` types, type: ignore |
| **Dead Code** | Unused functions, unreachable branches |
| **Dependencies** | Outdated packages, unused imports |
| **Complexity** | Deep nesting, long parameter lists |
## Process
### 1. Scan
Search for debt indicators across the codebase:
- Grep for TODO/FIXME comments
- Find functions over threshold length
- Identify files with type errors
- Check for unused exports
### 2. Categorize
For each finding, assess:
- **Severity**: How bad is this?
- **Effort**: How hard to fix?
- **Risk**: What could go wrong?
### 3. Prioritize
Focus on:
- π― **Quick Wins** - Low effort, high impact
- π **Safety First** - Fix risky debt before adding features
- π **Hot Paths** - Prioritize frequently-touched code
### 4. Fix or Document
- Simple fixes: Just do it (with tests)
- Complex fixes: Create a plan for later
## Quick Win Examples
```python
# Before: Dead import
from typing import List, Dict, Optional # Only Optional used
# After
from typing import Optional
```
```python
# Before: Bare except
try:
data = fetch()
except:
pass
# After: Specific exception
try:
data = fetch()
except ConnectionError:
logger.warning("Failed to fetch data, using cache")
data = get_cached()
```
## Tech Debt Report Format
```markdown
## Tech Debt Analysis
### Summary
- **Total issues found**: X
- **Critical**: X (fix immediately)
- **Quick wins**: X (easy to fix)
- **Requires planning**: X (complex)
### Findings
#### Critical π΄
| Location | Type | Issue | Effort |
| ------------ | -------- | ------------------------- | ------ |
| `file.py:42` | security | bare except hiding errors | Low |
#### Quick Wins π―
| Location | Type | Issue | Effort |
| ------------- | ------ | ----------------- | ------ |
| `utils.py:10` | unused | import never used | Low |
#### Requires Planning π
| Location | Type | Issue | Why Complex |
| -------- | ----------- | ------------------ | ------------------------ |
| `api.py` | duplication | 3 similar handlers | Needs abstraction design |
### Recommendations
[Suggested order of tackling debt]
### Fixed This Session
[List of debt items resolved]
```
## When Fixing Debt
- β
Run tests after each change
- β
Keep changes atomic and focused
- β
Verify no regressions
- β Don't mix debt fixes with new features
- β Don't "refactor" working code without reason
## Safe Deletion Patterns
Before removing code, verify it's unused:
```bash
# Check for usages
ag "function_name" --python
# Check imports
ag "from module import function_name"
```
Watch for code that might be used dynamically:
```python
# β
Safe to delete: unused import
from typing import List # 'List' never used in file
# β
Safe to delete: unused variable
result = calculate() # 'result' never read
log(value) # This is the actual intent
# β
Safe to delete: dead branch
if False: # Will never execute
do_something()
# β οΈ Verify first: might be used dynamically
def _helper(): # Underscore suggests private, but check usages
pass
# β Don't delete without checking: exported function
def public_api(): # Might be called by external code
pass
```
Also watch for:
- Dynamically called code (`getattr`, `eval`)
- Reflection-based frameworks
- External API contracts
- CLI entry points
## Cleaning Checklist
```markdown
- [ ] Unused imports removed
- [ ] Unused variables removed
- [ ] Dead functions removed
- [ ] Commented-out code removed
- [ ] Debug statements removed
- [ ] Duplicate code consolidated
- [ ] Tests still pass
- [ ] Types still check
```
## Debt Prevention Tips
To prevent future debt:
- Add TODO with issue tracker link: `# TODO(JIRA-123): refactor after migration`
- Use type hints from the start
- Write tests before marking done
- Review for simplification opportunities
> "The best code is no code at all."
This skill helps identify, prioritize, and remove technical debt across a codebase. It focuses on finding code smells, TODOs, dead code, unused imports, and type issues, then categorizing and fixing them safely. The goal is less code, fewer bugs, and faster maintenance cycles.
The skill scans the repository for debt indicators (TODO/FIXME, long functions, unused imports, bare excepts, Any/type: ignore, duplicated blocks). It classifies each finding by severity, effort, and risk, then proposes a prioritized remediation plan separating quick wins from complex refactors. When authorized, it can apply atomic fixes, run tests, and document changes in a concise tech-debt report.
Will this skill run tests after changes?
Yes. It runs tests after each change to verify no regressions and reports failures immediately.
Can it delete code that might be referenced dynamically?
It will flag dynamic usages as risky and avoid automatic deletion; those items are documented for manual review.