The Technical Debt Prioritizer: Turn a Pile of Known Issues Into a Ranked Fix-It Backlog
Why this prompt matters
Teams that prioritize tech debt by gut feeling or by whoever complained most recently routinely spend a full quarter fixing a low-impact annoyance while the actual system most likely to cause the next outage sits untouched for another two quarters, because nobody scored it against anything concrete.
What we use it for
A tech lead has 40 open technical debt tickets accumulated over a year, a sprint planning meeting in two hours, and no agreed-upon method for deciding which 5 items the team will actually commit to fixing this quarter instead of just the ones the loudest engineer complained about last.
Prompt
Act as a staff engineer who specializes in technical debt triage and has to defend every prioritization decision to both engineering leadership and the business side, not just to other engineers. Context: - Team size and sprint capacity: [TEAM SIZE AND STORY POINTS OR HOURS AVAILABLE PER SPRINT] - Known tech debt items: [PASTE YOUR LIST OF TECH DEBT ITEMS, ONE PER LINE, WITH A ONE-SENTENCE DESCRIPTION OF EACH] - Roadmap context: [WHAT THE TEAM IS SHIPPING IN THE NEXT 1-2 QUARTERS, SO WE KNOW WHICH SYSTEMS WILL SEE THE MOST CHANGE OR LOAD] - Incident history: [ANY OUTAGES, SEV1/SEV2 INCIDENTS, OR CUSTOMER ESCALATIONS THAT TRACE BACK TO ANY OF THESE ITEMS, IF KNOWN] Task: For each tech debt item, score it on four dimensions using a 1-5 scale and produce a single composite score: 1. Blast radius - how many systems, teams, or customers would be affected if this item causes a failure 2. Incident probability - how likely this item is to cause a production incident in the next two quarters, given the roadmap context above 3. Cost of delay - how much more expensive or risky this item becomes the longer it's left unaddressed (interest accrual, not just current pain) 4. Effort to fix - estimated engineering time, flagged clearly as either a confident estimate (based on reading the actual code or system) or a rough guess Then rank all items by composite score and draw a clear line recommending the top items that fit within the stated sprint capacity for this quarter. Constraints: - Recommend no more than 5 items for this quarter's commitment, regardless of how many items are on the list - Any item with a safety, data-integrity, or compliance dimension must be flagged as a must-fix regardless of its composite score, and called out separately from the ranked list - Do not let "this annoys me as an engineer" stand in for blast radius or incident probability - every score needs a one-sentence justification tied to actual system behavior or business impact - If effort estimates are guesses rather than informed by code inspection, say so explicitly rather than presenting false precision Output format: A markdown table with columns: Item | Blast Radius (1-5) | Incident Probability (1-5) | Cost of Delay (1-5) | Effort (1-5, lower is less effort) | Composite Score | Recommendation (Fix this quarter / Defer / Must-fix regardless of score) Followed by a short narrative (3-4 sentences per item) explaining the reasoning for the top 3 recommended items, and a separate callout box listing any must-fix safety/compliance items that bypass the ranking entirely.
Result
| Item | Blast Radius | Incident Probability | Cost of Delay | Effort | Composite | Recommendation |
|---|---|---|---|---|---|---|
| Auth service still on sync HTTP calls to 3 downstream services, no circuit breaker | 5 | 4 | 5 | 3 | 17 | Fix this quarter |
| Legacy billing cron job has no idempotency key, double-charges on retry | 4 | 3 | 4 | 2 | 13 | Must-fix regardless (compliance/financial risk) |
| Admin dashboard still uses deprecated internal API v1, scheduled for shutdown in 5 months | 2 | 5 | 3 | 3 | 13 | Fix this quarter |
| Test suite takes 47 minutes, no parallelization | 2 | 1 | 2 | 4 | 9 | Defer |
| Inconsistent error logging format across 6 microservices | 2 | 1 | 2 | 2 | 7 | Defer |
Why the top 3
Auth service sync calls (score 17): This is the clearest must-fix for pure risk reasons. With three downstream dependencies and no circuit breaker, a single slow dependency degrades login for the entire platform, and the roadmap shows two new services calling into auth next quarter, which only raises the odds of a cascading timeout. Effort is a confident estimate at 3 because the team already scoped this during the Q2 reliability review.
Billing cron double-charge bug: This bypasses the ranking entirely and goes in the must-fix box. A double-charge is a compliance and trust issue regardless of how rarely the retry path triggers; probability of occurrence doesn't matter when the downside is a refund process and a support escalation every time it fires.
Admin dashboard on deprecated API v1: Incident probability is scored a 5 specifically because the shutdown date is fixed and known — this isn't a maybe, it's a scheduled failure if untouched. Blast radius is lower than the auth item because only internal admin users are affected, which is why it ranks third despite the certain failure date.
Must-fix callout: Billing cron idempotency bug — financial and compliance exposure independent of composite score. Recommend assigning to this sprint even if it displaces one of the ranked items above.
Every engineering team has a tech debt backlog nobody fully trusts. Items get added when something annoys someone, and they get prioritized the same way — by recency of complaint, not by actual risk. That approach reliably produces a quarter spent fixing a minor irritation while the system most likely to cause the next outage sits untouched, because nobody ever scored it against anything concrete.
This prompt forces a structured scoring pass on every item in the backlog before any prioritization decision gets made. It uses four dimensions — blast radius, incident probability, cost of delay, and effort — precisely because those four together capture what "priority" actually means in a production system, and none of them map directly onto how annoying an issue feels to the engineer who has to work around it daily.
Why four dimensions, not one score
A single "priority: high/medium/low" field collapses too much information to be useful, and it's also the field most vulnerable to whoever argues loudest in the planning meeting. Splitting the score into blast radius (how many systems or users are exposed), incident probability (how likely this specific item is to actually fail, given what's shipping next), cost of delay (whether the problem gets worse the longer it sits), and effort (what it actually costs to fix) forces every argument for a ranking to be made in those specific terms. "This really bugs me" doesn't fit into any of the four boxes, which is the point.
Why the must-fix escape hatch matters
Not every risk should be ranked against effort. A compliance or data-integrity bug that happens rarely but causes real damage every time it fires shouldn't lose to a higher-probability-but-lower-stakes item just because the math works out that way. The prompt explicitly carves these out into a separate must-fix category that bypasses the ranked list, because folding them into a composite score either inflates every other item's apparent urgency or buries a genuine liability under a pile of minor performance complaints.
Why effort honesty is a separate constraint
Effort estimates for tech debt are frequently guesses dressed up as numbers, and a team that treats a guessed 3-day estimate the same as a code-verified 3-day estimate ends up blowing through sprint capacity for reasons nobody can trace. Forcing the model to flag which estimates are confident versus rough keeps the output honest about what it actually knows.
How to use the output
Bring the ranked table and the must-fix callout directly into sprint planning. The hard cap of five items per quarter isn't arbitrary — it's there to force a real commitment decision rather than a backlog that grows every sprint without anything actually getting fixed. If your team's capacity genuinely supports more than five, raise the cap, but keep it as a number you have to defend rather than leaving it open-ended.