font-size

Use when applies to all CSS `font-size` declarations, particularly those using `px` units for body text, UI labels, and navigation. Use when auditing mobile responsiveness and accessibility compliance. Check for `font-size` in media queries targeting small screens.

Quality

66%

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

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.

The body is a well-structured, actionable audit skill: concrete thresholds and fix recipes in Check/Fix, a clear check→fix sequence with a 200%-zoom verification, and exemplary progressive disclosure pointing to a real, one-level-deep reference file. Its main weakness is redundancy — the Quick Reference, Check/Fix, and Explain sections restate the same 4-5 facts, and Explain spends tokens on WCAG/px-vs-rem background Claude already knows.

Suggestions

Merge the repeated facts: state the 16px minimum, 12px iOS limit, and rem-vs-px guidance once (in Quick Reference or Fix) and cut their restatement in Explain and Check.

Trim the Explain section's background on WCAG SC 1.4.4 and px-vs-rem semantics that Claude already knows, keeping only the iOS Safari heuristic and the 1-in-3-adults motivation if needed.

Promote the 200%-zoom readability check to an explicit final validation step at the end of the Fix section rather than leaving it inside a parenthetical in Check.

Dimension	Reasoning	Score
Conciseness	The body repeats the same facts across sections — the 16px minimum, the 12px iOS Safari auto-inflation, px-ignores-browser-settings, and the 200% zoom test each appear in "Quick Reference", "Check"/"Fix", and again in "Explain" (e.g., "iOS Safari ignores values below 12px and auto-inflates them" in Quick Reference vs. the same claim restated in Explain). The Explain section also covers concepts Claude already knows (WCAG SC 1.4.4, px vs rem semantics), fitting 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than the lean level-4/5 anchors.	3 / 5
Actionability	The Fix section gives concrete, executable guidance: "divide the pixel value by 16 (the browser default) — e.g., `14px` becomes `0.875rem`", "Set body text to at least `1rem`", "Replace `html { font-size: 10px }` ... with `html { font-size: 62.5% }`", and specific thresholds (16px, 12px, 0.75rem). It stops short of fully copy-paste-ready code (the CSS examples live in references/rule.md, and "test in Chrome DevTools by setting font-size in browser settings or using zoom" is loosely specified), matching 'mostly executable guidance; concrete code or commands with minor gaps'.	4 / 5
Workflow Clarity	The Check → Fix → Explain sequence is clear, with numbered flag conditions (1)-(4) in Check and corresponding numbered remediations in Fix, plus a verification step ("Check that text remains readable and layout does not break at 200% zoom"). It fits 'clear sequence with most checkpoints present; minor validation gaps' — the fixes are not explicitly mapped back to the flag conditions and the 200%-zoom verification is mentioned only once, inside a parenthetical, rather than as an explicit final validation step.	4 / 5
Progressive Disclosure	The body is a ~35-line overview with clear section headers (Quick Reference, Check, Fix, Explain, Code Review) and a single, well-signaled, one-level-deep reference — "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and that file exists with matching content. This matches the level-5 anchor: clear overview with well-signaled one-level-deep references and easy navigation.	5 / 5
	Total	16 / 20 Passed

Description

61%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 conditions and a clear niche, but it opens with a grammatically broken clause ("Use when applies to all CSS font-size declarations") and never clearly states what the skill does — only when and where it applies. Tightening the what (e.g., "Flags and fixes sub-16px / px-based font sizes") and fixing the grammar would lift it substantially.

Suggestions

Fix the broken opening clause: replace "Use when applies to all CSS `font-size` declarations" with a third-person statement of what the skill does, e.g., "Flags and remediates CSS `font-size` declarations that use `px` units or fall below 16px on mobile."

State the concrete actions (audit, flag, convert px to rem) explicitly rather than only listing the contexts where the rule applies ("Use when", "Check for").

Add natural trigger synonyms such as "rem", "em", "text too small", or "WCAG resize text" to broaden keyword coverage.

Dimension	Reasoning	Score
Specificity	Phrases like "Use when applies to all CSS `font-size` declarations, particularly those using `px` units for body text, UI labels, and navigation" and "Check for `font-size` in media queries targeting small screens" name the domain and 1-2 concrete actions (auditing, checking media queries), but the opening clause is grammatically broken ("Use when applies") and the skill's actual actions (flag, fix, convert) are never stated — matching the 'names domain and 1-2 concrete actions, but not comprehensive' anchor rather than the level-4 'several specific actions' anchor.	3 / 5
Completeness	The "when" is explicit ("Use when auditing mobile responsiveness and accessibility compliance. Check for `font-size` in media queries targeting small screens") but the "what" is only weakly implied — the description says where the rule "applies" and what to "check", never what the skill actually does (identify violations, remediate to rem). This sits between the level-2 'when present without what' and level-4 'both present' anchors; the what is too vague for 4 and too implied for 2.	3 / 5
Trigger Term Quality	Natural trigger terms are well covered: "font-size", "px units", "body text", "UI labels", "navigation", "mobile responsiveness", "accessibility compliance", "media queries", "small screens" — phrases a user would plausibly say. A few natural variations are missing (e.g., "rem/em", "text too small", "WCAG"), so it fits the 'good keyword coverage; a few natural terms missing' anchor rather than the comprehensive level-5 anchor.	4 / 5
Distinctiveness Conflict Risk	The niche is clear (CSS `font-size` declarations, px-to-rem units, small-screen media queries) with distinct triggers, matching 'mostly distinct; minor overlap risk'. Broad phrases like "auditing mobile responsiveness and accessibility compliance" could overlap with general accessibility-audit or responsive-design skills, keeping it below the minimal-conflict level-5 anchor.	4 / 5
	Total	14 / 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/font-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.