assess-technical-debt
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 t
Install
npx skills add https://github.com/tobihagemann/turbo/tree/main/codex/skills/assess-technical-debt
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install tobihagemann-turbo@llmmart
git clone https://github.com/tobihagemann/turbo.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole tobihagemann/turbo collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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:
- Scope and partition
- Run debt analysis agents
- Run
$evaluate-findingsskill - Rank and write markdown report
- 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:
- 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). - 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 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. 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 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). 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, 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. 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
# 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`.
Step 5: Generate HTML Report
Convert the markdown report into a styled, interactive HTML page.
- Run the
$frontend-designskill to load design principles. - Read
.turbo/technical-debt.mdfor the full report content. - 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 adisplayvalue still hides- Finding cards with location, impact, effort, and recommended refactor
- 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.
Files (turbo)
-
references
-
debt-reviewer.md 6.1 KB
# Debt Reviewer Guidelines Scan the assigned scope for structural technical debt and return structured findings. Cover the dimensions named in your prompt: partition agents cover complexity hotspots, deprecated API usage, and duplication; the architecture agent covers architecture rot project-wide. Do not modify code, propose a full implementation, or write files. ## Contents - Scope and Mindset - Optional CLI Tools - Dimension 1: Complexity Hotspots - Dimension 2: Deprecated API Usage - Dimension 3: Duplication Clusters - Dimension 4: Architecture Rot - Impact and Effort Rubric - Output Format ## Scope and Mindset This assessment deliberately surfaces large refactors. Flag the underlying structural problem even when fixing it requires a multi-file refactor. Report accumulated debt, not stylistic nits. Anchor every finding to a concrete location (`path:line` or a line range) and read enough surrounding code to be confident the problem is real. Speculative findings waste the downstream evaluation pass. ## Optional CLI Tools If a relevant analyzer is already installed, run it as a fast first pass, then confirm and enrich its hits by reading the code. Do not ask to install anything; if none is present, rely on direct reading and `rg`. | Concern | Tools (any one) | |---|---| | Cyclomatic / cognitive complexity | `lizard` (multi-language), `radon cc` (Python), `gocyclo` (Go), ESLint `complexity` rule (JS/TS) | | Duplication | `jscpd` (multi-language), `pmd cpd` | | Deprecated symbols | compiler/linter deprecation warnings (`tsc`, `cargo build`, `go vet`, `-Xlint:deprecation`) | ## Dimension 1: Complexity Hotspots Functions, methods, or types that are hard to hold in the head and risky to change. Look for: - High cyclomatic complexity: many branches, deeply nested conditionals and loops, long `switch`/`if-else` chains. - High cognitive load: deep nesting, flag arguments that fork behavior, long parameter lists, mixed levels of abstraction in one body. - Long functions and God classes/modules: a single unit owning many unrelated responsibilities or mutating wide shared state. - Boolean-blind and primitive-obsessed signatures where a small type would collapse the branching. For each hotspot, name the smallest refactor that would meaningfully reduce the complexity (extract function, replace conditional with polymorphism/table, introduce a type, split the unit). ## Dimension 2: Deprecated API Usage Production code calling APIs marked for removal or already discouraged. Look for: - Project-internal symbols annotated deprecated (`@deprecated`, `@Deprecated`, `#[deprecated]`, `@available(*, deprecated)`, `obsolete`) that still have call sites. - Standard-library or framework APIs the toolchain warns are deprecated. - Third-party library calls superseded by a newer API in the installed version. Use documentation tools or web search to confirm the replacement when unsure. - Patterns the ecosystem has moved past where the codebase still uses the old form throughout. Report the deprecated symbol, where its replacement lives, and how widespread the usage is (one call site vs. pervasive). ## Dimension 3: Duplication Clusters Repeated logic that should be consolidated, beyond incidental similarity. Look for: - Copy-pasted blocks with small variations, especially logic duplicated across modules. - Parallel implementations of the same concept that drift independently (validation, formatting, mapping, error handling repeated per call site). - Repeated literal sets or magic constants that belong in one shared definition. - Custom infrastructure that re-implements what an established, maintained dependency already provides. Distinguish genuine duplication worth unifying from coincidental resemblance. Report the cluster (all locations), what they share, and the consolidation target (shared helper, base type, table, generic, established dependency). When the target is an established dependency, name the candidate and mark its coverage of the needed behavior, compatibility, license, and migration cost as unverified. ## Dimension 4: Architecture Rot Structural decay visible only across modules. This is the architecture agent's focus. Look for: - Tangled module boundaries: modules that import each other widely with no clear ownership. - Circular dependencies between modules or packages. - Layering violations: lower layers reaching into higher ones, UI touching persistence directly, business logic in controllers/views. - Bottleneck modules everything depends on, and "shotgun surgery" where one conceptual change forces edits across many files. - Inconsistent architecture: several competing ways to do the same cross-cutting thing (data access, config, eventing). Report the modules involved, the dependency or boundary problem, and the refactor direction (introduce a boundary/interface, invert a dependency, extract a shared layer, merge or split modules). ## Impact and Effort Rubric Tag every finding with both axes so the report can rank them. **Impact** — how much the debt hurts: - **High** — frequently changed or central code; high change risk, wide blast radius, or a recurring source of bugs. - **Medium** — noticeable maintenance drag on a moderately active area. - **Low** — real but isolated, rarely touched, or low-risk. **Effort** — rough size of the refactor: - **Low** — localized, mechanical, low regression risk (single function/file). - **Medium** — spans a few files or needs modest restructuring and test updates. - **High** — cross-module restructuring, broad ripple, or significant test/behavior risk. ## Output Format Return findings as a single structured markdown block. Group by dimension; state an explicit outcome for every dimension, including one with no findings. ```markdown ## Debt Findings — <partition or "Architecture"> ### <Dimension> **Finding:** <one-line summary> **Location:** <path:line or path (lines start-end); list all sites for duplication> **Impact:** <High|Medium|Low> — <why> **Effort:** <High|Medium|Low> — <why> **Recommended refactor:** <the concrete change> (repeat per finding) ``` If the scope holds no significant debt, say so explicitly and note any caveats.
-
-
SKILL.md 8.8 KB
--- name: assess-technical-debt description: "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." --- # 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`. 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` 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). 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, 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, 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`. ``` ## Step 5: 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, and recommended refactor - 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.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.