CtrlK
BlogDocsLog inGet started
Tessl Logo

legacy-js

Use when auditing slow page loads, heavy assets, or rendering delays related to Avoid serving legacy JavaScript to modern browsers. Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes.

60

Quality

70%

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/legacy-js/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.

A well-structured, token-efficient overview body with excellent progressive disclosure to a real, one-level-deep references/rule.md. Its weaknesses are in-body actionability — the Check and Fix sections tell Claude what to do but not how, deferring all executable detail to the reference — and missing validation checkpoints in the Check/Fix workflow (no measure-confirm-reverify loop).

Suggestions

Add one minimal executable anchor to the Fix section, e.g. the module/nomodule snippet (`<script type="module" src="modern.js"></script><script nomodule src="legacy.js"></script>`) or a one-line Vite `build.target`/browserslist example, so the body is actionable without opening the reference.

Make the Check section concrete: name the measurement (e.g. 'Compare modern vs legacy bundle sizes in the build output; check Lighthouse "Serve modern code" audit or bundle analysis for ES5/polyfill payload') and add a verify-after-fix step (re-run the same audit) to close the workflow loop.

Trim the opening explainer sentence and the generic Code Review template phrasing, since both restate knowledge Claude already has.

DimensionReasoningScore

Conciseness

The body is lean (~35 lines), well-sectioned (Quick Reference / Check / Fix / Explain / Code Review), and assumes Claude's competence with no library tutorials or padding. It is not a 5 because the opening sentence ("Modern browsers can execute ES6+ code faster and more efficiently; serving them transpiled ES5 with polyfills adds unnecessary weight") explains a concept Claude already knows, and the Code Review section's generic template text could be trimmed.

4 / 5

Actionability

Concrete technique names appear ("differential serving (module/nomodule)", "set a modern target"), but the body gives only high-level direction with no commands, config snippets, or measurement steps — e.g. "Analyze the project's JavaScript output" and "Update the build configuration" without saying how. The executable detail (Vite target, browserslist, module/nomodule HTML) lives one hop away in references/rule.md, so guidance is present but incomplete rather than minimally present (not 2) or mostly executable in-body (not 4).

3 / 5

Workflow Clarity

A coherent Check → Fix → Explain → Code Review sequence exists, but there are no validation checkpoints: no method for confirming the issue in the body, and no verify-after-fix step (e.g. re-run Lighthouse or compare bundle sizes). The sequence is clearly present and coherent (above the 2 anchor) but checkpoints are missing or deferred to the reference file, matching the 3 anchor.

3 / 5

Progressive Disclosure

The body is a concise overview with a clearly signaled, one-level-deep reference — "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and the referenced file exists with exactly that content (differential-serving HTML, Vite/browserslist configs, best practices) with no further nesting. Content is appropriately split and navigation is trivial, matching the 5 anchor; a 4 would require organization gaps, which are absent.

5 / 5

Total

15

/

20

Passed

Description

75%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.

A solid description with an explicit 'Use when' trigger clause, natural user phrasing, and concrete verification tooling. Its main weaknesses are the awkward embedded rule title ("related to Avoid serving legacy JavaScript to modern browsers") and a 'what' that describes auditing/verifying but never states the remediation the skill performs, plus mild overlap risk with other web-performance skills on generic slow-page triggers.

DimensionReasoningScore

Specificity

Names several concrete actions with specific tooling — "auditing slow page loads, heavy assets, or rendering delays", "Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes" — but stops short of naming the actual remediation (differential serving, build targets), so it is not comprehensive (not 5); it is clearly more than 1-2 generic actions (not 3).

4 / 5

Completeness

Both what and when are present: the explicit "Use when auditing slow page loads, heavy assets, or rendering delays related to Avoid serving legacy JavaScript to modern browsers" trigger plus the action sentence "Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes". The 'what' is somewhat muddled by the awkwardly embedded rule title and never states what the skill actually changes, so it falls short of the fully explicit 5 anchor.

4 / 5

Trigger Term Quality

Good natural-phrase coverage: "slow page loads", "heavy assets", "rendering delays", "legacy JavaScript", "modern browsers", "DevTools", "Lighthouse", "field data" — terms a user would plausibly say. A few common variations are missing ("bundle size", "polyfills", "transpiled"), keeping it below the comprehensive synonym coverage of a 5, but it is well above the sparse keyword sets of 2-3.

4 / 5

Distinctiveness Conflict Risk

The legacy-JS/modern-browsers niche with DevTools/Lighthouse/field-data triggers is mostly distinct, but "slow page loads", "heavy assets", and "rendering delays" could also fire for sibling performance skills (image optimization, lazy loading, bundling), giving minor overlap risk with closely related skills rather than the minimal-conflict clear niche of a 5.

4 / 5

Total

16

/

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.