CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

code-refactoring-tech-debt

Identify and prioritize technical debt by maintenance cost, delivery impact, and risk. Use when assessing code health or planning a measurable remediation roadmap.

Quality

60%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/code-refactoring-tech-debt/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

38%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a well-sequenced but heavily padded monolith: it teaches Claude concepts it already knows, substitutes illustrative fake data for executable tooling guidance, and keeps all detail inline with zero bundle files. The core structure (inventory → assessment → prioritized plan) is sound, but the skill needs to be split into reference files and stripped of tutorial-style explanation.

Suggestions

Move the debt-type catalog (sections 1), metrics templates, and report formats into references/ files (e.g., references/debt-types.md, references/report-templates.md) and keep SKILL.md as a lean overview with one-level-deep links.

Replace conceptual explanations of code smells (god classes, feature envy, shotgun surgery) with concrete tool commands for detecting them (e.g., jscpd, radon, sonar CLI, dependency audit commands), since Claude already knows these concepts.

Add validation checkpoints to the workflow — e.g., confirm measured metrics against tool output and re-verify the debt inventory before producing the prioritized roadmap — so the analysis sequence has explicit feedback loops.

DimensionReasoningScore

Conciseness

The ~380-line body extensively catalogs concepts Claude already knows — definitions of duplicated code, god classes, feature envy, shotgun surgery, cyclomatic complexity — and pads sections with fabricated illustrative data ($150/hour rates, 'ROI: 250% in first month', invented trend scores). This matches 'noticeably verbose; several unnecessary explanations or padded sections' rather than 3, where padding would be incidental rather than spanning multiple sections.

2 / 5

Actionability

Guidance includes concrete output templates (metrics YAML, stakeholder report format) but no executable commands for actually performing the analysis (e.g., how to run a duplication or complexity scan), and the Python snippets are skeletons with 'pass' bodies rather than executable code. This fits 'some concrete guidance but incomplete; pseudocode instead of executable code; missing key details' rather than 4, which requires mostly executable guidance.

3 / 5

Workflow Clarity

The eight numbered sections give a clear sequence (inventory → impact → metrics → plan → implementation → prevention → communication → metrics), but there are no validation checkpoints (e.g., verifying findings against tool output or confirming metrics before prioritizing). This matches 'steps listed but validation gaps; sequence present but checkpoints missing or implicit' rather than 4, which requires most checkpoints present.

3 / 5

Progressive Disclosure

There are no references/, scripts/, or assets/ files at all; the entire skill is one monolithic file with the debt-type catalog, KPI templates, and report formats all inlined — content that clearly belongs in separate files. This matches anchor 2 ('content that clearly belongs in separate files is inlined'); it does not reach 3 because there are no reference files or split structure at all, only in-file headings.

2 / 5

Total

10

/

20

Passed

Description

62%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is well-constructed: third-person voice, a clear what-and-when structure, and a distinct technical-debt niche. Its main weaknesses are limited action coverage (only identify and prioritize) and a thin trigger vocabulary that omits natural synonyms like refactoring, legacy code, and code cleanup.

Suggestions

Broaden the action list beyond 'identify and prioritize' to cover the full capability (e.g., 'quantify debt impact, build a metrics dashboard, and produce a prioritized remediation roadmap').

Add natural trigger phrases users would actually say — 'refactoring priorities', 'legacy code', 'code cleanup', 'maintenance backlog' — to the 'Use when' clause.

DimensionReasoningScore

Specificity

The description names the domain and two concrete actions — "Identify and prioritize technical debt by maintenance cost, delivery impact, and risk" — with clear prioritization criteria, but coverage is not comprehensive (no mention of quantifying, reporting, or remediation planning as actions). It matches the anchor 'names domain and 1-2 concrete actions, but not comprehensive' rather than 4, which expects several listed actions.

3 / 5

Completeness

It explicitly answers both what ("Identify and prioritize technical debt by maintenance cost, delivery impact, and risk") and when ("Use when assessing code health or planning a measurable remediation roadmap"). The 'when' clause is present but could be more specific with concrete trigger phrases, matching anchor 4 rather than 5; it is clearly above anchor 3, where 'when' is missing or only weakly implied.

4 / 5

Trigger Term Quality

It includes relevant natural terms like "technical debt", "code health", and "remediation roadmap", but misses common variations users would say such as "refactoring", "legacy code", "code cleanup", or "maintenance backlog". This fits 'some relevant keywords but missing common variations or synonyms' rather than 4's 'good keyword coverage'.

3 / 5

Distinctiveness Conflict Risk

"Technical debt" is a clear niche with distinct triggers, giving minimal conflict risk with unrelated skills; only minor overlap risk exists with closely related refactoring or code-review skills. It fits 'mostly distinct; minor overlap risk with closely related skills' better than 3, since the domain is well-scoped rather than merely 'somewhat specific'.

4 / 5

Total

14

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

rmyndharis/antigravity-skills

Path

skills/code-refactoring-tech-debt/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.