Legacy Code Refactoring Prioritization Matrix
Assess technical debt hotspots and build an actionable refactoring risk-versus-impact prioritization matrix.
Use this template when planning codebase modernization or paying down technical debt. It enables software teams to categorize code rot, calculate regression risks, and sequence refactoring initiatives into a clear decision matrix.
Role: Staff Software Engineer and Technical Debt Remediation Lead
Context
- Target codebase or module: {{codebase_module}}
- Known defect patterns and bug history: {{known_defects}}
- Current test coverage and automated safety nets: {{test_coverage_level}}
- Strategic business criticality: {{business_criticality}}
- Impact on engineering velocity: {{developer_velocity_impact}}
- Target delivery milestone: {{target_milestone}}
Task
Produce a technical debt audit and refactoring prioritization matrix for {{codebase_module}} that balances architectural health against delivery risks ahead of {{target_milestone}}.
Method
- Deconstruct {{codebase_module}} into its core subcomponents, interfaces, and shared state layers.
- Correlate {{known_defects}} with code complexity indicators (e.g., cyclomatic complexity, tight coupling, stale dependencies).
- Assess {{test_coverage_level}} to determine regression danger for each target subcomponent.
- Grade each refactoring candidate on an Impact scale (1-5) using {{developer_velocity_impact}} and {{business_criticality}}.
- Grade each candidate on an Implementation Risk scale (1-5) based on blast radius and testing gaps.
- Plot components into an Effort vs. Value prioritization matrix (Quick Wins, Strategic Investments, Defer, Avoid).
- Outline incremental refactoring techniques (e.g., Strangler Fig, Branch by Abstraction) for top priorities.
- Formulate a phased sprint execution schedule aligned with {{target_milestone}}.
Constraints
- MUST present the core output as a multidimensional prioritization matrix scored across effort, risk, and velocity gain.
- MUST establish explicit automated testing prerequisites before recommending destructive code changes.
- MUST NOT propose complete ground-up rewrites unless modular refactoring is proven unviable.
- Scores in the matrix must be fully justified by reference to {{known_defects}} and {{business_criticality}}.
Output format
- Module Technical Health Summary (150 words diagnosing core debt in {{codebase_module}}).
- Refactoring Prioritization Matrix (Table: Subcomponent, Risk Score, Impact Score, Refactoring Pattern, Priority Quadrant).
- High-Priority Execution Blueprints (2-3 structured plans with prerequisite tests, pattern choice, and rollback plan).
- Milestone Alignment Roadmap (Phased schedule mapped to {{target_milestone}}).
Self-review
- Ensure every subcomponent scored in the matrix has a clear dependency profile.
- Check that low {{test_coverage_level}} areas are flagged with higher risk scores.
- Confirm refactoring milestones are realistically achievable within {{target_milestone}}.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.