Technical debt management

Skill sairam0424/MindForge/.mindforge/skills/technical-debt-management

MindForge: The Enterprise Agentic Framework for Claude Code & Antigravity. High-performance autonomous execution, wave-parallelism, and multi-tier governance for production-grade AI engineering.

Install

npx -y skills add sairam0424/MindForge --skill technical-debt-management

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.2 KB, as published. Nobody here has run it

Skill — Technical Debt Management

When this skill activates

Any task involving debt identification, classification, prioritization, ROI-based refactoring, budget allocation, code health scoring, or payoff planning.

Mandatory actions when this skill is active

Before writing any code

Classify the debt (deliberate vs inadvertent, prudent vs reckless).
Estimate interest rate (hours lost per sprint due to this debt).
Calculate payoff ROI before prioritizing.

During implementation

Track all debt in backlog with tech-debt label + severity + affected area.
Boy-scout rule: leave code cleaner than found.
Never create debt without acknowledgment and payoff timeline.
Fix debt in atomic PRs — never bundle with feature work.

After implementation

Update debt inventory with resolved items.
Recalculate code health score after significant payoffs.
Document lessons to prevent similar accumulation.

Debt Classification

Type	Description	Example
Deliberate + Prudent	"We know, ship now, fix Sprint N"	Hardcoded config needing config service
Deliberate + Reckless	"We know, don't care"	Skipping auth "because VPN"
Inadvertent + Prudent	"Didn't know better then"	Hand-rolled state before finding library
Inadvertent + Reckless	"Didn't know what we were doing"	N+1 queries from ORM misuse

Interest Calculation

Weekly Interest = incidents_caused * avg_hours
               + developer_workaround_time
               + onboarding_friction
               + blocked_feature_delays

High (>4 hrs/sprint): fix immediately.
Medium (1-4 hrs/sprint): schedule within 2 sprints.
Low (<1 hr/sprint): fix opportunistically.

Prioritization Formula

Priority Score = interest_per_sprint / effort_to_fix_hours
Higher score = fix first (best ROI)

Debt Budget (The 20% Rule)

20% of sprint capacity for debt payoff (non-negotiable).
10% targeted high-interest debt. 5% boy-scout cleanup. 5% prevention tooling.
Increase when: health score < 60, velocity declining 3+ sprints, incidents rising.

Code Health Score (0-100)

Health = test_coverage(25%) + dependency_freshness(20%)
       + complexity(25%) + documentation(15%) + incident_inverse(15%)

Test coverage: 80%+ = 100pts, 60-80% = 75, 40-60% = 50, <40% = 25.
Complexity: avg cyclomatic per function. <5 = 100, 5-10 = 75, >10 = 50.
Track monthly. Alert if drops >10 points in one month.

Self-check before task completion

Is all identified debt logged with classification and severity?
Is interest rate estimated for each item?
Is payoff prioritized by ROI (interest / effort)?
Is the 20% debt budget respected in sprint planning?
Are new debts acknowledged with a payoff timeline?
Is code health score calculated and tracked?
Are debt fixes in isolated PRs (not bundled with features)?

Gives 0 of the 12 instructions most refactoring skills give

Counted across 521 of the 525 authors here whose files we hold, read 2026-08-06

run tests after each changein 59 of 521, across 56 files
write tests before refactoringin 27 of 521, across 24 files
preserve external behaviorin 26 of 521, across 22 files
remove dead codein 25 of 521, across 24 files
make small incremental changesin 20 of 521, across 17 files
break the implementation into tiny commitsin 18 of 521, across 5 files
ask the user about alternative optionsin 17 of 521, across 4 files
create a GitHub issue with the planin 17 of 521, across 4 files
explore the repository to verify assertionsin 17 of 521, across 4 files
interview the user about the refactorin 16 of 521, across 3 files
check the codebase for test coveragein 16 of 521, across 3 files
refactor one thing at a timein 16 of 521, across 12 files

Said here and by no other author read

estimate interest rate per sprint
calculate payoff ROI before prioritizing
track all debt in the backlog
fix debt in atomic pull requests
update debt inventory with resolved items
recalculate code health score after payoffs

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.