table-duplicate-name

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Ensure tables have unique accessible names. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

Quality

81%

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

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 compact, well-structured single-purpose skill that appropriately delegates implementation detail to references/rule.md. Main improvements are removing repetition of the rule title and tightening the overlap between Quick Reference and Check.

Suggestions

Merge the Quick Reference and Check sections into one — they both say every table needs a unique caption or aria-label — and drop one of the verbatim rule-title repetitions.

Add a brief verification checkpoint in the Fix section (e.g. 'after adding the caption/aria-label, confirm uniqueness by listing tables in the browser accessibility tree or with an axe scan') to strengthen the feedback loop.

Mention the checking tooling (axe, Lighthouse, browser accessibility pane) in the body in one line so the skill is actionable without opening the reference file.

Dimension	Reasoning	Score
Conciseness	The body is lean and well-sectioned, but the rule title is repeated verbatim three times and the Quick Reference and Check sections largely restate each other ('unique accessible name via caption or ARIA attributes'), leaving minor trim-able padding.	4 / 5
Actionability	Concrete, executable guidance is given ('Add a unique <caption> or aria-label to the table'), which is sufficient for an instruction-only skill. Minor gaps: no mention in the body of the tooling for checking (axe, browser accessibility tree) — those details live only in references/rule.md.	4 / 5
Workflow Clarity	The Check → Fix → Explain → Code Review sequence is clear and verification is addressed ('note how to verify the fix with browser accessibility tooling or assistive tech'). It falls short of 5 because explicit verification checkpoints (e.g. re-inspect the accessibility tree after fixing) are only implied.	4 / 5
Progressive Disclosure	The short overview body appropriately splits implementation detail into a clearly signaled one-level-deep pointer ('see references/rule.md'), which is a real file containing the code examples, exceptions, and verification steps. Navigation is easy and nothing is over-inlined.	5 / 5
	Total	17 / 20 Passed

Description

83%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 strong description with an explicit 'Use when' trigger and concrete inspection actions. Its weaknesses are the awkwardly inlined rule title in the trigger clause and missing natural synonyms (caption, aria-label) that would sharpen trigger matching.

Suggestions

Rewrite the trigger clause to name concrete artifacts a user would mention, e.g. 'Use when reviewing HTML tables that need unique captions or aria-labels, or when auditing pages with multiple data tables for screen-reader accessibility.'

Add natural synonyms such as 'caption', 'aria-label', and 'screen reader' as trigger terms to improve matching against how users actually phrase this request.

Tighten the what-portion into a clean action list (check captions/ARIA labels, verify uniqueness across tables, confirm screen-reader navigation) so the capabilities read as distinct actions rather than an embedded rule title.

Dimension	Reasoning	Score
Specificity	Lists several concrete actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), but the awkwardly embedded rule-title phrase ('related to Ensure tables have unique accessible names') blurs the action list, keeping it short of comprehensive coverage.	4 / 5
Completeness	Both parts are explicit: an 'Use when reviewing rendered HTML, interactive components, or design-system patterns...' trigger clause, and a concrete what (check native semantics, inspect keyboard behavior, focus flow, accessible names, screen-reader output). This matches the anchor for clear what and when with concrete trigger phrases.	5 / 5
Trigger Term Quality	Natural terms like 'rendered HTML', 'tables', 'accessible names', and 'screen-reader' are present, but common variations users would say — 'caption', 'aria-label', 'a11y', 'WCAG' — are missing, so coverage is good rather than comprehensive.	4 / 5
Distinctiveness Conflict Risk	The skill is scoped to a specific table-accessibility rule, but the opening 'reviewing rendered HTML, interactive components, or design-system patterns' is generic boilerplate shared by many sibling accessibility skills, creating minor overlap risk.	4 / 5
	Total	17 / 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/table-duplicate-name/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.