Agent skill

Assess Technical Debt

by tobihagemann in tobihagemann/turbo

Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, architecture rot, and low-value tests.

MITAuto-check passedDevelopment

Install Assess Technical Debt

skills CLI
$ npx skills add tobihagemann/turbo --skill assess-technical-debt -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install tobihagemann/turbo assess-technical-debt --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/tobihagemann/turbo.git skills-src && mkdir -p .claude/skills && cp -r skills-src/codex/skills/assess-technical-debt .claude/skills/assess-technical-debt && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
assess-technical-debt
GitHub stars
408
Token cost
~2.8k tokens
SKILL.md length
1,358 words
Files
2 (incl. references)
Skills in repo
81
Repo updated
First seen
Licence
MIT

At a glance

Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, architecture rot, and low-value tests.

  • Works in 6 steps: Scope and Partition → Run Debt Analysis Agents → Run $evaluate-findings Skill → …
  • The user asks to assess technical debt
  • SKILL.md covers Task Tracking, Step 1: Scope and Partition, Step 2: Run Debt Analysis Agents and Step 3: Run $evaluate-findings…, plus 4 more sections
  • Calls git

What it does

Assess Technical Debt is an agent skill from tobihagemann/turbo. Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, architecture rot, and low-value tests. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", "what's our worst code", "find low-value tests", or "which tests can we delete". Analysis-only —…

