Technical Debt Analyzer

Overview

This skill identifies and prioritizes technical debt by combining static code analysis with git history. Instead of just finding code smells, it answers the critical question: "Which debt is actually hurting us?" by correlating complexity with change frequency, bug density, and developer contention.

Instructions

Step 1: Gather Debt Signals

Scan the codebase for these indicators:

# TODO/FIXME/HACK markers with context
grep -rn "TODO\|FIXME\|HACK\|XXX\|WORKAROUND" --include="*.ts" --include="*.js" --include="*.py" --include="*.go" --include="*.java" src/

# Long functions (proxy: count lines between function declarations)
# Outdated dependencies
npm outdated 2>/dev/null || pip list --outdated 2>/dev/null || go list -m -u all 2>/dev/null

Step 2: Measure Complexity

For each file, estimate cyclomatic complexity:

• Count branching statements (if, else, switch cases, ternary, catch, &&, ||)
• Flag functions with complexity > 15 as high
• Flag files with average complexity > 10 as concerning

Step 3: Analyze Git History

# Change frequency per file (last 6 months)
git log --since="6 months ago" --pretty=format: --name-only | sort | uniq -c | sort -rn | head -30

# Bug-fix correlation (commits mentioning fix/bug/hotfix)
git log --since="6 months ago" --grep="fix\|bug\|hotfix" --pretty=format: --name-only | sort | uniq -c | sort -rn | head -20

# Developer contention (unique authors per file)
git log --since="3 months ago" --pretty=format:"%an" -- <file> | sort -u | wc -l

Step 4: Score and Prioritize

Calculate a composite score (0-10) for each debt item:

• Change frequency (30%): How often the file is modified
• Bug density (30%): How many bug-fix commits reference this file
• Developer contention (20%): How many developers work on it weekly
• Complexity score (20%): Normalized cyclomatic complexity

Classify into:

• P0: Score ≥ 8 — Fix this sprint, it's actively causing pain
• P1: Score 5-7.9 — Schedule within the quarter
• P2: Score < 5 — Monitor but don't prioritize

Step 5: Generate Remediation Tickets

For P0 and P1 items, produce structured tickets with:

• Problem description with specific metrics
• Acceptance criteria (measurable)
• Suggested refactoring approach
• Estimated effort in story points (1-13 scale)
• Risk assessment

Examples

Example 1: Monorepo Scan

User prompt:

Analyze our Python Django project for tech debt priorities

Agent output:

Tech Debt Analysis — myproject/ (156 files, 22,400 LOC)

P0 — Fix This Sprint
  views/checkout.py     Score: 9.1  Complexity: 38  Churn: 24/mo  Bugs: 9
    → 340-line process_order() handles payment, inventory, email, logging
    → Recommendation: Extract into OrderProcessor, PaymentHandler, NotificationService

P1 — This Quarter
  models/user.py        Score: 6.8  Complexity: 22  Churn: 12/mo  Bugs: 4
    → User model has 28 methods, some unrelated to user domain
    → Recommendation: Extract ProfileMixin, PreferencesMixin

P2 — Monitor
  utils/legacy_xml.py   Score: 1.3  Complexity: 31  Churn: 0/mo   Bugs: 0
    → Complex but completely stable. Do not refactor.

Debt trend indicator: 📈 Growing (+3 files above threshold vs 3 months ago)

Example 2: Dependency Audit

User prompt:

Check for outdated and risky dependencies in our Node.js project

Agent output:

Dependency Debt Report
──────────────────────

CRITICAL (security + major version behind)
  lodash          4.17.15 → 4.17.21    3 known vulnerabilities
  express         4.17.1  → 4.21.2     1 moderate CVE

MAJOR VERSION BEHIND
  typescript      4.9.5   → 5.7.3      Breaking changes in 5.x
  jest            27.5.1  → 29.7.0     Migration guide available

MINOR UPDATES (low risk)
  axios           1.6.0   → 1.7.9
  dotenv          16.3.1  → 16.4.7

Recommendation: Address critical items immediately (1-2 hours).
Schedule TypeScript 5.x migration as a dedicated sprint task (2-3 days).

Guidelines

• Business impact over code purity — a complex file that never changes and never breaks is NOT high priority debt
• Data over opinions — always back prioritization with git metrics, not gut feeling
• Don't recommend rewriting stable legacy code — if it works and nobody touches it, leave it alone
• Include effort estimates — debt without remediation cost is not actionable
• Track trends — a single snapshot is useful; comparing snapshots over time is powerful
• Respect team context — note when refactoring requires domain knowledge or coordination across teams