CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

dependency-update

Read release notes/changelogs, update a defined dependency scope, handle breaking changes, and verify. Explicit-only; no broad update-everything by inference.

Quality

71%

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 ./crates/tui/assets/skills/dependency-update/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

65%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 exceptionally lean and well-organized with a sensible non-goals section, but the workflow relies on high-level direction rather than concrete, executable guidance, and lacks failure-handling checkpoints for a batch operation. Adding specific commands and an explicit verify-fix-retry loop would substantially improve it.

Suggestions

Add concrete commands for identifying outdated dependencies (e.g., 'npm outdated', 'pip list --outdated', or equivalents per ecosystem) so step 1 is executable rather than a hint.

Add a feedback loop after verification: 'If tests/build fail: review breakages, fix, and re-run gates before proceeding' to satisfy the batch-operation validation checkpoint.

Give a concrete example of the defined dependency scope (e.g., 'scope = the packages the user names plus their direct transitive breakages') to make the explicit-only contract actionable.

DimensionReasoningScore

Conciseness

The body is 13 lean lines across three well-scoped sections with zero padding; every token earns its place and it fully assumes Claude's competence. This matches anchor 5 exactly.

5 / 5

Actionability

The workflow steps are high-level hints ('Identify the dependency set and current versions', 'Apply updates and fix breakages') with no concrete commands, examples, or specific steps to execute. This matches anchor 2 rather than anchor 3, which requires at least some concrete executable guidance.

2 / 5

Workflow Clarity

Four steps are clearly sequenced and a verification step exists ('Verify with the project's test/build gates'), but there is no feedback loop or checkpoint for what to do when verification fails. This is a batch operation with implicit checkpoints, matching anchor 3 ('sequence present but checkpoints missing or implicit') rather than anchor 4.

3 / 5

Progressive Disclosure

The skill is under 50 lines, needs no external references (none exist in the bundle), and is organized into clear sections. Per the rubric's simple-skill guideline this matches anchor 5.

5 / 5

Total

15

/

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 states concrete capabilities in third person with a clear scope boundary ('Explicit-only; no broad update-everything by inference'), but it omits any 'Use when...' trigger clause, which limits completeness and trigger discoverability. Adding explicit invocation triggers and common synonyms (upgrade, bump, package manager) would raise it further.

Suggestions

Append an explicit trigger clause such as 'Use when the user asks to update, upgrade, or bump specific dependencies or fix breaking changes after an update.'

Include natural synonyms users would say (e.g., 'upgrade', 'bump versions', 'package manager', 'lock file') to improve trigger term coverage.

Mention the concrete artifacts involved (e.g., manifest/lock files, package manager commands) to sharpen specificity beyond 'a defined dependency scope'.

DimensionReasoningScore

Specificity

Lists several concrete actions ('Read release notes/changelogs, update a defined dependency scope, handle breaking changes, and verify') with minor gaps such as no package-manager or lock-file specifics. It is above anchor 3 (more than 1-2 actions) but below anchor 5 (coverage is not comprehensive).

4 / 5

Completeness

The 'what' is clear and concrete, but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the rubric guidelines. It matches anchor 3 ('clear what, when missing') and not anchor 4, since the 'when' is entirely absent rather than merely under-specified.

3 / 5

Trigger Term Quality

Natural keywords like 'release notes', 'changelogs', 'dependency', 'breaking changes', and 'update' are present, but common synonyms users would say ('upgrade', 'bump', 'package manager', 'lock file') are missing. This fits anchor 4's 'good keyword coverage; a few natural terms missing' rather than anchor 5's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

Dependency updating is a mostly distinct niche, though broad verbs like 'update' and 'verify' create minor overlap risk with general maintenance/build skills. It fits anchor 4 rather than anchor 5 because it lacks distinct explicit trigger phrases.

4 / 5

Total

15

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

Hmbown/Codewhale

Path

crates/tui/assets/skills/dependency-update/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.