create-voice
Generate screen reader accessibility specifications for VoiceOver (iOS), TalkBack (Android), and ARIA (Web). Use when the user mentions "voice", "voiceover", "screen reader", "accessibility spec", "talkback", "aria", or wants to create accessibility documentation for a UI component.
80
76%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.cursor/skills/create-voice/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong description that clearly communicates its purpose and provides excellent trigger guidance. The 'Use when...' clause is well-constructed with multiple natural keywords. The main weakness is that the capability description could be more specific about what actions are performed beyond 'generate specifications' — e.g., defining roles, focus order, announcement text, or gesture mappings.
Suggestions
Add more specific concrete actions to the capability portion, e.g., 'Defines roles, labels, focus order, announcement text, and gesture mappings for screen reader accessibility specifications.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (screen reader accessibility specifications) and lists the three platforms (VoiceOver, TalkBack, ARIA), but doesn't enumerate multiple concrete actions beyond 'generate specifications' and 'create accessibility documentation'. It could be more specific about what the specs contain (e.g., role assignments, focus order, announcements). | 2 / 3 |
Completeness | Clearly answers both 'what' (generate screen reader accessibility specifications for VoiceOver, TalkBack, and ARIA) and 'when' (explicit 'Use when...' clause with specific trigger terms and scenarios). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'voice', 'voiceover', 'screen reader', 'accessibility spec', 'talkback', 'aria', and 'accessibility documentation for a UI component'. These are terms users would naturally use when requesting this type of work. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche focused specifically on screen reader accessibility specifications across three named platforms. The trigger terms are specific enough to avoid conflicts with general accessibility, coding, or documentation skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill excels at actionability and workflow clarity — every step has executable code, clear sequencing, and validation checkpoints. However, it is severely bloated: the rendering script is duplicated/near-duplicated across sections, the Notes section restates what the code already communicates, and slot insertion logic appears in at least 4 places. The content would benefit enormously from extracting large code blocks into referenced files and eliminating redundant explanatory notes.
Suggestions
Extract the large Step 4 extraction script and Step 10-11 rendering script into separate referenced files (e.g., extraction-script.js, render-script.js) to reduce the SKILL.md body from ~600 lines to a manageable overview.
Remove or drastically condense the Notes section — most bullet points restate what the code and workflow steps already communicate (e.g., font loading behavior, slot handling, bounding box capture). Keep only notes that add genuinely new information not evident from the code.
Deduplicate the slot insertion logic that appears nearly identically in the main rendering path, the richest-variant fallback, and the variant search loop — extract it into a named helper function within the script.
Condense the MCP Adapter table notes — the page-context workaround and branch URL guidance could be 2-3 lines instead of a full paragraph each.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This skill is extremely verbose at ~600+ lines. It contains massive JavaScript code blocks with extensive inline comments, repeated slot insertion logic duplicated across multiple code sections, and lengthy notes that restate what the code already does. Much of the explanation (e.g., how SLOT nodes work, font loading rationale, bounding box capture details) could be dramatically condensed. | 1 / 3 |
Actionability | The skill provides fully executable JavaScript code blocks for every step, concrete MCP adapter mappings, specific template node names, and copy-paste-ready scripts with clear placeholder conventions. Every workflow step has precise, executable guidance. | 3 / 3 |
Workflow Clarity | The 13-step workflow is clearly sequenced with a progress checklist, explicit validation in Step 12 (screenshot capture + verification criteria + up to 3 fix iterations), and clear error recovery paths (MCP connection failures, missing template keys, unresolved focus stops with richest-variant fallback). | 3 / 3 |
Progressive Disclosure | The skill references external files well (agent-screenreader-instruction.md, voiceover.md, talkback.md, aria.md) and has a clear section structure. However, the massive inline code blocks and extensive Notes section make this a monolithic wall of content. The rendering script alone is ~200 lines and could be in a separate file, and the Notes section repeats information already present in the code/workflow. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (1085 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- redongreen/uSpec
- Commit
4eae941
- 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.