Навык Claude Code, который обеспечивает тщательный, цитируемый аудит технического долга всей вашей кодовой базы — а не стандартный чек-лист лучших практик.

Это весь интерфейс. Запустите его в любом репозитории, получите TECH_DEBT_AUDIT.md с результатами, указанными в файлах, серьёзностью, оценками усилий и рейтинговым списком того, что действительно исправить.

Почему это существует

Обзоры кода, генерируемые LLM, проваливаются предсказуемо: они соответствуют шаблонам с общими эвристиками, выявляют очевидные выводы, не закрепляя их в реальном коде, и дают всесторонний результат, на который никто не действует. В результате получается вкладка, которую никто не открывает дважды.

Этот навык имеет своё мнение о том, чтобы избежать такого режима отказа. Три дизайнерских решения выполняют основную работу:

Принудительная ориентация перед суждением. Протокол требует, чтобы модель прочитала манифест, отобрала структуру каталога, проанализировала git-терн и написала ментальную модель архитектуры *до того, как она сформирует мнение. Фаза 1 не является необязательной. Результаты без контекста — это вибрация.

File:line citations по каждому находке. Находка без ссылки нефальсифицируема, а нефальсифицируемые выводы не исправляются. Навык отвергает расплывчатые заявления вроде «код в целом…

tech-debt-audit

A Claude Code skill that produces a thorough, citable tech debt audit of your entire codebase — not a generic best-practices checklist.

/tech-debt-audit

That’s the whole interface. Run it in any repo, get back TECH_DEBT_AUDIT.md with file-cited findings, severity, effort estimates, and a ranked list of what to actually fix.

Why this exists

LLM-generated code reviews fail in a predictable way: they pattern-match against generic heuristics, surface obvious findings without grounding them in the actual code, and produce comprehensive-feeling output that nobody acts on. The result is a tab nobody opens twice.

This skill is opinionated about avoiding that failure mode. Three design choices do most of the work:

Forced orientation before judgment. The protocol requires the model to read the manifest, map the directory structure, analyze git churn, and write a mental model of the architecture before it forms any opinions. Phase 1 isn’t optional. Findings without context are vibes.

File:line citations on every finding. A finding without a citation is unfalsifiable, and unfalsifiable findings don’t get fixed. The skill rejects vague claims like “the code generally…” and requires path/to/file.ext:LINE on every concrete finding.

A required “looks bad but is actually fine” section. This is the single biggest separator between a real audit and a checklist regurgitation. Forcing the model to surface calls it considered making and chose not to is what catches shallow analysis. If that section comes back empty, the audit didn’t look hard enough.

The skill also explicitly forbids recommending rewrites, forbids padding categories with filler, and produces a persistent artifact (TECH_DEBT_AUDIT.md) you can commit and track over time.

Why not the built-in Claude Code skills?

Claude Code ships several skills that touch this space. None of them do what a debt audit needs to do.

What this skill adds:

• Whole-repo scope across the nine dimensions that actually matter for debt: architectural decay, consistency rot, type & contract debt, test debt, dep & config debt, performance & resource hygiene, error handling & observability, security hygiene, and documentation drift.