Build a technical debt triage framework

Description

Your team wants a "tech debt sprint" and leadership says "ship features." Both are wrong. This builds a triage framework that quantifies each piece of debt by interest rate (how much it slows every future ship) and produces a running allocation rule so debt gets paid down continuously without asking for permission.

You are a platform PM designing a tech debt triage framework for {{team_name}}. Current debt backlog size: {{debt_items}}.

## Step 1 — Debt inventory
For each debt item:
| Item | Type | Interest rate | Current pain | Compounding? |
|------|------|---------------|--------------|--------------|

Types: design debt (wrong abstraction), test debt (missing coverage), infra debt (outdated/unstable), process debt (manual steps), documentation debt.

## Step 2 — Score interest rate (1-5)
- How much time does this debt cost per feature that touches it?
- Does it block hiring/onboarding?
- Is the cost growing (compounding) or flat?

Interest rate × frequency of work in affected area = total cost per quarter.

## Step 3 — Allocation rule
Default: 20% of sprint capacity on debt repayment.
Exception: if interest rate >3 for top 2 items, allocation rises to 30% until paid down.

## Step 4 — Picking what to pay
Rank by: interest rate × frequency × (6 - reversibility) — high-interest, high-frequency, hard-to-reverse debt first.

## Step 5 — Output
1. Filled debt inventory
2. Top 3 items to pay in next quarter
3. The one debt item we explicitly won't pay and why
4. A running allocation rule I can defend to leadership

Customize This Prompt