frame-title

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

Quality

64%

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

Quality

Content

57%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.

This is a clean, well-structured simple review skill with excellent progressive disclosure, but the body restates known concepts, lacks inline executable examples, and only implicitly references verification. Tightening the prose and surfacing a concrete validation step would raise the middle dimensions.

Suggestions

Trim the intro paragraph and the 'Explain' section to remove concepts Claude already knows (what frame titles are and why they help screen-reader users), keeping only the actionable rule.

Add one short inline code example showing a correct vs. incorrect iframe title so the body is self-contained without forcing a jump to the reference.

Add an explicit verification checkpoint in the body (e.g., a 'Verify' step: 'Confirm the title is non-empty and descriptive via the browser accessibility tree or axe/Lighthouse') to close the workflow's implicit validation gap.

Dimension	Reasoning	Score
Conciseness	The body is short, but the intro paragraph ('Frame titles allow users of assistive technology to quickly understand the content of an iframe... crucial for navigation and orientation') and the 'Explain' section restate concepts Claude already knows, and Quick Reference/Check/Fix repeat the same 'add a title attribute' point. It is not 4 because the redundant concept explanation could be trimmed, and not 2 because it is not severely padded.	3 / 5
Actionability	Concrete instructions are present ('Verify that all <iframe> and <frame> elements have a non-empty title attribute', 'Add a descriptive title attribute'), but no inline code examples are in the body and the guidance stays high-level about what makes a good title. It is not 4 because executable examples are deferred entirely to the reference, and not 2 because the guidance is specific rather than vague hints.	3 / 5
Workflow Clarity	A clear section sequence exists (Check, Fix, Explain, Code Review) and verification is mentioned ('note how to verify the fix with browser accessibility tooling'), but there is no explicit validation checkpoint or feedback loop in the body — those live in the reference. It is not 4 because checkpoints are implicit rather than present, and not 2 because the sequence is well-defined.	3 / 5
Progressive Disclosure	The body is well-organized into clear sections and points to a single, clearly signaled, one-level-deep reference ('see references/rule.md', verified to exist) for full implementation details and code examples. It is not 4 because navigation is easy and the split is appropriate with no nesting or buried references.	5 / 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 several concrete actions and a clear trigger clause, but its actions and review language are generic accessibility-review boilerplate rather than frame-title-specific. Distinctiveness is the weakest dimension due to overlap with sibling accessibility skills.

Suggestions

Replace the generic a11y-review actions with frame-title-specific actions (e.g., 'Verify every <iframe> and <frame> has a non-empty, descriptive title attribute; flag generic titles like "frame" or "iframe"') so the description is distinct from other accessibility skills.

Add natural synonyms users actually say, such as 'iframe title', 'frame title', or 'embedded content', to broaden trigger-term coverage.

Make the 'when' clause use concrete user phrasing (e.g., 'Use when the user mentions iframes, frames, or embedded content lacking titles') rather than referencing the rule name.

Dimension	Reasoning	Score
Specificity	Lists several concrete actions ('Check native semantics', 'inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), though they are generic a11y-review steps rather than frame-title-specific. It is not 5 because coverage is not comprehensive for this rule, and not 3 because multiple specific actions are explicitly named.	4 / 5
Completeness	Both 'what' (review/inspect accessibility aspects of frame titles) and an explicit 'when' ('Use when reviewing rendered HTML... related to Provide titles for iframes and frames') are present. It is not 5 because the 'what' actions are generic and the 'when' leans on the rule name rather than concrete user phrasing.	4 / 5
Trigger Term Quality	Natural terms appear ('rendered HTML', 'interactive components', 'design-system patterns', 'iframes and frames'), giving good keyword coverage. It is not 5 because common synonyms like 'iframe title' or 'embedded content' are missing, and not 3 because several natural phrases are present.	4 / 5
Distinctiveness Conflict Risk	The trigger 'related to Provide titles for iframes and frames' is niche, but the surrounding a11y-review language ('native semantics, keyboard behavior, focus flow, accessible names, screen-reader output') is a templated pattern shared across many accessibility skills, creating overlap risk. It is not 4 because the generic review language is not mostly distinct from sibling a11y skills.	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/frame-title/SKILL.md
Commit: 30756a7

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