CtrlK
BlogDocsLog inGet started
Tessl Logo

team-tech-debt

Unified team skill for tech debt identification and remediation. Scans codebase for tech debt, assesses severity, plans and executes fixes with validation. Uses team-worker agent architecture with roles/ for domain logic. Coordinator orchestrates pipeline, workers are team-worker agents. Triggers on "team tech debt".

49

Quality

53%

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 ./.claude/skills/team-tech-debt/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%Scale 1-3

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

This is a well-organized orchestration skill that effectively serves as a routing document for a team-worker architecture. Its strengths are in progressive disclosure and clear role delegation. Its weaknesses are the lack of explicit validation checkpoints integrated into the workflow, some verbosity in the architecture description, and limited concrete executable examples for the CLI tools and pipeline execution.

Suggestions

Add explicit validation/checkpoint steps between pipeline stages (e.g., 'After scan completes, verify scan/ output exists before spawning assessor') to improve workflow clarity for this multi-step destructive process.

Include a concrete end-to-end example showing a minimal invocation and expected output (e.g., what happens when a user says 'team tech debt --mode=scan') to improve actionability.

Trim the ASCII architecture diagram or replace with a more compact representation — the role registry table already conveys the hierarchy effectively.

DimensionReasoningScore

Conciseness

The content is reasonably efficient and avoids explaining basic concepts, but includes some structural detail (like the full ASCII architecture diagram and verbose spawn template) that could be tightened. The role registry table and session directory tree are useful but borderline verbose for a routing document.

2 / 3

Actionability

The worker spawn template is concrete and near-executable, and the role router logic is clear. However, much of the content describes architecture rather than giving step-by-step executable instructions — the actual domain logic is deferred to role files. The CLI tool references (ccw cli) lack concrete usage examples with expected outputs.

2 / 3

Workflow Clarity

The pipeline stages (scan → assess → plan → fix → validate) are clearly sequenced, and the architecture diagram shows the flow. However, there are no explicit validation checkpoints or feedback loops between stages — error handling is listed as a table of scenarios but not integrated into the workflow steps. For a system involving destructive operations (executor modifying code), this gaps caps the score.

2 / 3

Progressive Disclosure

The skill is well-structured as a router/overview document with clear one-level-deep references to role files (roles/<name>/role.md) and specs (specs/pipelines.md). The role registry table provides a clean navigation index, and content is appropriately split between this overview and the referenced role files.

3 / 3

Total

9

/

12

Passed

Description

50%Scale 1-3

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 provides a reasonable overview of what the skill does (tech debt identification and remediation) but is cluttered with implementation architecture details (team-worker agents, coordinator, pipeline, roles/) that don't help Claude decide when to use it. The trigger phrase is too narrow ('team tech debt') and misses many natural user expressions. It would benefit from removing internal architecture details and adding broader trigger guidance.

Suggestions

Replace architecture details ('team-worker agent architecture', 'coordinator orchestrates pipeline', 'roles/ for domain logic') with more user-facing capability descriptions like 'identifies code smells, outdated dependencies, duplicated code, and missing tests'.

Expand trigger guidance with a proper 'Use when...' clause covering natural variations: 'Use when the user mentions technical debt, tech debt, code quality issues, refactoring needs, legacy code cleanup, or code smells'.

Add common file type or language context if applicable (e.g., 'across Python, JavaScript, or TypeScript codebases') to improve distinctiveness and trigger matching.

DimensionReasoningScore

Specificity

Names the domain (tech debt) and some actions (scans codebase, assesses severity, plans and executes fixes with validation), but also includes implementation details about architecture (team-worker agents, coordinator, pipeline) that don't describe user-facing capabilities. The actual concrete actions are somewhat listed but mixed with internal architecture jargon.

2 / 3

Completeness

The 'what' is partially covered (scans, assesses, plans, fixes tech debt). There is a trigger phrase ('Triggers on "team tech debt"'), but it's very narrow and not framed as a proper 'Use when...' clause with broader guidance on when Claude should select this skill. The trigger is too specific and doesn't cover natural user language variations.

2 / 3

Trigger Term Quality

Includes 'tech debt' as a key term users might say, and mentions 'team tech debt' as a trigger phrase. However, it misses common variations like 'technical debt', 'code quality', 'refactor', 'legacy code', 'code smell', or 'cleanup' that users would naturally use.

2 / 3

Distinctiveness Conflict Risk

The 'team tech debt' trigger is distinctive but overly narrow. The broader description of scanning codebases and fixing issues could overlap with general code review or refactoring skills. The team-worker architecture detail adds some distinctiveness but is an implementation detail rather than a functional differentiator.

2 / 3

Total

8

/

12

Passed

Validation

90%

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

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

Total

10

/

11

Passed

Repository
catlog22/Claude-Code-Workflow
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.