CtrlK
BlogDocsLog inGet started
Tessl Logo

form-field-multiple-labels

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Use a single label for each form field. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

62

Quality

73%

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/form-field-multiple-labels/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%

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 lean, well-structured overview that correctly defers detail to a real one-level-deep reference, so workflow clarity and progressive disclosure are strong. Actionability and conciseness sit at 2 because inline examples are absent and the opening restates knowledge Claude already has.

Suggestions

Add one small inline good/bad <label> markup snippet in the Fix section so the core guidance is copy-paste ready without opening the reference.

Drop or tighten the opening 'why multiple labels are bad' sentence, which explains a concept Claude already knows.

Merge the duplicate aria-labelledby mention so it appears once, and convert the meta 'Explain' section into concrete user-facing phrasing guidance.

DimensionReasoningScore

Conciseness

Mostly efficient, but the opening sentence explains a concept Claude already knows ('Multiple labels... can cause screen readers to announce redundant information'), the aria-labelledby guidance is repeated across Quick Reference and Fix, and the meta 'Explain' section restates intent rather than adding guidance.

2 / 3

Actionability

Check/Fix guidance is concrete ('Search for form inputs associated with more than one <label>'; 'Consolidate... or use aria-labelledby') but no executable example markup is shown inline — the concrete examples are deferred to references/rule.md.

2 / 3

Workflow Clarity

This is a simple single-purpose skill under 50 lines with a clear Check → Fix → Explain → Code Review sequence and an explicit verification cue ('note how to verify the fix with browser accessibility tooling'), meeting the score-3 simple-skill bar.

3 / 3

Progressive Disclosure

SKILL.md is a concise overview that clearly signals a one-level-deep reference ('see references/rule.md') for full details and examples, and that file exists and is well-organized, matching the clear-overview anchor.

3 / 3

Total

10

/

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 states concrete capabilities and an explicit 'Use when' trigger, but awkwardly embeds the rule title and uses broad triggers that risk overlap with other accessibility skills. Tightening the trigger phrasing and adding the natural terms 'multiple labels' and 'accessibility' would lift the weaker dimensions.

Suggestions

Reword the embedded rule title into a natural trigger clause, e.g. 'Use when reviewing HTML forms where an input may be associated with multiple <label> elements.'

Add the natural user-facing terms 'multiple labels' and 'accessibility' so the trigger matches how users actually describe the problem.

Narrow the broad 'interactive components, or design-system patterns' scope to label/form-field semantics to reduce overlap with general accessibility skills.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — which matches the score-3 anchor for multiple specific concrete actions.

3 / 3

Completeness

Both 'what' ('Check native semantics... inspect... screen-reader output') and 'when' ('Use when reviewing rendered HTML...') are stated with an explicit 'Use when...' trigger, satisfying the score-3 anchor.

3 / 3

Trigger Term Quality

Relevant keywords exist (form field, label, HTML, screen reader), but the rule title is jammed in awkwardly ('related to Use a single label for each form field') and natural variations like 'multiple labels' or 'accessibility' are absent, so coverage is incomplete.

2 / 3

Distinctiveness Conflict Risk

Broad triggers like 'reviewing rendered HTML, interactive components, or design-system patterns' could overlap with sibling accessibility skills, keeping it at 'somewhat specific but could still overlap' rather than a clear distinct niche.

2 / 3

Total

10

/

12

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.