CtrlK
BlogDocsLog inGet started
Tessl Logo

form-labels

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Associate labels with form controls. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

60

Quality

71%

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

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 overview with actionable check/fix guidance and an exemplary one-level reference into references/rule.md. Its main weakness is redundancy between the Check, Code Review, and Quick Reference sections, plus a small amount of background explanation Claude does not need.

Suggestions

Merge the 'Check' and 'Code Review' sections into one — they overlap almost entirely on placeholder-only labels and fieldset/legend grouping — and drop the opening sentence explaining why labels matter.

Trim the Quick Reference bullets that duplicate Check/Fix content, keeping only the rules not stated elsewhere (e.g., 'Placeholder text is not a label').

Inline one short correct/incorrect HTML snippet (label for/id) in the Fix section so the most common case is executable without opening the reference.

DimensionReasoningScore

Conciseness

The body is short but the 'Code Review' section restates the 'Check' section ("Specifically check for placeholder-only labels and question groups that..."), and the opening sentence explains label purpose — a concept Claude already knows. Duplication across Check, Code Review, and Quick Reference goes beyond minor trimming.

3 / 5

Actionability

Concrete, specific instructions ("Add a <label> element with a 'for' attribute that matches the 'id' of the corresponding input field... wrap related checkboxes or radio buttons in a <fieldset> with a <legend>"), with full executable code examples delegated to the real references/rule.md. Not a 5 because no executable examples appear in the body itself.

4 / 5

Workflow Clarity

Clear Check → Fix → Explain sequence with a verification cue ("note how to verify the fix with browser accessibility tooling or assistive tech"). Not a 5 because the actual verification steps are deferred to the reference file rather than stated, leaving checkpoints implied rather than explicit.

4 / 5

Progressive Disclosure

Well-organized sections under 50 lines with a clearly signaled, one-level-deep reference ("For full implementation details, code examples, and framework-specific guidance, see references/rule.md") that exists and holds the promised details. Easy to navigate with no content that should have been split out.

5 / 5

Total

16

/

20

Passed

Description

71%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 several concrete inspection actions, but its 'what' is a generic review process rather than the labeling-specific work, and its broad rendered-HTML trigger creates overlap risk with sibling accessibility skills.

Suggestions

State the skill's actual labeling actions (e.g., 'verify label for/id association, flag placeholder-only labels, check fieldset/legend grouping') instead of only the generic inspection process.

Add natural trigger synonyms such as 'accessibility', 'a11y', 'form inputs', and 'placeholder-only labels' so users' phrasing matches without relying on the embedded rule title.

Narrow the 'when' clause to label/form semantics (e.g., 'Use when reviewing forms or rendered HTML for label association and accessible field names') to reduce conflict with sibling accessibility skills.

DimensionReasoningScore

Specificity

Lists several concrete inspection actions ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output") but never states the core labeling actions themselves (for/id association, fieldset/legend), leaving minor gaps in coverage.

4 / 5

Completeness

Explicitly answers both: "Use when reviewing rendered HTML, interactive components, or design-system patterns" (when) and the check/inspect actions (what). Not a 5 because the 'what' describes a generic inspection process rather than what the skill actually does for label association.

4 / 5

Trigger Term Quality

Includes natural trigger terms like "rendered HTML", "form controls", "labels", "keyboard", and "screen-reader", but misses common synonyms such as "accessibility", "a11y", "form inputs", and "placeholder"; the embedded phrase "Associate labels with form controls" reads as a rule title rather than a phrase a user would say.

4 / 5

Distinctiveness Conflict Risk

The trigger conditions "reviewing rendered HTML, interactive components, or design-system patterns" are broad enough to overlap with sibling accessibility-review skills; only the embedded rule title differentiates it. Somewhat specific, but conflict risk with similar skills remains.

3 / 5

Total

15

/

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.