form-validation

Use when reviewing templates, rendered HTML, or shared components related to Validate forms accessibly. Validate the final browser-facing markup, not just the source framework abstraction. Distinguish between browser-posted forms and client-handled React forms so you do not over-report missing `method` or `action` as accessibility defects.

Quality

73%

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-validation/SKILL.md

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.

A lean, well-structured review skill with specific attribute-level guidance and exemplary use of a single one-level-deep reference. Its main weaknesses are cross-section repetition of the same accessibility criteria and a filler 'Explain' section, plus slightly odd section ordering between Check and Code Review.

Suggestions

Merge or deduplicate the overlapping guidance: state the criteria (aria-describedby, aria-invalid, required/aria-required, fieldset/legend) once — e.g., in Quick Reference — and have Check/Fix/Code Review reference them rather than restate them.

Cut or conflate the 'Explain' section; telling Claude to 'explain how accessible form validation improves user experience' adds no information, so fold the one-line rationale into the intro if needed.

Reorder so the detection steps sit together — move the 'Code Review' section adjacent to 'Check' (before 'Fix') so the review-then-remediate sequence reads top to bottom.

Dimension	Reasoning	Score
Conciseness	The body is compact, but the one-sentence 'Explain' section ('Explain how accessible form validation improves user experience...') tells Claude nothing it doesn't already know, and the required/aria-required and aria-describedby guidance repeats across Quick Reference, Check, Fix, and Code Review — it could be tightened into one authoritative list.	3 / 5
Actionability	Concrete, checkable guidance with exact attributes (aria-describedby, aria-invalid, required/aria-required, fieldset/legend) and a precise exception ('Do not flag React forms just because they omit method or action when onSubmit clearly handles submission client-side'). No inline correct/incorrect markup example — that lives in references/rule.md — keeps it just short of fully copy-paste ready.	4 / 5
Workflow Clarity	The Check → Fix → Explain pattern gives a coherent review-then-remediate flow with unambiguous detection criteria, and this is a read-only review task so destructive-operation validation caps don't apply. The sequencing stumbles slightly: the 'Code Review' section (which is really the detection step) appears after 'Explain' rather than alongside 'Check'.	4 / 5
Progressive Disclosure	A concise overview body with one clearly signaled, one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md') that matches the actual bundle structure — the referenced file exists with the full rule details.	5 / 5
	Total	16 / 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, well-scoped description with an explicit trigger clause, concrete actions, and a distinctive React-form carve-out. It reads slightly awkwardly ('related to Validate forms accessibly') and could enumerate its capability a bit more directly, but it clearly answers both what and when.

Dimension	Reasoning	Score
Specificity	Names several concrete actions — 'Validate the final browser-facing markup, not just the source framework abstraction' and 'Distinguish between browser-posted forms and client-handled React forms so you do not over-report missing method or action' — with only minor gaps in coverage of the full validation checklist.	4 / 5
Completeness	Both parts are explicit: 'Use when reviewing templates, rendered HTML, or shared components' answers when, and validating rendered markup with the browser-posted vs. client-handled distinction answers what. It falls just short of the 5 anchor because the 'what' leans on scope caveats rather than a direct capability statement.	4 / 5
Trigger Term Quality	Good natural keywords users would say when reviewing ('templates', 'rendered HTML', 'shared components', 'React forms', 'accessibility defects'), but a few common synonyms like 'a11y', 'screen reader', or 'form markup' are missing.	4 / 5
Distinctiveness Conflict Risk	A clear niche (accessible form validation in rendered HTML/templates, including the React onSubmit nuance) with only minor overlap risk against generic HTML or accessibility review skills.	4 / 5
	Total	16 / 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-validation/SKILL.md
Commit: 7bfd868

Reviewed: 1 day 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.