code-refactoring-tech-debt

Identify technical debt from actual code and change history, estimate its impact, and prioritize bounded improvements with explicit assumptions.

Quality

61%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

56%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 highly actionable with concrete code and config examples and a clear multi-step workflow, but it is markedly verbose and monolithic — large template and taxonomy sections should be moved into reference files. Tightening the inline material would materially improve token efficiency and progressive disclosure.

Suggestions

Move the stakeholder report, dashboard YAML, and debt-type taxonomies into reference files (e.g. references/templates.md, references/debt-types.md) and link to them one level deep.

Trim definitional bullets (e.g. explaining what duplicated code or god classes are) that restate knowledge Claude already has.

Add an explicit validation/checklist step after Impact Assessment and after the Remediation Plan so outputs are verified before reporting.

Dimension	Reasoning	Score
Conciseness	The ~400-line body inlines long taxonomies of debt types with 'Quantify:' bullets and full stakeholder-report/dashboard templates that largely restate concepts Claude already knows, matching 'noticeably verbose; several unnecessary explanations or padded sections'; not a 3 because the padding is substantial rather than incidental.	2 / 5
Actionability	Concrete executable Python (facade/service migration), YAML gates and dashboards, and ROI formulas cover the common cases with mostly copy-paste-ready material; not a 5 because several examples are illustrative templates rather than directly runnable in a real repo.	4 / 5
Workflow Clarity	Eight numbered sections (Inventory → Impact → Metrics → Plan → Implementation → Prevention → Communication → Success Metrics) form a clear sequence; being read-only analysis, the destructive/batch validation cap does not apply, but explicit validation checkpoints for the analysis outputs are missing.	4 / 5
Progressive Disclosure	Section headers give reasonable structure, but no bundle files exist and bulky template/report content that belongs in separate reference files is fully inlined; it sits above 'minimal structure' yet below well-signaled one-level-deep references.	3 / 5
	Total	13 / 20 Passed

Description

66%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 specific and well-targeted to a clear niche, but it lacks an explicit 'when to use' trigger clause, which caps completeness and limits distinctiveness slightly. Adding a natural 'Use when...' phrase would lift the two weaker dimensions.

Suggestions

Append an explicit trigger clause, e.g. 'Use when the user asks about technical debt, code-quality hotspots, or refactoring priorities.'

Add common synonyms users say ('refactoring', 'legacy code', 'code cleanup') to broaden trigger-term coverage.

Sharpen the actions toward measurable outputs ('quantify duplication', 'rank items by ROI') to push specificity toward comprehensive.

Dimension	Reasoning	Score
Specificity	Names three concrete actions — 'Identify technical debt from actual code and change history', 'estimate its impact', 'prioritize bounded improvements' — matching the 'several specific actions, minor gaps' anchor; not a 5 because the actions stay somewhat high-level rather than enumerating comprehensive concrete operations.	4 / 5
Completeness	It clearly states the 'what' but provides no 'Use when...' clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3.	3 / 5
Trigger Term Quality	'technical debt', 'code', 'change history', 'impact' are natural user phrases, but common synonyms like 'refactoring', 'legacy code', or 'code quality' are missing, so it stops short of comprehensive coverage.	4 / 5
Distinctiveness Conflict Risk	The technical-debt-analysis niche is mostly distinct with clear triggers; minor overlap risk with general code-review or refactoring skills keeps it just below a 5.	4 / 5
	Total	15 / 20 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: sickn33/agentic-awesome-skills
Path: skills/code-refactoring-tech-debt/SKILL.md
Commit: b1aebac

Reviewed: ~18 hours ago

Table of Contents

Discovery Implementation Validation

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.