Content
56%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is well-structured as an overview with an exemplary one-level-deep reference split, and the check/fix directives are concrete in intent. Its weaknesses are templated redundancy (the uniqueness rule stated four times across intro, Quick Reference, Check, and Explain/Code Review boilerplate) and the absence of any executable detection method in the body itself.
Suggestions
Merge Quick Reference into the intro and drop the Explain section — the uniqueness rule is currently stated about four times, and the unique content would fit in half the body.
Include one executable detection detail in the body, e.g. a JavaScript snippet comparing `document.querySelectorAll('[accesskey]')` values or the relevant axe/Lighthouse rule, rather than deferring all detection method to the reference.
Replace the templated Code Review boilerplate with rule-specific flags (which duplicate values, which elements win the shortcut conflict in each browser).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The core rule is restated roughly four times: the intro ("Duplicate access keys cause conflicts where only one element...is reachable"), Quick Reference bullet 1 ("Each `accesskey` attribute value must be unique on the page"), and the Check section ("Check for duplicate `accesskey` attributes across the document to ensure each shortcut is unique"). The Explain section ("Explain how duplicate access keys affect keyboard accessibility...") and the Code Review section are templated restatements that add no new information, so several sections are padding — matching anchor 2 rather than 3, where only some tightening would be needed. | 2 / 5 |
Actionability | There is concrete directional guidance — "Check for duplicate `accesskey` attributes across the document" and "Assign unique values to each `accesskey` attribute or remove redundant ones" — but no executable method for the key step: no selector, command, or code snippet for actually finding duplicates (e.g. comparing `document.querySelectorAll('[accesskey]')` values or an axe/Lighthouse rule), and detection is deferred to the reference. This fits anchor 3 (some concrete guidance but incomplete, missing key details) rather than 4 (mostly executable) or 2 (only high-level hints). | 3 / 5 |
Workflow Clarity | For this simple single-task skill the body presents a clear, unambiguous sectioned flow — Quick Reference (rule), Check (find duplicates), Fix (assign unique or remove), Explain, Code Review ("Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule") — with verification at least gestured at ("note how to verify the fix with browser accessibility tooling or assistive tech"). Not 5 because the concrete validation checkpoints (axe/Lighthouse, keyboard-only retest) live in references/rule.md rather than the body, leaving the body's own checkpoints implicit; not 3 because the sequence is clear and the single action is unambiguous. | 4 / 5 |
Progressive Disclosure | The ~30-line body is a clean overview with section headers, and the implementation details (code example, why-it-matters, exceptions, standards, verification steps) are correctly split into references/rule.md — a real, substantive 49-line file exactly one level deep with no further nested references. The pointer is clearly signaled ("For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`"), matching the anchor 5 example of a clear overview with well-signaled one-level-deep references. | 5 / 5 |
Total | 14 / 20 Passed |