Every backlog has a “tech debt” tag with 50 tickets nobody works on. A good prioritization prompt evaluates each item by impact, effort, and decay risk — and outputs at most 5 things to actually do this quarter.
Who this is for
Tech leads writing a quarterly tech-debt plan, founders deciding whether to invest a sprint in cleanup, engineers building a case for refactor budget.
When not to use these prompts
Don’t use these to justify a rewrite — that’s a separate conversation. Don’t use them without business context (revenue, deadlines, hiring).
Prompt anatomy / structure formula
Every prioritization prompt should carry six elements:
- Role: who AI plays (SRE / release captain / staff engineer / QA lead).
- Context: stack / branch / failing logs / diff / dashboard URL.
- Goal: one concrete deliverable — root cause, checklist, plan, ticket list, runbook.
- Constraints: what AI MUST NOT do (don’t auto-fix, don’t hallucinate file paths).
- Output format: numbered findings, markdown table, JSON, unified diff, runnable code.
- Examples / signal: 1-2 “good” output examples, or counter-examples.
Best for
- Quarterly tech-debt triage
- Pre-launch hardening list
- Cleanup case for product leadership
- Onboarding-friction reduction plan
- Build a cost-of-delay model for debt
12 copy-ready prompt templates
1. Score by impact × effort × decay
Score each debt item: (a) IMPACT (1-5): user-visible / dev-velocity / risk, (b) EFFORT (S / M / L weeks), (c) DECAY (Stable / Growing / Compounding). Final score = IMPACT × DECAY weight ÷ EFFORT. Output a ranked table. Treat any "Compounding + L effort" specially — those eat the future.2. “Why now” filter
For each debt item, answer: "What changes in the next 90 days that makes this urgent?" (e.g., hiring 3 backend devs, launching to enterprise, EU rollout, framework EOL). Drop items whose answer is "nothing".3. Bundle related items
Cluster these {nItems} debt items into themes. For each theme: top 1-2 items + bundled cleanup that can ride along. Bundling cuts overhead — but only if items share files / mental model. Don't bundle unrelated items.Variables to swap: nItems
4. Sunset candidates
Identify code / features eligible for sunset: (1) Low usage + high maintenance cost, (2) Replaced internally but never removed, (3) Behind a feature flag that's been on for > 12 months. Output: candidates + a decommission plan.5. Onboarding-friction debt
Audit debt that slows new-hire onboarding: (1) Undocumented build steps, (2) Magic env vars, (3) Local dev requires manual seed, (4) "Just ask {person}" knowledge. Prioritise the items that block a new hire in the first week.6. Velocity-impact debt
Audit debt that slows weekly velocity: (1) Tests > 10 min, (2) PRs that need 3+ approvals due to ownership ambiguity, (3) Build flake > 5%, (4) Areas of code requiring "specialist" review. Output top 3 + ROI estimate.7. Risk-led debt
Audit debt that creates production risk: (1) Single points of failure, (2) Manual deploy steps, (3) No rollback for X service, (4) Logs missing for critical path, (5) Off-team-owned code blocking incident response. Severity-rank.8. Cost-of-delay model
For 5 candidate debts, estimate cost-of-delay: (a) Pain today (hours / quarter), (b) Pain in 1 year if untouched, (c) Fix cost. Output ROI = (FuturePain - TodayPain) / FixCost. Recommend top 3 to fund this quarter.9. Tech-debt narrative for leadership
Take these 3 prioritized items and write a 200-word narrative for a product / business audience: (1) Each item in plain language, (2) Business consequence if untouched, (3) Engineering investment + outcome, (4) Why now. No jargon.10. Anti-bundle: “stop bundling fixes with features”
Audit the last 10 feature PRs for hidden cleanup. List places where cleanup was bundled, making the PR harder to review. For each: extract the cleanup into a follow-up ticket. Output ticket drafts.11. Debt freeze plan
We can't fix this quarter — design a debt FREEZE plan: (1) Areas we'll stop adding to until cleaned up, (2) Compatibility shims to keep new features off the bad code, (3) Comms to the team. Output a 1-page plan.12. Post-mortem → debt items
Convert this post-mortem into 1-3 debt tickets: title, problem, acceptance criteria, owner, decay class. Don't re-litigate the incident — focus on prevention.Common mistakes
- Treating loudness as priority — the engineer most upset isn’t always right.
- No effort estimate — every item looks “important”.
- No decay model — Compounding debt is silent but expensive.
- Trying to fund > 5 items per quarter — none ship cleanly.
- No business framing — leadership won’t fund what they don’t understand.
- Bundling debt fix into a feature PR — reviewer can’t see either properly.
- Forgetting to sunset replaced code — it haunts forever.
How to push results further
- Track DECAY explicitly. Stable debt can wait; Compounding cannot.
- 5 items max per quarter — anything more is wish-listing.
- Bundle related items, but never bundle features and cleanups in the same PR.
- Make the cost-of-delay model visible to leadership.
- Re-run prioritization quarterly — context changes.
- For each item, name a single owner and a deadline.
- Sunset > rewrite > refactor > tolerate. Try in that order.
Practical depth notes
Use these prompts as starting points, not final answers. For Technical Debt Prioritization Prompts: 12 Templates Beyond a Backlog, the useful extra work is to replace every generic placeholder with a real constraint: audience, channel, length, brand voice, examples to imitate, and examples to avoid. Run at least two versions with different constraints, then compare the outputs side by side instead of accepting the first polished response.
A good result should pass three checks: it is specific enough that another person could reuse it, it avoids vague praise or filler, and it gives you an editable artifact rather than a broad suggestion. If the output feels generic, add one concrete reference, one forbidden pattern, and one measurable success criterion before rerunning the prompt.
FAQ
- How much time should we spend on tech debt?: Common range: 15-25% of capacity. Higher in legacy-heavy contexts, lower in pure greenfield.
- Should AI choose priorities?: AI scores; humans decide. AI can’t see hiring plans and customer commitments.
- What’s “Compounding” debt?: Debt where the cost of fixing later is materially higher than today (e.g., schemas being widened, new dependencies on a deprecated lib).
- How do I justify cleanup with no immediate revenue?: Use the cost-of-delay model — translate to dev-velocity hours or risk exposure.
- Should everyone work on debt every sprint?: Not necessarily — rotate or allocate a “fixer” slot per sprint.
- When should I rewrite?: Almost never. Try sunset / refactor first. Rewrite is a 3-year detour.
Related
- Refactor prompts
- Full repository audit prompts
- Code review prompts
- Deployment check prompts
- Coding & Developer Prompts hub
Tags: #Prompt #Coding #Tech debt #Refactor