Technical Debt Assessor

Assess the technical debt in the following code and produce a prioritized remediation plan:

**Project Context**:
- Application type: [e.g., B2B SaaS web app, mobile API, data pipeline]
- Tech stack: [e.g., Python/Django, React, PostgreSQL]
- Team size: [NUMBER OF DEVELOPERS working on this codebase]
- Codebase age: [e.g., 3 years, started as a prototype]
- Current pain points: [WHAT PROMPTED THIS AUDIT? e.g., "New features take 3x longer than expected", "Bugs keep appearing in the billing module"]

**Code to Assess**:
```
[PASTE THE CODE, MODULE, OR FILE(S) YOU WANT ASSESSED. For large codebases, paste the most problematic area first, or paste the directory structure and key files.]
```

**Known Constraints**:
- Upcoming priorities: [WHAT FEATURES OR DEADLINES ARE COMING THAT AFFECT REFACTORING TIMING]
- Off-limits areas: [ANYTHING YOU CANNOT CHANGE RIGHT NOW, e.g., "We cannot swap the ORM until Q3"]

Produce the assessment in this format:

1. **Executive Summary** (3-4 sentences): A non-technical overview of the codebase's health and the business risks of its current state. Written so a product manager or CTO can understand the urgency without reading the full report.

2. **Debt Inventory**: For each item of technical debt found, provide:
   - **ID**: TD-01, TD-02, etc.
   - **Category**: Design Debt (architectural issues), Code Debt (implementation smells), Test Debt (missing or inadequate tests), Dependency Debt (outdated or risky dependencies), Documentation Debt (missing or misleading docs)
   - **Description**: What the problem is and where it lives (file, module, or layer)
   - **Severity**: Critical / High / Medium / Low
   - **Business Risk**: How this debt manifests as a real-world problem (e.g., "Every new payment method requires changes in 4 files instead of 1, tripling development time and bug surface")
   - **Effort Estimate**: T-shirt size (S: hours, M: 1-3 days, L: 1-2 weeks, XL: multi-week project)
   - **Dependencies**: Other debt items that should be resolved first, or features that would be blocked

3. **Debt Distribution**: Summarize how many items fall into each category and severity level. Identify which category carries the most risk.

4. **Priority Matrix**: Rank all items by "impact over effort" ratio. The highest priority items deliver the most risk reduction for the least investment.

5. **Remediation Roadmap**: Organize the debt items into three phases:
   - **Phase 1 (Quick Wins)**: Small-effort, high-impact items to tackle immediately alongside feature work. Target: 1-2 weeks.
   - **Phase 2 (Focused Sprints)**: Medium-effort items that require dedicated sprint time. Target: 1-2 sprints.
   - **Phase 3 (Strategic Refactors)**: Large-effort items that need planning, possibly feature freezes, or phased migration. Target: quarter-level planning.
   For each phase, estimate the cumulative risk reduction (e.g., "Completing Phase 1 eliminates 40% of the identified high-severity debt").

6. **Prevention Recommendations**: 3-5 process or tooling changes that would prevent similar debt from accumulating (e.g., "Add a linting rule to enforce maximum function length", "Require test coverage for new files in CI").