assess-technical-debt
Assess-technical-debt analyzes a codebase to identify structural issues including complexity hotspots, deprecated API usage, code duplication, and architectural problems, then ranks findings by impact and refactoring effort. Use this skill when asked to evaluate technical debt, find refactoring candidates, or review code quality across a project. The analysis generates detailed reports in markdown and HTML formats without modifying any code.
git clone --depth 1 https://github.com/tobihagemann/turbo /tmp/assess-technical-debt && cp -r /tmp/assess-technical-debt/codex/skills/assess-technical-debt ~/.claude/skills/assess-technical-debtSKILL.md
# Assess Technical Debt Surface the structural debt that routine review keeps out of scope: long-lived complexity, deprecated APIs, duplication, and tangled architecture 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. Rank and write markdown report 5. 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: - **All source files** — assess the whole codebase - **Specific paths** — user provides directories or file patterns Once scope is determined: 1. Glob for source 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 source 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](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. HEAD stays where it is: read other refs with `git show <ref>:<path>` rather than `git checkout` or `git switch`. 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. Afterward the sub-agent verifies that `git worktree list` no longer shows the worktree, that `git status --short` is clean, 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` clean, since it is gitignored). 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, and duplication, 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. ## Step 4: 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](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 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> | ## 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, re
For each reviewer question on a PR, recall implementation reasoning and compose a raw answer. Use when the user asks to \"answer reviewer questions\", \"draft answers to PR questions\", or \"explain reviewer questions\".
Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\".
Project-wide health audit pipeline that fans out to all analysis skills in parallel, evaluates findings, and produces a unified report at .turbo/audit.md. Use when the user asks to \"audit the project\", \"run a full audit\", \"project health check\", \"audit my code\", \"codebase audit\", or \"comprehensive review\".
Shared changelog conventions and formatting rules referenced by $create-changelog and $update-changelog. Not typically invoked directly.
Enforce existence, reuse, mirror, and symmetry principles to keep new code minimal and consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.
Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".
Run AI-powered code review using the codex CLI. Use when the user asks to \"codex review\", \"run codex review\", or \"review a commit with codex\".
Shared commit message rules and technical constraints referenced by /stage-commit and /commit-staged. Not typically invoked directly.