js-file-size

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

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/js-file-size/SKILL.md

Quality

Content

45%

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

The skill is well-structured with a clean overview and a genuine one-level reference to rule.md, so progressive disclosure is strong. It is held back by abstract, non-executable Check/Fix guidance in the body (all real code lives in the reference) and by a measurement workflow that lacks explicit verify-after-fix checkpoints.

Suggestions

Add at least one concrete executable step to the body (e.g., a webpack-bundle-analyzer or Lighthouse CLI command, or a one-line code-splitting import example) so the Fix section instructs rather than describes.

Turn the Check/Fix flow into an explicit measure -> change -> re-measure loop with a validation checkpoint (e.g., 're-run Lighthouse and confirm TTI/JS transfer size dropped') so workflow clarity can score higher.

Trim the intro paragraph and 'Explain' section, which restate well-known main-thread/low-end-device concepts Claude already knows, to improve token efficiency.

Dimension	Reasoning	Score
Conciseness	The body is fairly short and avoids re-explaining JS basics, but lines like 'Excessive JavaScript increases parse and execution time, especially on low-end devices' and the 'Explain' section restate concepts Claude already knows, leaving some tighten-able padding.	2 / 3
Actionability	The Check/Fix/Explain sections give only abstract direction ('Implement code-splitting, tree-shaking, and dependency audits') with no executable commands or copy-paste code in the body, matching the 'vague/abstract; describes rather than instructs' anchor.	1 / 3
Workflow Clarity	There is a recognizable Check -> Fix -> Explain -> Code Review sequence, but it lacks explicit validation checkpoints or feedback loops for the measurement-dependent changes, and the 'Code Review' step does not describe verifying a fix actually improved the metric.	2 / 3
Progressive Disclosure	The body is a concise overview that clearly signals a single one-level-deep reference ('see references/rule.md'), and rule.md exists and holds the detailed examples, matching the clear-overview-with-well-signaled-one-level-deep-reference anchor.	3 / 3
	Total	8 / 12 Passed

Description

77%

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 well-formed with an explicit 'Use when...' trigger and natural user language, scoring high on trigger quality and completeness. It is slightly generic on conflict risk because 'slow page loads/heavy assets' overlaps with broader performance skills, and it lists only one main capability theme.

Suggestions

Tighten the 'what' to list the concrete audit actions (e.g., measure bundle sizes, flag files over 200KB compressed, recommend code-splitting/tree-shaking) rather than a single verify-the-bottleneck theme, to lift specificity.

Add a JS-bundle-specific discriminator (e.g., 'Use when users report large .js bundles or high Time to Interactive from JavaScript') to reduce overlap with general performance or image-optimization skills.

Dimension	Reasoning	Score
Specificity	It names concrete actions ('auditing slow page loads', 'Verify the actual bottleneck') but stays at a single audit/verify theme rather than listing multiple specific operations, matching the 'names domain and some actions, but not comprehensive' anchor.	2 / 3
Completeness	It explicitly answers both 'what' (audit page loads/assets/rendering delays, verify bottlenecks before recommending) and 'when' (leading 'Use when auditing slow page loads, heavy assets, or rendering delays'), satisfying the clear-what-and-when-with-explicit-triggers anchor.	3 / 3
Trigger Term Quality	It leads with the natural user phrasing 'Use when auditing slow page loads, heavy assets, or rendering delays' and names the concrete tools users say (DevTools, Lighthouse), giving good coverage of terms users would actually say.	3 / 3
Distinctiveness Conflict Risk	The triggers ('slow page loads', 'heavy assets', 'rendering delays') are shared with broader web-performance skills and could overlap with image-optimization or general perf-audit skills, so it is somewhat specific but not a clear conflict-free niche.	2 / 3
	Total	10 / 12 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
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/js-file-size/SKILL.md
Commit: 48405aa

Reviewed: about 11 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.