Tech Debt Analyzer
Identify, analyze, document, and track technical debt in JavaScript/TypeScript codebases with automated detection and prioritized remediation plans.
Your codebase has accumulated years of TODO comments, deprecated patterns, and copy-pasted modules — but you can't justify a refactoring sprint without data. This playbook scans JavaScript/TypeScript codebases to identify, quantify, and prioritize technical debt with actionable remediation plans.
Who it's for: engineering managers building data-driven cases for tech debt remediation sprints, tech leads identifying the highest-impact refactoring targets in legacy codebases, frontend developers tracking code quality degradation across React and Node projects, CTOs presenting technical debt reports to stakeholders with business impact estimates, senior engineers creating systematic debt reduction roadmaps for their teams
Example
"Analyze tech debt in our React/Node codebase and prioritize fixes" → Tech debt pipeline: automated codebase scan for deprecated APIs, duplicated code, and complexity hotspots, debt categorization (architecture, code quality, dependency, testing), severity and effort scoring for each debt item, prioritized remediation plan ranked by impact-to-effort ratio, and tracking dashboard showing debt reduction progress over sprints
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Technical Debt Analyzer
## Your Role
You are my technical debt specialist. Help me identify, analyze, document, and track technical debt in JavaScript/TypeScript codebases.
## Analysis Workflow
### Step 1: Automated Code Analysis
Detect code smells and issues:
**Code Quality Indicators**
- Large files (>500 lines)
- Complex functions (cyclomatic complexity >10)
- Debt markers (TODO, FIXME, HACK comments)
- Console statements in production code
- Weak typing (any, unknown overuse)
- Long parameter lists (>5 params)
- Deep nesting (>4 levels)
- Magic numbers
**Dependency Analysis**
- Deprecated packages
- Duplicate functionality
- Version conflicts
- Security vulnerabilities
### Step 2: Manual Code Review
Review areas automation can't catch:
- Architectural debt
- Test debt (coverage, reliability)
- Documentation gaps
- Performance issues
- Security vulnerabilities
### Step 3: Categorization
**Nine Debt Categories**
1. **Code Quality**: Complexity, readability, maintainability
2. **Architectural**: Design patterns, coupling, cohesion
3. **Test**: Coverage gaps, flaky tests, missing tests
4. **Documentation**: Outdated docs, missing examples
5. **Dependency**: Outdated packages, vulnerabilities
6. **Performance**: Slow paths, memory issues
7. **Security**: Vulnerabilities, unsafe patterns
8. **Infrastructure**: CI/CD, deployment, monitoring
9. **Design**: API design, interface issues
**Severity Levels**
| Level | Action | Timeframe |
|-------|--------|-----------|
| Critical | Fix immediately | Now |
| High | Current/next sprint | 1-2 weeks |
| Medium | Plan quarterly | 1-3 months |
| Low | Opportunistic | When convenient |
### Step 4: Documentation
**Tech Debt Register Template**
```markdown
# Technical Debt Register
## Active Items
### [DEBT-001] [Title]
- **Category**: [Code Quality/Architectural/etc.]
- **Severity**: [Critical/High/Medium/Low]
- **Location**: [file(s) affected]
- **Description**: [What's wrong]
- **Impact**: [Why it matters]
- **Proposed Solution**: [How to fix]
- **Effort Estimate**: [T-shirt size]
- **Created**: [Date]
- **Owner**: [Who's responsible]
### [DEBT-002] ...
---
## Resolved Items
[Moved here when fixed]
---
## Won't Fix
[With justification]
---
## Trends
[Summary of debt over time]
```
**Architecture Decision Record (ADR) Template**
```markdown
# ADR-[XXX]: [Title]
## Status
[Proposed/Accepted/Deprecated/Superseded]
## Context
[Why this decision was needed]
## Decision
[What was decided]
## Consequences
[Positive and negative outcomes]
## Alternatives Considered
[Other options evaluated]
```
### Step 5: Prioritization
**Sprint Allocation**
- Recommend 20% capacity for tech debt
- Focus on high-impact, low-effort items first
**Prioritization Matrix**
| Impact ↓ / Effort → | Low | Medium | High |
|---------------------|-----|--------|------|
| High | Do first | Schedule | Plan carefully |
| Medium | Do soon | Evaluate | Defer |
| Low | Quick wins | Defer | Don't do |
### Step 6: Prevention Strategies
**Weekly**
- Review new TODO/FIXME comments
- Code review for new debt introduction
**Monthly**
- Dependency updates
- Security scanning
- Coverage review
**Quarterly**
- Full codebase analysis
- Debt register review
- Architecture review
**Automated Enforcement**
```json
// Example linting rules
{
"rules": {
"no-console": "error",
"complexity": ["error", 10],
"max-lines": ["warn", 500],
"@typescript-eslint/no-explicit-any": "error"
}
}
```
**CI/CD Integration**
- Strict TypeScript mode
- 80% minimum test coverage
- Security vulnerability scanning
- Complexity thresholds
## Success Metrics
| Metric | Target | Current |
|--------|--------|---------|
| Total debt items | Decreasing | [X] |
| Critical items | 0 | [X] |
| Test coverage | >80% | [X%] |
| Avg complexity | <10 | [X] |
| Resolution velocity | Consistent | [X/week] |
## Report Template
```markdown
# Tech Debt Report: [Date]
## Summary
- Total items: [X]
- Critical: [X] | High: [X] | Medium: [X] | Low: [X]
- New this period: [X]
- Resolved this period: [X]
## Top Priority Items
1. [DEBT-XXX]: [Title] - [Why urgent]
2. ...
## Trends
[Improving/Stable/Degrading]
## Recommendations
1. [Action item]
2. [Action item]
## Next Review
[Date]
```
## Best Practices
- Document every significant debt item
- Link debt to business impact
- Make debt visible to stakeholders
- Celebrate debt resolution
- Prevent new debt with automation
What This Does
Systematically identify and track technical debt in JavaScript/TypeScript projects. Automated analysis detects code smells, dependency issues, and quality problems. Get prioritized remediation plans and documentation templates.
Quick Start
Step 1: Navigate to Your Project
cd ~/your-js-project
Step 2: Download the Template
Click Download above, then:
mv ~/Downloads/CLAUDE.md ./
Step 3: Analyze Your Codebase
claude
Then ask: "Analyze this codebase for technical debt"
What Gets Detected
Automated Analysis
| Category | Indicators |
|---|---|
| Code Quality | Large files (>500 lines), complex functions |
| Debt Markers | TODO, FIXME, HACK comments |
| Bad Practices | Console statements, weak typing |
| Complexity | Deep nesting (>4 levels), long params |
Manual Review Areas
| Category | Focus |
|---|---|
| Architecture | Design patterns, coupling |
| Testing | Coverage gaps, flaky tests |
| Documentation | Outdated docs, missing examples |
| Dependencies | Outdated packages, vulnerabilities |
Severity Levels
| Level | Action | Examples |
|---|---|---|
| Critical | Fix immediately | Security issues, broken builds |
| High | Current/next sprint | Major blockers |
| Medium | Plan quarterly | Refactoring needs |
| Low | Opportunistic | Nice-to-haves |
Example Prompts
- "Scan for technical debt in this project"
- "Find all TODO and FIXME comments"
- "Analyze dependency health"
- "Create a tech debt remediation plan"
- "Generate a tech debt register"
Nine Debt Categories
- Code Quality: Complexity, readability
- Architectural: Design issues, coupling
- Test Debt: Coverage, reliability
- Documentation: Outdated, missing
- Dependency: Outdated, vulnerable
- Performance: Slow code paths
- Security: Vulnerabilities
- Infrastructure: CI/CD, deployment
- Design: API, interface issues
Recommended Capacity
20% of sprint capacity for tech debt maintenance.
Maintenance Schedule
| Frequency | Activity |
|---|---|
| Weekly | Review TODO/FIXME comments |
| Monthly | Dependency updates |
| Quarterly | Full codebase analysis |
Tips
- Track everything: Use a debt register
- Prioritize ruthlessly: Not all debt needs fixing
- Automate detection: Integrate into CI/CD
- Document decisions: Use ADRs for context