CtrlK
BlogDocsLog inGet started
Tessl Logo

duplicate-js

Use when auditing slow page loads, heavy assets, or rendering delays related to Remove duplicate JavaScript libraries. Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes.

54

Quality

61%

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/duplicate-js/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%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-structured, appropriately delegated overview: it is lean and points cleanly to a real, substantive reference file. Its main weakness is actionability — the body itself contains only high-level direction with no executable commands, and the workflow lacks explicit validation checkpoints after fixes.

Suggestions

Inline one or two executable commands in the Check section (e.g. `npm ls <package>` or `pnpm why <package>`) so the core loop is executable without opening the reference file.

Add a post-fix verification step (re-run the bundle analysis or Lighthouse audit to confirm the duplicates are gone) to create a feedback loop.

Remove the generic "Explain" section or fold it into the intro, since explaining what duplicate libraries are adds tokens without actionable guidance.

DimensionReasoningScore

Conciseness

The body is short (~40 lines) and efficiently delegates detail to the reference file. Two minor over-explanations remain: the opening sentence about what duplicate libraries do (concepts Claude already knows) and the generic "Explain the risks..." section, which adds little actionable value. This matches anchor 4 (efficient with minor trims possible) rather than 5.

4 / 5

Actionability

The Check/Fix sections give only high-level hints ("using Lighthouse or bundle analysis tools", "Consolidate dependencies to use a single version") with no commands or code, while the concrete executable guidance (npm ls, package.json overrides) lives only in references/rule.md. This matches anchor 2 (high-level hints missing the specific steps) better than anchor 3, since no concrete command or example appears in the body itself.

2 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sections present a rough sequence, but there are no validation checkpoints (e.g. re-measure after consolidation to confirm the fix) — verification is only implied by "describe the measurement method used to confirm the issue". This fits anchor 3 (sequence present, checkpoints missing or implicit).

3 / 5

Progressive Disclosure

The body is a lean overview that delegates all implementation detail via a clearly signaled, one-level-deep pointer to references/rule.md, which exists and contains the concrete commands and examples. This matches anchor 5 (clear overview with well-signaled single-level references and appropriate content split).

5 / 5

Total

14

/

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 has a strong, explicit 'when' clause with natural trigger terms and tool names, but the 'what' is under-specified: the skill's actual capabilities (detecting and consolidating duplicate libraries) are only implied via the embedded title. Leading with broad performance symptoms also creates overlap risk with sibling performance skills.

Suggestions

State the core actions explicitly in the description, e.g. "Detects duplicate JavaScript libraries and consolidates them to a single version", so the 'what' does not rely on the embedded skill title.

Add synonyms users would actually say, such as "bundle size", "duplicate dependencies", or "multiple versions of the same library", to broaden trigger coverage.

Narrow the leading trigger symptoms (e.g. "auditing bundle size or duplicate dependencies") to reduce overlap with sibling performance-rule skills like render-blocking or image-optimization checks.

DimensionReasoningScore

Specificity

The description names the domain and 1-2 concrete actions ("Verify the actual bottleneck in DevTools, Lighthouse, or field data"), but it never states the skill's core capabilities (detect and remove duplicate libraries) — the skill's purpose appears only as the embedded title phrase "Remove duplicate JavaScript libraries". It sits between anchor 3 (clear actions but incomplete coverage) and anchor 4, closer to 3 because the primary action verbs are missing.

3 / 5

Completeness

An explicit "Use when..." trigger clause is present, and the verification instruction ("Verify the actual bottleneck... before recommending changes") partially answers the 'what'. However, the 'what' leans on the title phrase rather than stating actions like "detects and consolidates duplicate libraries", so it does not clearly match anchor 5's explicit what-and-when pairing.

4 / 5

Trigger Term Quality

Includes natural phrases users would say ("slow page loads", "heavy assets", "rendering delays") plus tool names ("DevTools", "Lighthouse", "field data"), giving good keyword coverage. It misses common variations like "bundle size", "duplicate dependencies", or package-manager terms ("npm ls", "dedupe"), keeping it below anchor 5.

4 / 5

Distinctiveness Conflict Risk

The narrow topic phrase is distinct, but the leading triggers ("slow page loads, heavy assets, or rendering delays") are generic performance complaints that would equally fire sibling performance-rule skills (image optimization, render-blocking resources, etc.). It overlaps with closely related skills without a discriminating trigger, matching anchor 3.

3 / 5

Total

14

/

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

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.