tech-debt-analyzer
This skill should be used when analyzing technical debt in a codebase, documenting code quality issues, creating technical debt registers, or assessing code maintainability. Use this for identifying code smells, architectural issues, dependency problems, missing documentation, security vulnerabiliti
By ailabs-393 · 980 installs
npx skills add ailabs-393/ai-labs-claude-skills --skill tech-debt-analyzer
Source repository · Upstream listing
Technical Debt Analyzer
Overview
Systematically identify, analyze, document, and track technical debt in JavaScript/TypeScript codebases. This skill provides automated analysis tools, comprehensive debt categorization frameworks, and documentation templates to maintain a technical debt register.
Core Workflow
1. Automated Analysis
Run automated scripts to detect technical debt indicators across the codebase.
Code Smell Detection
Identify code quality issues using the automated detector:
The script analyzes:
Large Files: Files exceeding 500 lines
Complex Functions: High cyclomatic complexity ( 10) or long functions ( 50 lines)
Debt Markers: TODO, FIXME, HACK, XXX, BUG comments
Console Statements: Debug statements left in code
Weak Typing: Use of any type in TypeScript
Long Parameters: Functions with 5 parameters
Deep Nesting: Code nested 4 levels deep
Magic Numbers: Hardcoded numeric values
Output Example:
Dependency Analysis
Examine dependencies for debt indicators:
The script identifies:
Deprecated Packages: Known deprecated libraries (request, tslint, etc.)
Duplicate Functionality: Multiple packages serving same purpose
Version Issues: Overly loose or strict version constraints
Security Concerns: Known vulnerable packages (requires audit data)
Output Example:
2. Manual Code Review
Complement automated analysis with manual review for issues that require human judgment.
Review Focus Areas
Architectural Debt:
Tight coupling between components
Missing abstractions
Poor separation of concerns
Circular dependencies
Test Debt:
Missing test coverage for critical paths
Fragile tests coupled to implementation
No integration or E2E tests
Slow test execution
Documentation Debt:
Missing README or setup instructions
No architecture documentation
Outdated API docs
Missing ADRs for major decisions
Performance Debt:
N+1 query problems
Inefficient algorithms
Memory leaks
Large bundle sizes
Security Debt:
Missing input validation
No authentication/authorization
SQL injection vulnerabilities
XSS vulnerabilities
Exposed secrets
3. Categorize and Assess
Organize findings using the standardized debt categories.
Debt Categories
Refer to references/debt categories.md for comprehensive details on:
1. Code Quality Debt: Code smells, complexity, duplication
2. Architectural Debt: Structure, coupling, abstractions
3. Test Debt: Coverage gaps, fragile tests
4. Documentation Debt: Missing or outdated docs
5. Dependency Debt: Outdated or problematic dependencies
6. Performance Debt: Inefficiencies and bottlenecks
7. Security Debt: Vulnerabilities and weaknesses
8. Infrastructure Debt: DevOps and deployment issues
9. Design Debt: UI/UX inconsistencies
Severity Assessment
Assign severity based on impact and urgency:
Critical:
Security vulnerabilities
Production breaking issues
Data loss risks
Action: Immediate fix required
High:
Significant performance problems
Architectural issues blocking features
High risk untested code
Action: Fix within current/next sprint
Medium:
Code quality issues in frequently changed files
Missing documentation
Outdated dependencies (non security)
Action: Address within quarter
Low:
Minor code smells
Optimization opportunities
Nice to have improvements
Action: Address when convenient
Priority Matrix
Impact / Effort Low Effort Medium Effort High Effort
High Impact Do First Do Second Plan & Do
Medium Impact Do Second Plan & Do Consider
Low Impact Quick Win Consider Avoid
4. Document Findings
Create comprehensive documentation of technical debt.
Technical Debt Register
Use the provided template to maintain a debt register:
Template Location: assets/DEBT REGISTER TEMPLATE.md
Structure:
Register Sections:
1. Active Debt Items: Current technical debt needing attention
2. Resolved Items: Historical record of fixed debt
3. Won't Fix Items: Debt accepted as acceptable trade off
4. Trends: Analysis by category, severity, and age
5. Review Schedule: Regular maintenance plan
Architecture Decision Records (ADRs)
Document major technical decisions using ADRs to prevent future debt.
Template Location: assets/ADR TEMPLATE.md
When to Create ADRs:
Choosing frameworks or libraries
Architectural changes
Major refactoring decisions
Technology migrations
Performance optimization strategies
Example:
5. Prioritize and Plan
Create actionable plans to address technical debt.
Prioritization Approach
1. Critical Items: Add to current sprint immediately
2. High Items: Include in sprint planning
3. Medium Items: Add to quarterly roadmap
4. Low Items: Opportunistic fixes during related work
Time Allocation
Recommended Allocation:
20% of sprint capacity for technical debt
Alternating sprints: feature sprint / debt sprint
Dedicated quarterly "tech health" sprint
Tracking Progress
Monitor debt reduction over time:
Metrics to Track:
Total debt items (trend down)
Debt by severity (critical should be 0)
Debt age (old debt is concerning)
Resolution rate (items fixed per sprint)
New debt rate (items added per sprint)
6. Prevention Strategies
Implement practices to minimize new technical debt.
Code Review Checklist
Before approving PRs, verify:
[ ] No code smells introduced (complexity, size, nesting)
[ ] Tests added/updated with adequate coverage
[ ] Documentation updated (README, comments, ADRs)
[ ] No security vulnerabilities
[ ] Performance impact considered
[ ] No new dependencies without justification
[ ] Follows team conventions and patterns
Automated Prevention
Linting and Formatting:
Required Checks:
TypeScript strict mode enabled
Minimum test coverage threshold (80%)
No high severity security vulnerabilities
Bundle size limits enforced
Regular Maintenance
Weekly:
Review and triage TODO/FIXME comments
Update debt register with new findings
Monthly:
Dependency updates (security patches)
Debt register review
Plan fixes for high priority items
Quarterly:
Full codebase debt analysis
Architecture review
Major dependency updates
Trend analysis and strategy adjustment
Decision Tree
Follow this workflow based on the situation:
Starting a new analysis?
→ Run automated scripts (detect code smells.py, analyze dependencies.py)
→ Review output for high severity issues
→ Conduct manual review for areas scripts can't detect
→ Go to documentation step
Documenting findings?
→ Copy DEBT REGISTER TEMPLATE.md to project root
→ Add each debt item with full details
→ Categorize by type and assign severity
→ Estimate effort and prioritize
→ Go to planning step
Planning debt reduction?
→ Sort by priority matrix (impact/effort)
→ Allocate sprint capacity (20% recommended)
→ Create tickets for top priority items
→ Schedule regular reviews
Making architectural decisions?
→ Copy ADR TEMPLATE.md
→ Document context, options, and decision
→ Identify any debt being incurred
→ Add to debt register if applicable
Preventing new debt?
→ Implement code review checklist
→ Configure automated linting/testing
→ Set up regular maintenance schedule
→ Monitor metrics over time
Tools and Scripts
detect code smells.py
Purpose: Automated code quality analysis
Usage:
Detects:
Large files ( 500 lines)
Complex functions (complexity 10)
Technical debt markers (TODO, FIXME, HACK)
Console statements
Weak TypeScript typing
Long parameter lists ( 5 params)
Deep nesting ( 4 levels)
Magic numbers
Output: Markdown report or JSON for programmatic processing
analyze dependencies.py
Purpose: Dependency health analysis
Usage:
Detects:
Deprecated packages (request, tslint, node sass, etc.)
Duplicate functionality (multiple date libs, http clients, etc.)
Unsafe version constraints ( , latest)
Overly strict versions (exact versions without ^ or ~)
Output: Markdown report with recommendations
Reference Documentation
debt categories.md
Comprehensive guide to technical debt types with:
9 major debt categories
Indicators and examples for each
Impact assessment criteria
Severity level definitions
Measurement metrics
Prevention strategies
Load this reference when:
Need detailed examples of specific debt types
Assessing severity and impact
Understanding root causes
Planning prevention strategies
Documentation Templates
DEBT REGISTER TEMPLATE.md
Complete technical debt register template including:
Debt item structure
Status tracking
Impact assessment format
Trend analysis sections
Review schedule
Use this template to:
Start a new debt register
Standardize debt documentation
Track debt across team/project
ADR TEMPLATE.md
Architecture Decision Record template including:
Context and problem statement
Options considered
Decision rationale
Consequences (positive and negative)
Implementation plan
Use this template to:
Document major technical decisions
Prevent future "why did we do this?" questions
Track technical debt incurred by decisions
Best Practices
Analysis Best Practices
1. Run analysis regularly (weekly or bi weekly)
2. Combine automated + manual review for comprehensive coverage
3. Focus on high churn areas first for maximum impact
4. Involve the team in debt identification
5. Be objective all codebases have debt
Documentation Best Practices
1. Be specific include file names, line numbers, examples
2. Explain impact why does this matter?
3. Propose solutions don't just complain, suggest fixes
4. Estimate effort helps with prioritization
5. Track trends is debt increasing or decreasing?
Remediation Best Practices
1. Fix critical items immediately especially security
2. Allocate consistent time 20% of sprint capacity
3. Celebrate wins track and recognize debt reduction
4. Don't let perfect be the enemy of good incremental improvement
5. Prevent new debt easier than fixing old debt
Communication Best Practices
1. Make debt visible share metrics with stakeholders
2. Educate on impact connect debt to business outcomes
3. Get buy in explain ROI of debt reduction
4. Regular updates include in sprint reviews
5. Avoid blame focus on improvement, not fault
Example Workflow
Complete workflow from analysis to resolution:
Week 1: Analysis
Week 1 2: Documentation
Week 2: Prioritization
Weeks 3 6: Remediation
Monthly: Review
Success Metrics
Track these metrics to measure debt reduction effectiveness:
Quantity Metrics:
Total debt items (trending down)
Debt by severity (zero critical)
Debt items per 1000 LOC
Quality Metrics:
Test coverage (trending up)
Cyclomatic complexity (trending down)
Average file/function size (stable or decreasing)
Velocity Metrics:
Debt items resolved per sprint
New debt items per sprint (should be low)
Time to resolve (should decrease)
Business Metrics:
Bug rate (should decrease)
Feature delivery speed (should increase)
Developer satisfaction (should increase)