| name | Technical Debt Tracking with PMAT |
| description | Tracks and manages technical debt using PMAT (Pragmatic AI Labs MCP Agent Toolkit). Use this skill when: - User asks about technical debt, TODO comments, or code quality issues - Planning sprint work and need to prioritize debt repayment - Conducting code audits or technical debt assessments - Tracking debt accumulation trends over time - Creating technical debt reports for stakeholders Detects SATD (Self-Admitted Technical Debt) annotations: TODO, FIXME, HACK, XXX, NOTE comments. Provides debt quantification in hours, prioritization by severity, and repayment tracking. |
| allowed-tools | Bash, Read, Write, Glob, Grep |
PMAT Technical Debt Tracking Skill
You are an expert at identifying, quantifying, and managing technical debt using PMAT (Pragmatic AI Labs MCP Agent Toolkit).
When to Activate
This skill should automatically activate when:
- User mentions "technical debt", "tech debt", or "TD"
- User asks about TODO, FIXME, HACK comments in the codebase
- Planning sprint work and need debt repayment estimates
- Conducting code quality audits or assessments
- Tracking debt trends over time (sprint-to-sprint comparison)
Core Concept: SATD (Self-Admitted Technical Debt)
Definition: Comments explicitly admitting suboptimal implementation Types:
- TODO: Deferred work, future enhancements
- FIXME: Known bugs or issues requiring fixes
- HACK: Temporary workarounds needing proper solutions
- XXX: Critical issues requiring immediate attention
- NOTE: Important context or warnings
Scientific Foundation: Based on research by Potdar & Shihab (2014) on self-admitted technical debt in code comments.
Available PMAT Commands
1. Detect Technical Debt
pmat analyze satd --path <file_or_directory> --output debt_report.json
Output: All SATD annotations with location, type, and context
2. Quantify Debt Hours
pmat analyze tech-debt --path <directory> --estimate-hours --output debt_hours.json
Output: Estimated hours to resolve each debt item
3. Track Debt Trends
# Baseline measurement
pmat analyze satd --path . --output debt_baseline.json
# After sprint work
pmat analyze satd --path . --output debt_current.json
# Compare trends
pmat compare-debt --baseline debt_baseline.json --current debt_current.json
4. Generate Debt Report
pmat analyze satd --path . --format markdown --output TECH_DEBT_REPORT.md
Output: Markdown report suitable for documentation or stakeholder review
Usage Workflow
Step 1: Initial Debt Assessment
Establish baseline understanding of technical debt:
# Detect all SATD annotations
pmat analyze satd --path . --output satd_inventory.json
# Analyze output for patterns
# - Count by type (TODO, FIXME, HACK)
# - Count by severity (critical, high, medium, low)
# - Count by module/component
Step 2: Categorize and Prioritize
Classify debt items by urgency:
Priority Matrix:
| Type | Severity | Priority | Action |
|---|---|---|---|
| FIXME (bug) | Security issue | CRITICAL | Fix immediately |
| HACK | Production workaround | HIGH | Refactor in current sprint |
| TODO | Blocking feature | HIGH | Schedule in backlog |
| FIXME | Minor bug | MEDIUM | Fix when modifying area |
| TODO | Nice-to-have | LOW | Defer until capacity |
Step 3: Estimate Repayment Cost
Quantify effort required to resolve debt:
# Get hour estimates
pmat analyze tech-debt --path . --estimate-hours --output debt_estimates.json
# Review estimates
cat debt_estimates.json | jq '.items[] | select(.priority == "HIGH")'
Estimation Guidelines (industry averages):
- TODO: 2-8 hours (implementation time)
- FIXME: 4-16 hours (bug investigation + fix)
- HACK: 8-24 hours (proper redesign)
- XXX: 16-40 hours (critical issue resolution)
Step 4: Create Repayment Plan
Develop systematic debt reduction strategy:
# Generate actionable plan
pmat generate-debt-plan \
--input debt_estimates.json \
--budget-hours 40 \
--output sprint_debt_plan.md
Plan Components:
- High-priority items (CRITICAL/HIGH)
- Quick wins (low effort, high impact)
- Strategic refactorings (foundational improvements)
- Deferred items (low priority)
Step 5: Track Progress
Monitor debt repayment over time:
# Weekly/sprint measurement
pmat analyze satd --path . --output debt_week_$(date +%Y%m%d).json
# Visualize trends
pmat visualize-debt-trend \
--inputs debt_week_*.json \
--output debt_trend_chart.png
Example Workflows
Example 1: Sprint Debt Assessment
# User: "What technical debt should we tackle this sprint?"
# Step 1: Inventory current debt
pmat analyze satd --path . --output current_debt.json
# Step 2: Filter high-priority items
cat current_debt.json | jq '.items[] | select(.priority == "HIGH" or .priority == "CRITICAL")'
# Example output:
# {
# "type": "FIXME",
# "file": "src/api/auth.rs",
# "line": 67,
# "message": "SQL injection vulnerability - sanitize inputs",
# "priority": "CRITICAL",
# "estimated_hours": 8,
# "context": "User authentication endpoint"
# }
# Step 3: Present recommendations
# "Found 3 CRITICAL and 8 HIGH priority debt items:
#
# **CRITICAL (must fix this sprint)**:
# 1. src/api/auth.rs:67 - SQL injection vulnerability (8 hours)
# 2. src/core/payments.rs:145 - Race condition in payment processing (12 hours)
# 3. src/services/cache.rs:230 - Memory leak in cache eviction (6 hours)
#
# **HIGH (recommended for this sprint)**:
# 1. src/handlers/upload.rs:90 - File upload size validation missing (4 hours)
# 2. src/models/user.rs:123 - Password hashing deprecated algorithm (6 hours)
# ...
#
# **Recommendation**: Allocate 26 hours this sprint to resolve CRITICAL items.
# Total debt estimate: 156 hours (down from 180 hours last sprint - 13% reduction)"
Example 2: Debt Trend Analysis
# User: "Is our technical debt getting better or worse?"
# Step 1: Compare with previous measurement
pmat compare-debt \
--baseline debt_2025_01_01.json \
--current debt_2025_01_22.json \
--output debt_comparison.md
# Example output (debt_comparison.md):
# # Technical Debt Trend Report
#
# ## Summary
# - **Previous**: 47 SATD items (180 hours)
# - **Current**: 43 SATD items (156 hours)
# - **Change**: -4 items (-8.5%), -24 hours (-13.3%)
#
# ## By Type
# | Type | Previous | Current | Change |
# |------|----------|---------|--------|
# | TODO | 23 | 21 | -2 (-8.7%) |
# | FIXME | 18 | 16 | -2 (-11.1%) |
# | HACK | 6 | 6 | 0 (0%) |
#
# ## By Priority
# | Priority | Previous | Current | Change |
# |----------|----------|---------|--------|
# | CRITICAL | 3 | 3 | 0 (0%) |
# | HIGH | 12 | 8 | -4 (-33%) |
# | MEDIUM | 20 | 22 | +2 (+10%) |
# | LOW | 12 | 10 | -2 (-16.7%) |
#
# ## Key Insights
# - ✅ High-priority debt reduced by 33% (excellent progress)
# - ⚠️ CRITICAL debt unchanged (needs attention)
# - ⚠️ Medium-priority debt increased (new TODOs added)
#
# ## Recommendations
# 1. Focus on resolving 3 CRITICAL items next sprint
# 2. Continue addressing HIGH priority items (on track)
# 3. Prevent new MEDIUM debt accumulation (code review focus)
# Step 2: Present summary
# "Technical debt is improving: 13% reduction in total hours this sprint.
# High-priority debt down 33%, but 3 CRITICAL items remain unresolved.
# Recommend allocating 26 hours next sprint to clear CRITICAL backlog."
Example 3: Debt Hotspot Identification
# User: "Which files have the most technical debt?"
# Step 1: Analyze debt by file
pmat analyze satd --path . --group-by file --output debt_by_file.json
# Step 2: Sort by debt concentration
cat debt_by_file.json | jq -r '.files | sort_by(.total_hours) | reverse | .[] | "\(.path): \(.count) items, \(.total_hours) hours"' | head -10
# Example output:
# src/services/legacy_processor.rs: 12 items, 48 hours
# src/api/v1/deprecated_endpoints.rs: 8 items, 32 hours
# src/core/payment_engine.rs: 6 items, 28 hours
# src/utils/data_migration.rs: 7 items, 24 hours
# src/handlers/legacy_auth.rs: 5 items, 20 hours
# Step 3: Recommend refactoring strategy
# "Technical debt is concentrated in 5 files (68% of total debt):
#
# **Top Debt Hotspots**:
# 1. src/services/legacy_processor.rs (48 hours)
# - Consider complete rewrite or phased modernization
# - High risk: 12 debt items indicate architectural issues
#
# 2. src/api/v1/deprecated_endpoints.rs (32 hours)
# - Migrate clients to v2 API, then delete file
# - Quick win: Eliminates 8 debt items at once
#
# 3. src/core/payment_engine.rs (28 hours)
# - Critical business logic with 6 HACK workarounds
# - Recommend: Extract payment logic into separate service
#
# **Strategy**: Focus refactoring efforts on legacy_processor.rs and deprecated_endpoints.rs for maximum debt reduction."
Debt Accumulation Prevention
Code Review Checklist
When reviewing code, flag new SATD additions:
# Check for new debt in PR
git diff main...feature-branch | grep -E "(TODO|FIXME|HACK|XXX)" | wc -l
# If count > 0, review justification:
# - Is this debt intentional and documented?
# - Is there a plan to resolve it?
# - Has an issue been created to track it?
Pre-commit Hook (Debt Budget)
Enforce debt budget limits:
# .git/hooks/pre-commit
#!/bin/bash
current_debt=$(pmat analyze satd --path . --format json | jq '.total_hours')
debt_limit=200
if [ "$current_debt" -gt "$debt_limit" ]; then
echo "❌ Technical debt budget exceeded: ${current_debt}h > ${debt_limit}h"
echo "Resolve existing debt before adding new code."
exit 1
fi
Debt Quantification Methodology
PMAT estimates debt hours using:
- Complexity Analysis: Higher complexity = more refactoring time
- Code Churn: Frequently changed code = harder to refactor
- Dependency Count: More dependencies = more integration work
- Historical Data: Learn from past debt resolution times
Formula:
debt_hours = base_estimate × complexity_factor × churn_factor × dependency_factor
Example:
- TODO in simple function: 2h × 1.0 × 1.0 × 1.0 = 2h
- HACK in complex, high-churn file: 8h × 2.5 × 2.0 × 1.5 = 60h
Debt Categorization Framework
By Intentionality (Fowler, 2009)
| Type | Description | Example |
|---|---|---|
| Deliberate & Prudent | Conscious decision with plan | "Ship now, optimize later" |
| Deliberate & Reckless | Shortcuts without consideration | "We don't have time for design" |
| Inadvertent & Prudent | Learning from hindsight | "Now we know how we should have done it" |
| Inadvertent & Reckless | Poor practice without awareness | "What's layering?" |
By Impact
- Architectural Debt: Fundamental design issues (high cost, high impact)
- Code Debt: Implementation quality issues (medium cost, medium impact)
- Test Debt: Missing or inadequate tests (low cost, high risk)
- Documentation Debt: Missing or outdated docs (low cost, low impact)
Integration with Other PMAT Skills
Recommended Workflow:
- pmat-context: Understand codebase structure
- pmat-quality: Identify quality issues
- pmat-tech-debt: Quantify and prioritize debt ← This skill
- pmat-refactor: Systematically repay debt
Reporting for Stakeholders
Generate executive-friendly reports:
# Create stakeholder report
pmat generate-debt-report \
--input current_debt.json \
--format executive \
--output TECH_DEBT_EXECUTIVE_SUMMARY.md
Report Structure:
- Executive Summary: Total debt in hours/dollars, trend vs. last sprint
- Risk Assessment: Critical items requiring immediate attention
- Recommendations: Prioritized action plan with ROI estimates
- Progress Tracking: Debt repayment velocity, sprint-over-sprint
Best Practices
- Measure Regularly: Weekly or per-sprint debt assessments
- Budget Allocation: Reserve 10-20% of sprint capacity for debt repayment
- Prevent New Debt: Code review focus on justifying new SATD annotations
- Track Trends: Visualize debt accumulation/repayment over time
- Link to Issues: Create tracking issues for high-priority debt items
- Celebrate Wins: Highlight debt reduction achievements in retrospectives
Limitations
- Estimation Accuracy: Hour estimates are approximations (±50% variance common)
- Comment Detection Only: Only finds explicit SATD comments (not implicit debt)
- Context Required: Automated analysis can't assess business criticality
- Language Support: Comment syntax varies by language (PMAT supports 25+ languages)
When NOT to Use This Skill
- Green Field Projects: New projects have minimal technical debt
- Syntax Errors: PMAT requires parseable code
- Non-Code Debt: Infrastructure, process, or organizational debt not detected
Scientific Foundation
Based on peer-reviewed research:
- Potdar & Shihab (2014): Self-Admitted Technical Debt detection
- Alves et al. (2016): Technical debt identification and management
- Cunningham (1992): Original technical debt metaphor
- Fowler (2009): Technical debt quadrant classification
Version Requirements
- Minimum: PMAT v2.170.0
- Recommended: Latest version for best SATD detection
- Check version:
pmat --version
Remember: Technical debt is not inherently bad. Strategic debt enables speed. The key is conscious decision-making, tracking, and systematic repayment. Use PMAT to make debt visible and manageable.