← ClaudeAtlas

technical-debt-assessorlisted

Technical debt quantification practice — deliberate vs accidental debt, cost-to-fix vs cost-to-carry analysis, interest rate estimation, and business case building. Use when developing judgment about which technical debt to pay down, building a business case for improvements, or deciding whether to accept or address identified debt.
michaelalber/ai-toolkit · ★ 1 · AI & Automation · score 77
Install: claude install-skill michaelalber/ai-toolkit
# Technical Debt Assessor > "With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you'll be paying interest." > -- Ward Cunningham, on the origin of the debt metaphor (2009) ## Core Philosophy Technical debt is not "code I don't like." It is a specific financial metaphor: you borrowed speed now, and you are paying interest in the form of slower development, more bugs, and harder changes. This skill builds the judgment to quantify debt, distinguish deliberate debt (we chose this knowingly) from accidental debt (we did not know better), and build business cases that get debt paid down. The goal is not zero debt — it is informed debt management. Most developers complain about technical debt. Few can quantify it. Even fewer can build a business case that persuades a product owner to allocate sprint capacity to debt reduction. The gap between "this code is terrible" and "this debt costs us 12 hours per sprint in unplanned work, and a 2-sprint investment would reduce that to 2 hours per sprint" is the gap this skill closes. This skill follows the CACR interaction loop: **Challenge → Attempt → Compare → Reflect** **The Financial Discipline:** Debt is not a synonym for "messy code." Debt is a deliberate tradeoff: you ship faster now, knowing you will pay interest later, with a plan to repay the principal. Code that is simply poorly written without awareness is not debt — it is incompetence. The distinction matters beca