How do I install the Techdebt Scan skill?

Run npx skillmds@latest add dmitryprg-ai/techdebt-scan in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Techdebt Scan safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: executes scripts. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Techdebt Scan?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Techdebt Scan free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Techdebt Scan?

dmitryprg-ai (@dmitryprg-ai) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Techdebt Scan by dmitryprg-ai — Agent Skill

Name: Techdebt Scan
Rating: 4.5 (4 reviews)
Author: dmitryprg-ai

Techdebt Scan

Scan codebase for technical debt including oversized files, duplicated code, code smells, and TODO items. Use when files exceed size limits, when TODO/FIXME/HACK count is growing, when build is slow, when coverage is low, when user says cleanup/tech debt/code quality, or when empty catch blocks or dead code are suspected.

dmitryprg-ai Updated Sep 10, 2026

File contents

Technical Debt Scanner

Find and safely fix technical debt using a TDD approach.

The order SCAN -> TEST CASES -> REFACTOR -> VERIFY exists because fixing debt without tests creates new debt. Skipping the scan leads to fixing low-impact issues while ignoring critical ones.

Phase 1: SCAN

bash ${CLAUDE_SKILL_DIR}/scripts/scan-large-files.sh
bash ${CLAUDE_SKILL_DIR}/scripts/find-todos.sh

Also check for: functions over 50 lines, nesting deeper than 3 levels, files with 10+ exports, magic numbers.

Phase 2: PRIORITIZE

Impact	Low Effort	High Effort
High (blocks dev)	P0 — Fix now	P1 — Plan carefully
Medium (reduces quality)	P2 — Quick win	P3 — Backlog
Low (cosmetic)	P4 — Optional	Skip

Phase 3: TEST CASES (before refactoring)

Write tests before changing any code because refactoring without tests is gambling. For each selected issue:

Create test cases table
Write failing tests
Verify tests fail (code not changed yet)

Phase 4: REFACTOR

Small steps — one file at a time
Run tests after each change
Commit after each green test

Phase 5: VERIFY

npm run build — success
npm run lint — 0 errors
npm test — all passing

What to avoid

Refactoring without scanning first — you might fix the wrong things
Skipping test cases — creates new bugs while fixing old debt
Writing tests after refactoring — defeats the purpose of TDD safety net
Equating "build passed" with "everything works" — build checks syntax, not behavior

---name: techdebt-scandescription: Scan codebase for technical debt including oversized files, duplicated code, code smells, and TODO items. Use when files exceed size limits, when TODO/FIXME/HACK count is growing, when build is slow, when coverage is low, when user says cleanup/tech debt/code quality, or when empty catch blocks or dead code are suspected.---# Technical Debt ScannerFind and safely fix technical debt using a TDD approach.The order SCAN -> TEST CASES -> REFACTOR -> VERIFY exists because fixing debt without tests creates new debt. Skipping the scan leads to fixing low-impact issues while ignoring critical ones.## Phase 1: SCAN```bashbash ${CLAUDE_SKILL_DIR}/scripts/scan-large-files.shbash ${CLAUDE_SKILL_DIR}/scripts/find-todos.sh```Also check for: functions over 50 lines, nesting deeper than 3 levels, files with 10+ exports, magic numbers.## Phase 2: PRIORITIZE| Impact | Low Effort | High Effort ||--------|-----------|-------------|| High (blocks dev) | P0 — Fix now | P1 — Plan carefully || Medium (reduces quality) | P2 — Quick win | P3 — Backlog || Low (cosmetic) | P4 — Optional | Skip |## Phase 3: TEST CASES (before refactoring)Write tests before changing any code because refactoring without tests is gambling. For each selected issue:1. Create test cases table2. Write failing tests3. Verify tests fail (code not changed yet)## Phase 4: REFACTOR1. Small steps — one file at a time2. Run tests after each change3. Commit after each green test## Phase 5: VERIFY- `npm run build` — success- `npm run lint` — 0 errors- `npm test` — all passing## What to avoid- Refactoring without scanning first — you might fix the wrong things- Skipping test cases — creates new bugs while fixing old debt- Writing tests after refactoring — defeats the purpose of TDD safety net- Equating "build passed" with "everything works" — build checks syntax, not behavior

Frequently asked questions