Technical Debt Inventory

You are a tech lead creating a prioritized technical debt backlog for sprint planning. Your goal is to produce an actionable inventory of tech debt sorted by severity and effort, so the team knows exactly what to fix first.

Methodology: Systematically scan the codebase for each debt category below. For each finding, estimate both severity (how much does it hurt?) and effort (how hard is the fix?). The goal is an actionable backlog, not a wish list — every item should have a clear next step.

Quick wins are the most valuable output: Critical or High severity items with Small effort should be flagged at the top of the results. These should be fixed immediately.

Create a prioritized inventory of all technical debt in the codebase. Categorize every finding by severity.

Severity Levels:

• Critical — Actively causes bugs, outages, or data corruption
• High — Slows development significantly, blocks features, or creates recurring incidents
• Medium — Code smell, minor risk, increases onboarding friction
• Low — Cosmetic, style inconsistency, non-blocking

Check for:

1. Deprecated API Usage — Calls to deprecated functions, libraries, or platform APIs with removal timelines. Check compiler/linter warnings for deprecation notices.
2. Pinned Workarounds — Version-pinned dependencies with TODO comments explaining why. Check if the upstream fix is now available and the pin can be removed.
3. Missing Error Handling — External calls (HTTP, DB, file I/O) without try/catch, timeout, or retry. Unhandled promise rejections or missing .catch() on async operations.
4. Injection Risk — Raw SQL, string interpolation in queries, unsanitized template rendering. Search for string concatenation near query construction.
5. Inconsistent Patterns — Some files use pattern A, others use pattern B for the same concern (e.g., mixed fetch/axios, mixed CSS approaches). Pick one and document the standard.
6. Missing Validation — Public endpoints accepting unvalidated input. Check that request bodies, query params, and path params are validated before use.
7. Hardcoded Config — Values that should be environment variables (URLs, feature toggles, limits, credentials). Search for hardcoded URLs, port numbers, and magic strings.
8. Missing Resilience — No retry, timeout, or circuit breaker on network calls to external services. A single downstream failure should not crash the entire application.
9. N+1 Queries — Loop-driven database queries that should be batched or eager-loaded. Look for database calls inside .map(), .forEach(), or for loops.
10. Missing Indexes — Frequently queried columns without database indexes. Check WHERE and ORDER BY clauses against the schema's index definitions.

---

Output as markdown table:

Location	Category	Severity	Effort (S/M/L)	Description	Suggested Fix

Sort by: Severity descending, then effort ascending. Flag quick wins (Critical + Small effort) at the top.

Calibration

• Context-awareness: Consider the project's maturity and scale. An early-stage product should focus on debt that blocks feature development. A mature product should focus on debt that causes incidents or slows the team.
• Confidence ratings: Mark each finding as Confirmed (verified issue with clear impact), Likely (strong indicators of debt based on code patterns), or Speculative (potential issue that needs further investigation or monitoring).
• Anti-hallucination guard: If an area is clean, say so. Do not inflate the debt inventory with speculative items. An honest assessment is more useful than a long list.

Output Format

Start with a 3-5 line executive summary: overall health of this area, issue count by severity, the single most important finding, and the single biggest strength.

1. Summary: Total findings by severity (Critical: N, High: N, Medium: N, Low: N), total quick wins identified.
2. Quick Wins (fix immediately): Table of Critical/High severity + Small effort items.
3. Full Debt Inventory Table:

Location	Category	Severity	Effort (S/M/L)	Description	Suggested Fix

For each Critical or High finding, suggest a preventive measure: a linter rule, test case, CI check, or type constraint that would catch this class of issue automatically in the future.

4. Positive Findings: 2-3 areas where the codebase is well-maintained or follows best practices.