Tech Debt Analyzer
Identify, analyze, document, and track technical debt in JavaScript/TypeScript codebases with automated detection and prioritized remediation plans.
Download this file and place it in your project folder to get started.
# 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