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.

64

Quality

76%

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

78%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.

A lean, well-structured single-purpose skill: unambiguous check/fix guidance, concrete ARIA and label techniques, and clean progressive disclosure to a verified references/rule.md containing executable HTML examples. Minor gaps are the lack of an inline detection method and verification being a note rather than an explicit checkpoint.

DimensionReasoningScore

Conciseness

Sections are tight (Quick Reference, Check, Fix, Explain, Code Review) with no padding or library tutorials, matching anchor 4. It misses anchor 5 because the opening sentence explaining why duplicate labels confuse screen readers and the "Explain" section restate knowledge Claude already has and could be trimmed.

4 / 5

Actionability

Guidance is concrete and specific — "Associate each form input with exactly one <label> element", "Consolidate multiple labels into a single <label> or use aria-labelledby" — with executable HTML examples deferred to the real references/rule.md, matching anchor 4. It is not a 5 because the Check step gives no concrete detection method (e.g., axe rule id, DOM query, or grep pattern) inline.

4 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sections form a clear sequence, and the Code Review section includes verification direction ("note how to verify the fix with browser accessibility tooling or assistive tech"), matching anchor 4. Not a 5 because verification is mentioned as a note rather than an explicit checkpoint step, and the sequence is implied by section order rather than stated.

4 / 5

Progressive Disclosure

The body is a concise overview with a clearly signaled, one-level-deep reference — "For full implementation details, code examples, and framework-specific guidance, see references/rule.md" — and that file exists and itself contains no further reference nesting, exactly matching anchor 5.

5 / 5

Total

17

/

20

Passed

Description

75%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.

A solid description with an explicit 'Use when' clause and several concrete inspection actions. Its main weaknesses are the awkward mid-sentence embedding of the rule name, missing natural accessibility trigger synonyms, and no statement of the remediation actions the skill provides.

Suggestions

Rewrite the trigger clause with natural phrases instead of embedding the rule name, e.g., "Use when reviewing HTML forms, accessibility audits, or design-system patterns where a form field may have multiple labels."

Add missing natural trigger synonyms such as "accessibility", "a11y", and "screen reader output" so users searching those terms match this skill.

Briefly state the remediation capability (e.g., "consolidates duplicate labels or replaces them with aria-labelledby") so the 'what' covers both detection and fix.

DimensionReasoningScore

Specificity

Lists several specific concrete actions ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant"), matching anchor 4. It falls short of anchor 5 because it never states what the skill actually does about the label problem (e.g., consolidating labels or using aria-labelledby).

4 / 5

Completeness

Both what ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output") and when ("Use when reviewing rendered HTML...") are explicitly present. Not a 5 because the when-clause awkwardly embeds the rule name mid-sentence ("related to Use a single label for each form field") instead of crisp, concrete trigger phrases like "when a form field has multiple labels".

4 / 5

Trigger Term Quality

Includes good natural keywords users would say — "rendered HTML", "interactive components", "label", "form field", "screen-reader" — but misses common variations and synonyms like "accessibility", "a11y", or "forms" that anchor 5 expects.

4 / 5

Distinctiveness Conflict Risk

The rule-name anchor ("Use a single label for each form field") gives it a clear niche, but the generic review-conditions prefix ("reviewing rendered HTML, interactive components, or design-system patterns") would be shared verbatim by sibling accessibility rule skills, creating minor overlap with closely related skills per anchor 4.

4 / 5

Total

16

/

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.

Validation — 15 / 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.