landmark-regions

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

Quality

65%

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

Quality

Content

60%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 content is well-structured as a brief review overview that delegates detail to a real one-level reference, with a clear check-fix-verify flow; it loses points for an unnecessary concept explanation, a vague Check step, and the absence of an inline markup example.

Suggestions

Drop or trim the opening explanatory sentence about what landmark regions are — Claude already knows this — and let the Quick Reference carry the introduction.

Make the 'Check' step concrete by listing what to inspect (accessibility tree roles for <main>/<nav>/<header>/<footer>, single <main>, aria-label on duplicate landmarks) instead of 'verify they are correctly structured'.

Inline a minimal landmark markup snippet in the body so the core fix is actionable without opening the reference, keeping rule.md for the fuller example and verification checklist.

Dimension	Reasoning	Score
Conciseness	The body is short and mostly lean, but the opening sentence ('Landmark regions allow screen reader users to quickly identify and jump to major sections...') explains a concept Claude already knows, and the one-line 'Explain' section restates the task rather than adding guidance.	3 / 5
Actionability	Concrete specifics exist (element list in Quick Reference, 'Replace generic <div> containers with semantic landmark elements'), but the 'Check' section is abstract ('Verify that the page uses appropriate HTML5 landmark elements...') and no executable markup example is inlined — the example lives only in the reference file.	3 / 5
Workflow Clarity	The Check → Fix → Explain → Code Review structure gives a clear review sequence, and verification is signalled ('note how to verify the fix with browser accessibility tooling or assistive tech'), with only minor checkpoint detail missing in the body itself.	4 / 5
Progressive Disclosure	The body is a concise overview that clearly signals a one-level-deep pointer to references/rule.md (which exists and holds the code example, rationale, and verification steps), though some Quick Reference content overlaps material repeated in the reference file.	4 / 5
	Total	14 / 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 answers both what and when with concrete, mostly natural trigger terms and a clear accessibility niche, but the embedded rule title reads as a templating artifact and the trigger conditions are broad enough to overlap with sibling accessibility skills.

Suggestions

Reword the description to remove the duplicated 'Use landmark regions correctly' phrase so it reads as a natural sentence rather than a templated insert.

Tighten the 'when' clause to landmark-specific triggers (e.g., 'Use when auditing page structure for screen-reader navigation, missing <main>/<nav>/<footer>, or unlabelled duplicate landmarks') to reduce overlap with generic accessibility review skills.

Add common synonyms users say, such as 'ARIA landmarks' and 'screen reader navigation', to broaden natural trigger coverage.

Dimension	Reasoning	Score
Specificity	Lists several concrete review actions — 'inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — giving good coverage, though the trailing 'where relevant' and the awkwardly embedded rule title leave minor gaps.	4 / 5
Completeness	Both 'what' (check native semantics, inspect keyboard/focus/accessible-names/screen-reader output) and 'when' ('Use when reviewing rendered HTML, interactive components, or design-system patterns...') are present, but the 'when' clause is slightly circular ('patterns related to Use landmark regions correctly') and could be more specific.	4 / 5
Trigger Term Quality	Natural trigger terms like 'reviewing rendered HTML', 'interactive components', 'design-system patterns', and 'landmark regions' are present, but a few common synonyms a user might say (e.g., 'ARIA', 'screen reader navigation') are missing.	4 / 5
Distinctiveness Conflict Risk	The landmark-regions niche is distinct, but the broad trigger ('reviewing rendered HTML, interactive components, or design-system patterns') overlaps with many general accessibility or frontend review skills, so conflict risk remains.	3 / 5
	Total	15 / 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/landmark-regions/SKILL.md
Commit: 30756a7

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