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.

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/form-field-multiple-labels/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 lean, well-structured overview that appropriately defers detailed examples to a single one-level-deep reference, achieving strong progressive disclosure. Its weaknesses are in-body actionability and workflow clarity, since concrete markup examples and explicit verification checkpoints live in the reference rather than the skill body.

Suggestions

Inline one minimal before/after <label> snippet (or a one-line aria-labelledby example) in the Fix section so the body is actionable without opening the reference.

Add an explicit in-body verification checkpoint under Code Review (e.g., "Run axe/Lighthouse and confirm the input's accessible name in the browser accessibility tree before considering the fix done").

Remove the re-embedded rule title in the Code Review sentence and the intro/Quick Reference overlap to tighten conciseness.

Dimension	Reasoning	Score
Conciseness	The body is lean and well-sectioned (under 45 lines, one-sentence sections) with little padding, but the intro/Quick Reference overlap slightly and the Code Review sentence awkwardly re-embeds "Use a single label for each form field", which could be trimmed.	4 / 5
Actionability	Check and Fix give concrete directional guidance ("Consolidate multiple labels into a single <label> or use aria-labelledby"), but the executable HTML examples and specific verification tooling are deferred to references/rule.md, leaving in-body detail incomplete.	3 / 5
Workflow Clarity	A clear Check -> Fix -> Explain -> Code Review sequence is present, but validation/verification checkpoints are only implicit ("note how to verify the fix...") and the concrete verification steps live in the reference rather than in-body.	3 / 5
Progressive Disclosure	A concise, well-organized overview with a single clearly signaled one-level-deep reference ("see `references/rule.md`"), and the referenced file exists, giving clean navigation with no nested references.	5 / 5
	Total	15 / 20 Passed

Description

67%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 answers both what and when with concrete review actions and an explicit "Use when" trigger, but suffers from a templating artifact that embeds the rule title mid-sentence and some hedged/jargony phrasing. Keyword coverage is decent but naturalness is impaired.

Suggestions

Rewrite the "when" clause so the rule topic reads naturally instead of "related to Use a single label for each form field" (e.g., "Use when reviewing forms or interactive HTML for accessible labeling — specifically when an input may have more than one <label>.").

Add user-natural synonyms and file/extension cues (e.g., "form fields", "<label>", "aria-labelledby", "accessibility audit") alongside the jargon to broaden trigger coverage.

Drop the "where relevant" hedges and tighten the action list so each named check reads as a definitive capability.

Dimension	Reasoning	Score
Specificity	Lists several concrete review actions ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output"), but the "where relevant" hedges and the awkwardly embedded rule title leave minor gaps versus a fully comprehensive anchor 5.	4 / 5
Completeness	Both "what" (check semantics, inspect keyboard/focus/accessible-name/screen-reader output) and "when" (explicit "Use when reviewing rendered HTML, interactive components, or design-system patterns...") are present; the "when" is explicit but the embedded rule title makes it read awkwardly, short of a clean anchor 5.	4 / 5
Trigger Term Quality	Relevant domain keywords appear (rendered HTML, interactive components, form field, label, screen-reader), but the templated embedding of "Use a single label for each form field" mid-sentence and jargon-heavy phrasing ("accessible names", "focus flow") reduce naturalness and miss common user-said synonyms.	3 / 5
Distinctiveness Conflict Risk	Scoped to a specific accessibility rule (single label per form field) with distinct triggers, so it is mostly distinct with only minor overlap risk against sibling accessibility-review skills.	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/form-field-multiple-labels/SKILL.md
Commit: 30756a7

Reviewed: 15 days 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.