dom-size

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

Quality

67%

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

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 a well-structured, token-efficient overview that correctly pushes implementation detail into a real one-level reference file. Its weaknesses are thin in-body actionability — no executable measurement commands despite a Check section — and an only-implicit workflow with no post-fix verification step.

Suggestions

Add one executable measurement command to the 'Check' section, e.g. a DevTools console snippet like document.querySelectorAll('*').length or the Lighthouse 'DOM size' audit name, so the check can be run without opening the reference file.

Make the Check → Fix → Verify sequence explicit (e.g. numbered steps) and add a post-fix re-measurement step to confirm the node count and depth are back under thresholds.

Trim the duplicated performance-impact explanation: the intro sentence and the 'Explain' section restate the same memory/rendering rationale; keep one.

Dimension	Reasoning	Score
Conciseness	The body is lean with concrete thresholds ('Keep total DOM nodes below 1,500', 'maximum depth < 32'), but the intro sentence ('An excessive DOM size increases memory usage, slows down style calculations...') explains a concept Claude already knows and the 'Explain' section restates it ('Explain the performance impact of a large DOM tree on memory and rendering speed') — minor trimmable padding per anchor 4 rather than the fully lean anchor 5.	4 / 5
Actionability	Provides concrete thresholds, named tools ('Lighthouse or Chrome DevTools'), and specific fix directions ('Simplify the HTML structure, remove unnecessary wrapper elements, and implement virtualization'), but includes no executable commands in the body — no DevTools snippet or script for measuring node count/depth — and defers the actual how-to entirely to references/rule.md, matching anchor 3 (missing key details) rather than anchor 4 (concrete code or commands present).	3 / 5
Workflow Clarity	An implicit Check → Fix → Explain sequence exists with a pre-fix measurement checkpoint, but there is no post-fix re-measurement to confirm improvement and the sequence is conveyed by section order rather than explicit steps, fitting anchor 3 ('checkpoints missing or implicit').	3 / 5
Progressive Disclosure	The body is a concise overview that cleanly splits deep content (code examples, framework-specific guidance) into a single real, one-level-deep, clearly signaled reference ('see references/rule.md', verified to exist), matching anchor 5's clear overview with well-signaled references.	5 / 5
	Total	15 / 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 a clear 'Use when' trigger clause, concrete tooling terms, and third-person voice, making it functional and reasonably distinct. Its main weakness is that the 'what' side is thin — it describes auditing and verifying but not the skill's actual remediation capabilities, and it leans on the rule title rather than natural synonyms for the DOM-size problem.

Suggestions

State the concrete actions the skill performs, e.g. 'Audits DOM size and depth, flags oversized or deeply nested structures, and recommends simplification and list virtualization' instead of the generic 'before recommending changes'.

Add common trigger synonyms such as 'large DOM', 'too many DOM nodes', or 'slow rendering' alongside 'slow page loads' and 'rendering delays'.

Dimension	Reasoning	Score
Specificity	Names the domain ('slow page loads, heavy assets, or rendering delays related to Reduce DOM size and complexity') and one concrete action ('Verify the actual bottleneck in DevTools, Lighthouse, or field data'), but never states the skill's concrete outputs (measuring node count/depth, simplifying HTML, virtualizing lists), so coverage is not comprehensive as anchor 4 requires.	3 / 5
Completeness	Has an explicit 'when' ('Use when auditing slow page loads, heavy assets, or rendering delays...') and a 'what' ('Verify the actual bottleneck... before recommending changes'), but the 'what' is generic about what the skill actually does, fitting anchor 4 ('when' could be more specific) rather than the fully explicit anchor 5.	4 / 5
Trigger Term Quality	Includes natural phrases users would say ('slow page loads', 'heavy assets', 'rendering delays', 'DOM size', 'DevTools', 'Lighthouse'), but misses common variations like 'large DOM', 'too many DOM nodes', or 'laggy page', matching anchor 4 rather than the comprehensive synonym coverage of anchor 5.	4 / 5
Distinctiveness Conflict Risk	Scoped to DOM size/complexity with distinct tooling triggers, but the opening phrases ('slow page loads', 'heavy assets') overlap with sibling performance-rule skills (asset optimization, lazy loading), matching anchor 4 (minor overlap risk with closely related skills) rather than anchor 5's minimal conflict risk.	4 / 5
	Total	15 / 20 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/dom-size/SKILL.md
Commit: 7bfd868

Reviewed: 1 day 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.