CtrlK
BlogDocsLog inGet started
Tessl Logo

page-weight

Use when auditing slow page loads, heavy assets, or rendering delays related to Keep page weight under 1500KB. 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/page-weight/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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 lean, well-structured overview that uses progressive disclosure effectively to push code and detail into references/rule.md. The main weakness is actionability in the body itself, which stays at a high-level directive level rather than giving executable steps.

Suggestions

Add one or two concrete commands or a tiny code snippet in the Check or Fix sections (e.g. a Lighthouse CLI invocation or a DevTools Network-tab steps list) so the body is executable without requiring the reference.

Add an explicit verify-after-fix step to the workflow (e.g. 'Re-measure total page weight to confirm it is under 1500KB after changes').

Remove the duplicated 'affect Keep page weight under 1500KB' clause in the Code Review section so that sentence reads cleanly.

DimensionReasoningScore

Conciseness

The body is lean and well-sectioned (Quick Reference, Check, Fix, Explain, Code Review) with little padding; the only minor over-explanation is the opening 'page weight correlates with load time' sentence and a duplicated 'affect Keep page weight under 1500KB' clause in Code Review.

4 / 5

Actionability

The body gives concrete thresholds (1500KB/500KB) and action categories (image optimization, code minification, removing resources) but no executable commands or code — specifics are deferred to references/rule.md, leaving the body itself with high-level hints missing key execution details.

3 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sequence is clear and the Check step provides a measurement checkpoint against the threshold; the only gap is the absence of an explicit re-measure/verify step after the fix, which is minor for a simple single-purpose skill.

4 / 5

Progressive Disclosure

The body is a concise overview that cleanly offloads full implementation details, code examples, and framework-specific guidance to a single well-signaled one-level-deep reference (references/rule.md, which exists), making navigation easy.

5 / 5

Total

16

/

20

Passed

Description

70%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 strong, explicit trigger guidance and natural keywords, but a grammatical glitch embeds the rule title mid-sentence, slightly muddying the 'what' and the action list. It reads as a solid skill description with a formatting defect worth fixing.

Suggestions

Remove the inlined rule title from the description so the sentence parses cleanly, e.g. 'Use when auditing slow page loads, heavy assets, or rendering delays caused by excessive page weight. Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes.'

Lead with the 'what' (what the skill does) before the 'when' trigger clause for a clearer what-then-when structure.

Add a couple of common synonyms ('load time', 'web performance') to broaden natural trigger coverage.

DimensionReasoningScore

Specificity

Names the domain (page-weight performance) and 1-2 concrete actions ('auditing slow page loads...', 'Verify the actual bottleneck in DevTools, Lighthouse, or field data'), but the rule title 'Keep page weight under 1500KB' is jammed mid-sentence, muddying the action list rather than cleanly listing several.

3 / 5

Completeness

Both 'when' ('Use when auditing slow page loads, heavy assets, or rendering delays') and 'what' (verify the bottleneck before recommending changes, keep weight under 1500KB) are present with concrete triggers, but the embedded rule title makes the 'what' clause read awkwardly rather than crisply.

4 / 5

Trigger Term Quality

Natural terms a user would say are present ('slow page loads', 'heavy assets', 'rendering delays', 'page weight') alongside tool names (DevTools, Lighthouse), giving good coverage, though synonyms like 'performance', 'load time', or 'web vitals' are missing.

4 / 5

Distinctiveness Conflict Risk

The page-weight-under-1500KB framing carves a fairly distinct niche, though it could overlap with broader web-performance or Lighthouse-auditing skills.

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.

Validation15 / 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.