th-has-data-cells

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Ensure table headers associate with data cells. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

Quality

68%

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/th-has-data-cells/SKILL.md

Quality

Content

61%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, concise overview that appropriately points one level deep to references/rule.md for details. Its weaknesses are actionability and workflow clarity: the standalone body lacks executable verification steps and an explicit validation checkpoint, relying on the reference for the concrete "how".

Suggestions

Add a brief inline verification snippet (e.g. an axe/Lighthouse check or an accessibility-tree inspection step) so the body is actionable without requiring the reference.

Replace the loose Check/Fix/Explain/Code Review sections with a numbered review workflow that includes an explicit validation checkpoint.

Move or merge the meta "Explain" section into the reference to keep the body purely task-oriented and trim tokens.

Dimension	Reasoning	Score
Conciseness	The body is lean and avoids over-explaining concepts Claude already knows, with tight Quick Reference bullets and one-line Check/Fix directives; the meta "Explain" section ("Explain why every header must have associated data...") is mild padding that could be trimmed.	4 / 5
Actionability	Gives directional guidance ("Verify that all <th> elements are correctly associated", "Remove empty headers or ensure they are correctly mapped to data cells") but defers the concrete "how" — actual code examples and verification tooling — to references/rule.md, leaving the body incomplete as standalone instruction.	3 / 5
Workflow Clarity	Sections (Check, Fix, Explain, Code Review) suggest a loose sequence but are not a clearly numbered workflow, and there is no explicit validation/verification checkpoint in the body — verification steps live only in the reference file.	3 / 5
Progressive Disclosure	The body acts as a clear overview with a well-signaled, one-level-deep pointer to references/rule.md (confirmed to exist) for full implementation details; organization is good, though some inline meta-content like the "Explain" section could itself sit in the reference.	4 / 5
	Total	14 / 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.

The description is solid: it has an explicit "Use when" trigger, concrete review actions, and a clear accessibility niche. Its main weakness is the awkward embedding of the rule title ("related to Ensure table headers associate with data cells") into the sentence, which muddies the otherwise clear capability statement.

Suggestions

Rewrite the "what" as a clean capability statement instead of embedding the rule title, e.g. "Verifies that every <th> is associated with one or more <td> data cells."

Add the most natural technical synonyms users say (e.g. "th elements", "scope attribute", "table accessibility") to strengthen trigger term coverage.

Tighten the broad framing ("rendered HTML, interactive components, or design-system patterns") to focus on tables specifically, reducing overlap with general accessibility skills.

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 embedded rule title makes the overall task framing slightly awkward, leaving minor gaps versus a fully comprehensive action list.	4 / 5
Completeness	Explicitly answers both what (review semantics/keyboard/focus/accessible names/screen-reader output for table header association) and when ("Use when reviewing rendered HTML, interactive components, or design-system patterns"), but the "what" is awkwardly phrased by embedding the rule title mid-sentence rather than stating it cleanly.	4 / 5
Trigger Term Quality	Includes natural terms a user would say ("rendered HTML", "interactive components", "design-system patterns", "table headers", "data cells", "screen-reader output"), with good coverage though a few synonyms (e.g. "th elements", "scope attribute") are missing.	4 / 5
Distinctiveness Conflict Risk	Targets a specific accessibility niche (table header/data-cell association) that is mostly distinct, though the broad framing around rendered HTML and interactive components creates minor overlap risk with other 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/th-has-data-cells/SKILL.md
Commit: 30756a7

Reviewed: 9 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.