codex/skills/assess-technical-debt/SKILL.md
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. 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", or "what's our worst code". Analysis-only — does not modify code.
npx skillsauth add tobihagemann/turbo assess-technical-debtInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
At the start, use update_plan to track each phase, restating any remaining steps of a parent workflow alongside them:
$evaluate-findings skillIf $ARGUMENTS specifies paths, assess those directly (skip the question).
Otherwise, use request_user_input to confirm scope:
Once scope is determined:
node_modules/, dist/, build/, vendor/, __pycache__/, .build/, DerivedData/, target/, .tox/, and others appropriate to the project).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 in parallel with spawn_agent / wait_agent using inherited model defaults. 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. 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, 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.
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.
$evaluate-findings SkillAggregate 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.
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:
Output the summary and priority matrix as text. Then write .turbo/technical-debt.md using the template below.
# 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, recommended refactor>
### Deprecated API Usage
<findings>
### Duplication Clusters
<findings>
### Architecture Rot
<findings>
---
This assessment covers in-code structural debt. For dependency freshness, dead code, and diff-scoped bugs, run `$review-dependencies`, `$find-dead-code`, and `$review-code`.
Convert the markdown report into a styled, interactive HTML page.
$frontend-design skill to load design principles..turbo/technical-debt.md for the full report content..turbo/technical-debt.html (single file, no external dependencies beyond Google Fonts) that presents all findings from the markdown report with:
@media printThen call update_plan to mark this step completed and continue with the next step of the active workflow.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".
development
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".