CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

62

Quality

74%

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

Quality

Content

65%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-organized overview body with excellent progressive disclosure to a real, one-level-deep reference file. Its weaknesses are in-body actionability and workflow clarity: the Check/Fix guidance states what to verify but not how (no association mechanics, selectors, or examples in the body), and verification checkpoints are only implied rather than stated as explicit steps.

Suggestions

Add the concrete association mechanics to the Check section — e.g., verify `scope` attributes and `headers`/`id` pairs, or inline one compact GOOD/BAD `<th>` markup snippet — so the check is executable before opening the reference file.

Make verification an explicit workflow step (e.g., 'After fixing, re-run axe or inspect the accessibility tree to confirm no orphaned headers remain') instead of the implicit 'note how to verify the fix' aside.

Trim redundancy: merge the overlapping Quick Reference bullets and Check/Fix one-liners (e.g., 'Avoid empty headers' vs 'Remove unnecessary headers') and drop or shorten the Code Review section that repeats the description's generic review procedure.

DimensionReasoningScore

Conciseness

The body is short (~30 lines), assumes Claude's competence, and explains no background concepts. Minor trimming is possible: the Quick Reference bullets overlap Check/Fix ("Avoid empty headers that don't describe any data" vs "Remove unnecessary headers"), and the Code Review section largely restates the description's generic review procedure — efficient with minor instances that could be tightened, matching level 4 rather than the every-token-earns-its-place of level 5.

4 / 5

Actionability

The Quick Reference bullets state concrete criteria ("Every `<th>` must be associated with one or more `<td>` cells", "Avoid empty headers"), which lifts it above level 2's high-level-hints-only profile. But the body gives no how: "Verify that all `<th>` elements are correctly associated with data cells" and "ensure they are correctly mapped to data cells" never specify what correct association looks like (scope attributes, headers/id pairs) or how to detect it, and all executable examples are delegated to references/rule.md — some concrete guidance but incomplete, matching level 3.

3 / 5

Workflow Clarity

A rough sequence is present (Quick Reference → Check → Fix → Explain → Code Review), above level 2's poorly-defined steps. But validation checkpoints are only implicit: "note how to verify the fix with browser accessibility tooling or assistive tech" mentions verification without any in-body checkpoint, and the actual verification steps live in references/rule.md — steps listed with validation gaps, matching level 3. The destructive/batch cap does not apply (this is a review skill), but the simple-skill exception for 5 does not apply either since the correct-association method is left unspecified.

3 / 5

Progressive Disclosure

The body is a clear overview with the single bundle file well signaled and exactly one level deep: "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and that file exists and contains no further nested references. The split is appropriate (criteria in SKILL.md; examples, rationale, exceptions, and verification in rule.md), matching the level-5 anchor for clear overview with well-signaled one-level-deep references.

5 / 5

Total

15

/

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 explicit what (check native semantics, inspect keyboard/focus/accessible names/screen-reader output) and when (reviewing rendered HTML, interactive components, or design-system patterns) plus domain-distinct trigger terms. The main weaknesses are that the listed actions are a generic a11y-review procedure rather than rule-specific mechanics, and the most natural synonym for the domain ("accessibility") is absent from the trigger terms.

DimensionReasoningScore

Specificity

The description lists several concrete actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — which exceeds the 1-2 actions of the level-3 anchor. However, the actions are a generic accessibility-review procedure rather than rule-specific mechanics (no mention of `scope` attributes, `headers`/`id` association, or th/td mapping specifics), so it falls short of the comprehensive coverage of the level-5 anchor.

4 / 5

Completeness

Both parts are explicitly answered: "Use when reviewing rendered HTML, interactive components, or design-system patterns related to..." gives a concrete when, and "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" gives a concrete what. This matches the level-5 anchor (clear what AND when with concrete trigger phrases); the level-4 anchor's caveat ("'when' could be more explicit") does not apply since the when clause names three specific trigger contexts.

5 / 5

Trigger Term Quality

Strong natural keyword coverage: "rendered HTML", "interactive components", "design-system patterns", "table headers", "data cells", "keyboard behavior", "focus flow", "accessible names", "screen-reader output" — phrases a user would naturally say. It stops short of level 5 because common synonyms are missing, most notably "accessibility"/"a11y" itself and unhyphenated "screen reader".

4 / 5

Distinctiveness Conflict Risk

The rule-specific phrases "table headers" and "data cells" plus "Ensure table headers associate with data cells" give it a clear niche, and the review procedure ties it to a distinct scenario. It is not level 5 because the generic preamble "Use when reviewing rendered HTML, interactive components, or design-system patterns" would be shared by sibling accessibility checklist skills, creating minor overlap risk with closely related skills.

4 / 5

Total

17

/

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.