| name | tech-debt-tracker |
| description | Technical debt management: catalogue, categorise, and prioritise tech debt — build a debt register, quantify impact, present to leadership, and create a paydown strategy |
Tech Debt Tracker Skill
When to activate
- Creating a tech debt register for the first time
- Prioritising which debt to pay down first
- Making the case to leadership for tech debt investment
- Categorising debt discovered during a sprint or codebase review
- Planning a refactoring sprint or debt paydown quarter
- Documenting the "why" behind technical decisions so future engineers understand
When NOT to use
- Active bug fixing — that's the debug skill
- Performance profiling — use the performance-profiler skill
- Immediate security vulnerabilities — fix those now, don't add to a register
- Architecture design decisions — use an ADR (Architecture Decision Record) instead
Instructions
Tech debt register
Create a tech debt register for [codebase/system].
System: [describe]
Team: [X engineers]
Current pain points: [list what's slowing the team down]
Sources of debt: [past deadline pressure / changing requirements / outdated tech / missing tests]
Debt register format:
| ID | Name | Category | Location | Impact | Effort | Priority | Notes |
|---|---|---|---|---|---|---|---|
| TD-001 | [name] | [type] | [file/service] | [H/M/L] | [S/M/L/XL] | [score] | [context] |
Debt categories:
- CODE: duplication, complexity, bad naming, anti-patterns
- ARCHITECTURE: wrong abstractions, coupling, missing separation of concerns
- TEST: missing tests, brittle tests, test coverage gaps
- DEPENDENCY: outdated packages, deprecated libraries, security-vulnerable deps
- DOCUMENTATION: missing, outdated, or misleading docs
- DATA: schema inconsistency, missing indexes, migration backlog
- INFRASTRUCTURE: manual processes that should be automated, legacy config
- SECURITY: known vulnerabilities, insufficient access controls
For each debt item:
Name: [short, descriptive — "Authentication module uses MD5 hashing"]
Category: [from list above]
Location: [file path / service name / database table]
Description: [what the problem is — 1-3 sentences]
Root cause: [why this debt exists — deadline / changing requirements / originally reasonable decision]
Impact: [what it costs the team — slower development / higher bug rate / security risk / etc.]
Effort to fix: S (< 1 day) / M (1-3 days) / L (1-2 weeks) / XL (> 2 weeks)
Risk if not fixed: [what happens if we leave this — scale it, maintain it, never fix it]
Generate the debt register template and populate with items from my codebase description.