Its SKILL.md is about 2.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/debt-reviewer.md`).

It sits in Development, covering Technical debt and Refactoring. The repository describes itself as: Reusable workflows for planning, building, reviewing, and shipping with Claude Code and Codex. The licence is MIT.

When your agent uses it

  • The user asks to assess technical debt
  • Find technical debt
  • Review technical debt
  • What should we refactor

Example prompts

  • “assess technical debt”
  • “find technical debt”
  • “review technical debt”
  • “/assess-technical-debt”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Scope and Partition
  2. Run Debt Analysis Agents
  3. Run $evaluate-findings Skill
  4. Resolve Escalated Findings
  5. Rank and Write Markdown Report
  6. Generate HTML Report

What it can do on your machine

Read from SKILL.md and the folder at commit 931eda5. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Assess Technical Debt loads about 2.8k tokens when it runs, and up to ~5.1k if it reads all its reference files. Until then it costs about 140 tokens; SKILL.md has 1,358 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~140
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from tobihagemann/turbo at commit 931eda5, republished under its MIT licence (© tobihagemann). 1,358 words, ~2,790 tokens.

Download SKILL.mdSave it as .claude/skills/assess-technical-debt/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
assess-technical-debt
description
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, architecture rot, and low-value tests. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", "what's our worst code", "find low-value tests", or "which tests can we delete". Analysis-only — does not modify code.

Assess Technical Debt

Surface the structural debt that routine review keeps out of scope: long-lived complexity, deprecated APIs, duplication, tangled architecture, and low-value tests that need deliberate refactoring. Project-wide, analysis-only. Ranks each finding by impact and effort and writes .turbo/technical-debt.md and .turbo/technical-debt.html.

Task Tracking

At the start, use update_plan to track each phase, restating any remaining steps of a parent workflow alongside them:

  1. Scope and partition
  2. Run debt analysis agents
  3. Run $evaluate-findings skill
  4. Resolve escalated findings
  5. Rank and write markdown report
  6. Generate HTML report

Step 1: Scope and Partition

If $ARGUMENTS specifies paths, assess those directly (skip the question).

Otherwise, use request_user_input to confirm scope:

  • Whole codebase — assess all source and test files
  • Specific paths — user provides directories or file patterns

Once scope is determined:

  1. Glob for source and test files in the selected scope. Exclude generated and vendored directories (node_modules/, dist/, build/, vendor/, __pycache__/, .build/, DerivedData/, target/, .tox/, and others appropriate to the project).
  2. Partition files by top-level directory. If a single directory holds far more files than its siblings, sub-partition it by its immediate subdirectories.

Step 2: Run Debt Analysis Agents

Before dispatching, read the project's test configuration and CI workflow to identify any test tier that resets a shared external resource between tests, such as a database, a fixed port, or a cache. Such tiers have no cross-process interlock, so sub-agents running them concurrently wipe each other's state and return failures that look like real defects. Name any such tier to every sub-agent as off-limits.

Launch the agents below with spawn_agent / wait_agent using inherited model defaults, issuing every call in one batch. Do not issue one and await its result before issuing the rest. Each sub-agent's prompt instructs it to read references/debt-reviewer.md for the debt taxonomy, detection heuristics, the impact/effort rubric, and the finding output format before scanning, and to treat the shared working tree and its git index as read-only — any empirical check runs in an isolated git worktree created under $TMPDIR and discarded afterward. Each sub-agent keeps the scratch files it writes, such as its starting git status snapshot, probes, and logs, in a scratch directory of its own, uniquely named under $TMPDIR, and refers to it by absolute path. HEAD stays where it is: read other refs with git show <ref>:<path> rather than git checkout or git switch. Refer to that worktree by absolute path in every command and join chained steps with &&, so a failed step cannot leave the rest running in the shared checkout. Run teardown and verification as their own commands. Give that worktree its own dependency install rather than reaching the shared tree's install by any route: removing a worktree deletes through symlinks, and a redirected suite writes into the shared install. When its own install is not possible, the check is left unrun and reported as such. Every test runner the sub-agent starts, in a worktree or in the shared checkout, runs in its own process group under a timeout enforced from outside the runner. Before teardown, the sub-agent stops the process group of every runner it started, since stopping a runner can leave the processes it spawned alive. Afterward the sub-agent verifies that git worktree list no longer shows the worktree, that git status --short shows what it showed at the start, that HEAD is still on the branch it started on, and that the shared tree's dependency directory still resolves (a destroyed install leaves git status unchanged, since it is gitignored). It also confirms that no process from those groups, and none whose command line names the worktree path, if any, is still running, and reports by PID any process it could not stop. When it cannot list processes, it reports that check as unrun and names those process groups and the worktree path, if any. Damage the sub-agent cannot repair is reported with the exact repair command in place of findings.

Expect (one per partition, plus one project-wide architecture agent) Codex sub-agent calls total. State the count explicitly before emitting the batch.

  • Partition agents — one per partition from Step 1. Each scans its files for complexity hotspots, deprecated API usage, duplication, and low-value tests, and notes coupling it observes reaching outside the partition. Pass the partition's file list and the full project root path.
  • Architecture agent — one project-wide pass over the scoped tree for architecture rot: tangled module boundaries, circular dependencies, layering violations, and refactor candidates that span modules. Pass the partition map and the full project root path.

If more partitions exist than fit a single fan-out, group related directories so the partition agents stay within a manageable batch, and note the grouping in the report.

Step 3: Run $evaluate-findings Skill

Aggregate all findings from all agents. Deduplicate items that surface in more than one agent (e.g., duplication a partition agent and the architecture agent both flag). Run the $evaluate-findings skill once on the combined set to verify each finding against the actual code and weed out false positives.

Show full SKILL.md (526 more words)Show less

Step 4: Resolve Escalated Findings

Skip when Step 3 assigned no Escalate verdict.

For each finding with an Escalate verdict, output its technical detail as text first, including the fact that forces the choice. Then use request_user_input to state the question as the decision the user owns, offering the report outcomes the finding leaves open:

  • Rank as debt — the finding enters the priority matrix with its recommended refactor. When the finding carries competing refactors, offer each as its own option.
  • Record as intentional — the finding stays out of the priority matrix and is listed with the decision
  • Get a second opinion — run the $consult-claude skill for a second opinion on the choice, then ask again with that answer in hand. Offer it when the choice is costly to reverse (it establishes a pattern others will follow, defines an interface, or commits to a data shape), and whenever no option earns (Recommended) with conviction.

Place the strongest option first and append (Recommended) to its label. When the choice hinges on product intent or domain knowledge you lack, say so instead of forcing a pick. Keep the question within three options: when the outcomes exceed that, offer the ones that fit the finding best, with the consultation option among them when it applies, and resolve a freeform answer naming an outcome left out the same way as a selected one.

Step 5: Rank and Write Markdown Report

Assign each surviving finding an impact (maintenance drag, change risk, blast radius) and an effort (rough refactor size) per the rubric in references/debt-reviewer.md. Sort findings into priority tiers:

  • Quick wins — high impact, low effort
  • Strategic refactors — high impact, high effort
  • Incremental — low-to-medium impact, low effort
  • Defer — low impact, high effort

Leave a finding recorded as intentional in Step 4 out of the Summary counts and the Priority Matrix, and list it under its dimension in Detailed Findings with that decision. Record the decision beside each escalated finding ranked as debt as well.

Output the summary and priority matrix as text. Then write .turbo/technical-debt.md using the template below.

Report Template
markdown
# Technical Debt Assessment

**Date:** <date>
**Scope:** <what was assessed>

## Summary

| Dimension | Findings | High impact |
|---|---|---|
| Complexity hotspots | <N> | <N> |
| Deprecated API usage | <N> | <N> |
| Duplication clusters | <N> | <N> |
| Architecture rot | <N> | <N> |
| Low-value tests | <N> | <N> |

## Priority Matrix

Ranked by impact against refactor effort. Take quick wins first; schedule strategic refactors deliberately.

### Quick Wins (high impact, low effort)
| Item | Dimension | Location | Recommended refactor |
|---|---|---|---|

### Strategic Refactors (high impact, high effort)
| Item | Dimension | Location | Recommended refactor |
|---|---|---|---|

### Incremental (low–medium impact, low effort)
| Item | Dimension | Location | Recommended refactor |
|---|---|---|---|

### Defer (low impact, high effort)
| Item | Dimension | Location | Recommended refactor |
|---|---|---|---|

## Detailed Findings

### Complexity Hotspots
<findings: location, description, impact, effort, recommended refactor, and the recorded decision for an escalated finding>

### Deprecated API Usage
<findings>

### Duplication Clusters
<findings>

### Architecture Rot
<findings>

### Low-Value Tests
<findings>

---
This assessment covers in-code structural debt. For dependency freshness and diff-scoped bugs, run `$review-dependencies` and `$review-code`.

Step 6: Generate HTML Report

Convert the markdown report into a styled, interactive HTML page.

  1. Run the $frontend-design skill to load design principles.
  2. Read .turbo/technical-debt.md for the full report content.
  3. Write a self-contained .turbo/technical-debt.html (single file, no external dependencies beyond Google Fonts) that presents all findings from the markdown report with:
    • Summary grid with per-dimension finding counts
    • Priority matrix laid out as an impact-by-effort quadrant, color-coded by tier (quick wins highlighted)
    • Sticky navigation between sections
    • Collapsible dimension sections
    • [hidden] { display: none !important; } in the base styles, so a section whose own CSS sets a display value still hides
    • Finding cards with location, impact, effort, recommended refactor, and the recorded decision where one exists
    • Impact and effort badges with color-coding
    • Entrance animations and hover states
    • Print-friendly styles via @media print
    • Responsive layout for mobile

Then call update_plan to mark this step completed and continue with the next step of the active workflow.

Rules

  • Analysis-only: do not modify source code, stage files, or commit.
  • If no significant debt is found, report that explicitly and note any scope limitations or analysis caveats.

© tobihagemann, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in codex/skills/assess-technical-debt of tobihagemann/turbo.

  • SKILL.md
  • references/debt-reviewer.md

Open the folder on GitHubat commit 931eda5

Compare with similar skills

Assess Technical Debt next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Assess Technical Debt compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Assess Technical Debt this skilltobihagemann/turbo408—~2.8kAutomated safety check: PassMIT
Systematic Code Refactoringluongnv89/claude-howto42k—~3kAutomated safety check: PassMIT
Code Simplification for ego-litecitrolabs/ego-lite17k—~1.2kAutomated safety check: PassMIT
Code Refactoring Workflowluongnv89/claude-howto42k—~3.1kAutomated safety check: PassMIT
FIXME Resolvertailcallhq/forgecode7.6k—~1.1kAutomated safety check: PassApache-2.0
DesloppifyGit-on-my-level/codex-autorunner875—~3.4kAutomated safety check: PassMIT

Similar skills

  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated today
    DevelopmentAuto-check passed
  • Finds and implements evidence-backed simplifications in the ego-lite repository, such as dead code, duplicated state and speculative abstractions, without hiding behavior changes.

    17k GitHub stars~1.2k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Code Refactoring Workflow

    luongnv89/claude-howto

    Guides systematic, test-backed refactoring in the style of Martin Fowler, moving through research, planning and small incremental changes with your approval at each phase.

    42k GitHub stars~3.1k tokensUpdated today
    DevelopmentAuto-check passed
  • FIXME Resolver

    tailcallhq/forgecode

    Finds every FIXME comment in a codebase, groups related ones across files into one task, implements the work they describe and removes the comments once it is done.

    7.6k GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed
  • Desloppify

    Git-on-my-level/codex-autorunner

    Codebase health scanner and technical debt tracker. An agent skill from Git-on-my-level/codex-autorunner.

    875 GitHub stars~3.4k tokensUpdated 2 days ago
    DevelopmentAuto-check passed
  • Tech Debt Analyzer

    ailabs-393/ai-labs-claude-skills

    This skill should be used when analyzing technical debt in a codebase, documenting code quality issues, creating technical debt registers, or assessing code maintainability.

    455 GitHub starsUsed in 1 repo~3.9k tokens
    DevelopmentAuto-check passed

More from tobihagemann/turbo

All 81 skills in this repo
  • Consult Oracle

    tobihagemann/turbo

    Consult ChatGPT Pro via ChatGPT browser automation for problems that resist standard approaches.

    408 GitHub stars~1.1k tokensUpdated 2 days ago
    Auto-check passed
  • Fetch PR Comments

    tobihagemann/turbo

    Fetch and summarize review feedback and conversation from a GitHub PR (unresolved review threads, review bodies, and PR conversation comments) without making changes.

    408 GitHub stars~967 tokensUpdated 2 days ago
    Auto-check passed
  • Recall Rationale

    tobihagemann/turbo

    Recall why a past change was made by locating the Claude Code transcript that produced it.

    408 GitHub stars~1.3k tokensUpdated 2 days ago
    Auto-check passed
  • Resolve PR Comments

    tobihagemann/turbo

    Evaluate, fix, answer, and reply to GitHub pull request review comments and conversation comments.

    408 GitHub stars~3.8k tokensUpdated 2 days ago
    Auto-check passed
  • Resolve PR Comments

    tobihagemann/turbo

    Evaluate, fix, answer, and reply to GitHub pull request review comments and conversation comments.

    408 GitHub stars~3.8k tokensUpdated 2 days ago
    Auto-check passed
  • Codex Exec

    tobihagemann/turbo

    Run autonomous task execution using the codex CLI. An agent skill from tobihagemann/turbo.

    408 GitHub stars~2.5k tokensUpdated 2 days ago
    Auto-check passed

Categories

Questions about Assess Technical Debt

What does Assess Technical Debt do?

Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, architecture rot, and low-value tests. Assess Technical Debt is an agent skill from tobihagemann/turbo. Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, architecture rot, and low-value tests.

When should I use Assess Technical Debt?

Assess Technical Debt fits situations like: the user asks to assess technical debt; find technical debt; review technical debt; what should we refactor.

How do I install Assess Technical Debt in Claude Code?

Run `npx skills add tobihagemann/turbo --skill assess-technical-debt -a claude-code`. Or copy the skill folder (codex/skills/assess-technical-debt in tobihagemann/turbo) into .claude/skills/assess-technical-debt in your project. Claude Code loads it when a task matches its description.

How do I install Assess Technical Debt in Codex?

Run `npx skills add tobihagemann/turbo --skill assess-technical-debt -a codex`. Or copy the skill folder (codex/skills/assess-technical-debt in tobihagemann/turbo) into .agents/skills/assess-technical-debt in your project. Codex loads it when a task matches its description.

Can I use Assess Technical Debt in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add tobihagemann/turbo --skill assess-technical-debt -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/assess-technical-debt, .gemini/skills/assess-technical-debt, .github/skills/assess-technical-debt and .opencode/skills/assess-technical-debt in your project.

What does Assess Technical Debt need to run?

Going by SKILL.md and its folder, Assess Technical Debt needs the command-line tools its instructions call (git).

Does Assess Technical Debt access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Assess Technical Debt safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Assess Technical Debt use?

Assess Technical Debt is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Assess Technical Debt use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.3k tokens, read only when the agent opens those files.

What are the alternatives to Assess Technical Debt?

Skills that share tags, products or a category with Assess Technical Debt: Systematic Code Refactoring (luongnv89/claude-howto, 42k stars), Code Simplification for ego-lite (citrolabs/ego-lite, 17k stars), Code Refactoring Workflow (luongnv89/claude-howto, 42k stars) and FIXME Resolver (tailcallhq/forgecode, 7.6k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Assess Technical Debt?

tobihagemann (a GitHub user) maintains it in tobihagemann/turbo, which has 408 GitHub stars. The repository holds 81 skills in this directory. The repository was last updated on October 9, 2026.

Source: tobihagemann/turbo on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.