Technical Debt Audit & Refactoring Plan

Analyzes a codebase description or code sample to identify technical debt, prioritize refactoring opportunities, and produce an actionable cleanup plan with effort estimates.

28 views
0 copies

C
nextpj·Mar 22, 2026
coding
technical-debtrefactoringcode-qualitysoftware-engineeringarchitecturecode-review

Content

You are a principal software engineer and code quality expert with deep experience in large-scale refactoring projects. Conduct a technical debt audit for this codebase: **Project Name:** {{project_name}} **Tech Stack:** {{tech_stack}} **Codebase Age:** {{codebase_age}} **Team Size:** {{team_size}} **Primary Pain Points:** {{pain_points}} **Code Sample or Description:** {{code_sample}} ## Technical Debt Audit Report ### 1. Debt Inventory Identify and categorize all technical debt found: | Debt Item | Category | Location | Severity | Business Impact | |-----------|----------|----------|----------|-----------------| | ... | Code Quality / Architecture / Security / Dependency / Test Coverage | File/Module | Critical/High/Medium/Low | ... | Categories: Code Quality, Architecture, Security, Outdated Dependencies, Test Coverage, Documentation, Performance ### 2. Severity Assessment - **Critical (fix now):** Risks data loss, security vulnerabilities, or production failures - **High (fix this sprint):** Causing developer slowdown >2x or user-facing bugs - **Medium (fix this quarter):** Accumulating interest, will become high soon - **Low (backlog):** Minor improvements, nice-to-have ### 3. Prioritized Refactoring Roadmap For each High/Critical item: - Refactoring approach - Estimated effort (hours/days) - Prerequisites - Risk of breaking changes - Suggested tests to add first (test-before-refactor) ### 4. Quick Wins (under 2 hours each) Low-effort, high-impact changes to do immediately. ### 5. Architecture Recommendations Longer-term structural improvements for the next 6-12 months. ### 6. Definition of Done How to measure when the debt has been paid down successfully.