Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
58
66%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/frontend-ui-engineering/SKILL.mdQuality
Discovery
67%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 reasonably well-structured description that clearly communicates both what the skill does and when to use it, with an explicit 'Use when' clause. Its main weaknesses are moderate specificity (actions are category-level rather than concrete) and limited trigger term coverage, missing common natural language terms users would use when requesting UI work (e.g., 'frontend,' 'React,' 'CSS,' 'web app'). The distinction from other coding-related skills could also be sharper.
Suggestions
Add more natural trigger terms users would say, such as 'frontend,' 'React,' 'CSS,' 'styling,' 'responsive design,' 'web app,' 'dashboard,' or file extensions like '.tsx', '.css'.
Increase specificity by listing more concrete actions, e.g., 'building forms, data tables, navigation bars, modals, responsive layouts' instead of the broader 'creating components, implementing layouts.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (UI development) and some actions like 'creating components, implementing layouts, managing state,' but these are somewhat general categories rather than highly specific concrete actions like 'extract text from PDFs, fill forms, merge documents.' | 2 / 3 |
Completeness | Clearly answers both 'what' (builds production-quality UIs) and 'when' with explicit trigger guidance ('Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality'). | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'components,' 'layouts,' 'state,' 'interfaces,' and 'production-quality,' but misses common user-facing variations such as 'frontend,' 'React,' 'CSS,' 'styling,' 'responsive design,' 'web app,' 'dashboard,' or specific framework names users would naturally mention. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on 'production-quality UIs' provides some distinctiveness, but 'building or modifying user-facing interfaces' and 'creating components' could overlap with general coding skills, frontend framework skills, or design system skills. The 'production-quality rather than AI-generated' qualifier helps but the boundaries remain somewhat fuzzy. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, actionable skill with excellent code examples and a valuable 'AI aesthetic' avoidance guide that provides genuinely novel guidance. Its main weaknesses are length (could be more concise by removing motivational content and concepts Claude already knows) and the lack of a clear sequential workflow for building components. The referenced accessibility checklist file is missing from the bundle.
Suggestions
Remove or significantly trim the 'Common Rationalizations' table — it's motivational rather than instructional and Claude doesn't need convincing.
Add a brief sequential workflow section (e.g., '1. Scaffold component structure → 2. Implement core logic → 3. Add accessibility → 4. Add loading/error/empty states → 5. Run verification checklist') to improve workflow clarity.
Split detailed sections like accessibility patterns and state management into separate reference files, keeping SKILL.md as a concise overview with links.
Provide the referenced `references/accessibility-checklist.md` file or remove the reference if it doesn't exist.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is generally well-structured but includes some content Claude already knows (e.g., explaining what prop drilling is, basic accessibility concepts, the 'Common Rationalizations' table which is motivational rather than instructional). The AI aesthetic table is valuable and novel, but the overall document could be tightened by ~30%. | 2 / 3 |
Actionability | The skill provides fully executable, copy-paste-ready code examples throughout — component patterns, state management, accessibility implementations, skeleton loading, optimistic updates, and responsive design patterns. The state management decision table is concise and immediately actionable. | 3 / 3 |
Workflow Clarity | The verification checklist at the end provides clear validation steps, but there's no sequenced workflow for building a component from start to finish. The skill reads more as a reference guide than a step-by-step process. For a skill covering multi-step UI building, the lack of an explicit build sequence (e.g., 'start with structure → add accessibility → verify') is a gap. | 2 / 3 |
Progressive Disclosure | The skill references `references/accessibility-checklist.md` in a 'See Also' section, but this file is not provided in the bundle. The document is quite long (~250 lines of content) and could benefit from splitting detailed sections (e.g., accessibility patterns, state management) into separate reference files with clear navigation from the overview. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
f17c6e8
Table of Contents
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.