CtrlK
BlogDocsLog inGet started
Tessl Logo

text-resizing

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Support text resizing to 200%. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

54

Quality

61%

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/text-resizing/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.

The body is a well-structured overview that defers detail to a single one-level-deep reference, with concrete check and fix guidance; its main weaknesses are redundancy between the Quick Reference and Fix sections and the lack of an explicit post-fix verification loop.

Suggestions

De-duplicate the Quick Reference and Fix sections so the remediation guidance appears once, or have Quick Reference link to Fix to avoid restating the same four points.

Add an explicit post-fix verification step (re-test at 200% text-only zoom and confirm no clipping) to close the Check → Fix loop.

Trim the opening sentence's explanation of low-vision basics, which Claude already knows, to improve token efficiency.

DimensionReasoningScore

Conciseness

The body is mostly efficient and well-sectioned, but the Quick Reference bullets and the Fix section restate the same four points (rem/em units, avoid fixed-height containers, containers grow, test at 200%), and the opening sentence explains a basic low-vision concept Claude already knows, so it could be tightened.

3 / 5

Actionability

The Check section gives a concrete verification procedure ('Resize text to 200% using browser text-only zoom settings and verify no content is clipped, truncated, or overlaps') and the Fix section names specific remediation strategies (rem/em units, min-height, avoid fixed-height containers); minor gap is that in-body code examples are deferred to the reference.

4 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sections form a logical sequence with an explicit initial validation checkpoint (Check), but there is no post-fix re-verification feedback loop and the sections are not framed as an explicit ordered workflow.

3 / 5

Progressive Disclosure

The body is a concise overview with clearly signaled one-level-deep navigation ('see references/rule.md') to the detailed implementation guide, which exists as a real bundle file, matching the well-organized overview-plus-single-reference pattern.

5 / 5

Total

15

/

20

Passed

Description

58%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 an explicit 'Use when' trigger and lists concrete actions, but the actions describe a generic accessibility review rather than the text-resizing specifics the skill name implies, weakening both specificity and distinctiveness.

Suggestions

Rewrite the 'what' clause to name text-resizing-specific actions (e.g., 'audit font-size units for rem/em, check fixed-height containers for clipping, verify content stays visible at 200% text-only zoom') instead of generic a11y-review actions.

Add common trigger synonyms users would say, such as 'font size', 'zoom', 'low vision', or 'WCAG 1.4.4 Resize Text'.

Narrow the 'when' scope so it triggers on text-sizing/zoom concerns rather than broad rendered-HTML or design-system reviews that overlap with general accessibility skills.

DimensionReasoningScore

Specificity

The description lists several concrete actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), but these are generic accessibility-review actions that do not comprehensively address the named domain of text resizing (no mention of relative units, container growth, or zoom testing), so coverage is not comprehensive.

3 / 5

Completeness

It explicitly answers both 'what' (check semantics, inspect keyboard/focus/accessible names/screen-reader output) and 'when' ('Use when reviewing rendered HTML, interactive components, or design-system patterns related to Support text resizing to 200%'), with the 'when' being explicit and specific; not a 5 because the 'what' is somewhat misaligned with the text-resizing purpose.

4 / 5

Trigger Term Quality

It includes some relevant natural terms ('text resizing to 200%', 'rendered HTML', 'design-system patterns') but misses common variations and synonyms a user might say such as 'font size', 'zoom', 'low vision', 'rem/em', or 'WCAG 1.4.4'.

3 / 5

Distinctiveness Conflict Risk

The text-resizing-to-200% niche is distinct, but the broad trigger scope ('rendered HTML, interactive components, or design-system patterns') and the generic accessibility-review actions create real overlap with general accessibility review skills.

3 / 5

Total

13

/

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.