Skip to main content
< All Topics
Print

Tech Debt Analysis

name: tech-debt-analysis

description: Identify, categorize, and prioritize technical debt across a codebase. Use when auditing code quality, planning a refactoring sprint, evaluating the cost of carrying debt, justifying modernization investments, or producing a quarterly tech health report.

Tech Debt Analysis

Instructions

Identify technical debt, quantify its cost, and produce an actionable remediation plan.

Debt taxonomy (Fowler’s Technical Debt Quadrant):

Reckless Prudent
Deliberate “We didn’t have time for tests” → fix immediately “We ship now, refactor later” → plan refactoring
Inadvertent “We didn’t know about the shared library” → fix soon “We now know a better approach” → fix when touching the area

Debt categories to audit:

  • Architectural debt: monolith that should be modules; missing abstraction layers; platform-specific code that should be shared
  • Code quality debt: duplicated logic; overly complex functions; missing type annotations; magic numbers/strings
  • Dependency debt: outdated libraries with security or compatibility risks; deprecated APIs
  • Testing debt: missing unit tests for critical paths; no integration tests for external APIs; no regression suite
  • Documentation debt: undocumented public APIs; outdated README; missing architecture decision records
  • Security debt: known vulnerabilities deferred; weak authentication patterns; unrotated credentials
  • Performance debt: N+1 queries; missing indexes; full KB file loads instead of section access; disabled caching

Debt inventory format:

ID Description Category Location Risk if Left Effort to Fix Priority Score
TD-001 [Brief description] [Category] [File/module] [Low/Med/High/Critical] [hours] [score]

Priority scoring formula:

Priority = (Risk × Impact × Strategic Alignment) / Effort Risk: 1 (cosmetic) to 4 (security/data loss) Impact: 1 (affects edge case) to 4 (affects core flow daily) Strategic Alignment: 1 (low priority product) to 3 (flagship product) Effort: 1 (1-2 hours) to 4 (1+ week)

Remediation plan structure:


## Phase 1: Immediate (this sprint) — P1 items only
[Critical risk items; security vulnerabilities]

## Phase 2: Short-term (next 1-2 sprints) — P2 items
[High-impact, moderate effort; architectural improvements]

## Phase 3: Medium-term (next quarter) — P3 items
[Valuable improvements that require planning]

## Phase 4: Backlog — P4 items
[Low-priority improvements; address when touching related code]

ITI-specific debt patterns to flag:

  • Custom Claude API client instead of ITI_Claude_API → migrate to shared library
  • Full KB file loading instead of ITI_KB_Parser::extract_relevant() → performance + token debt
  • No ITI_Conversation_Summarizer in products with 4+ conversation turns → experience debt
  • Missing prompt caching (prompt_caching: false) → cost debt
  • Agent logic duplicated across products → shared library candidate
  • WordPress plugin without class-iti-shared-loader.php → integration debt

Outputs: Tech debt inventory table, priority-scored remediation plan in 4 phases, debt trend analysis (growing/stable/shrinking), ROI estimate for top 5 fixes (time saved / risk reduced per hour invested).

Table of Contents