frontend-design
Transform UI style requirements into production-ready frontend code with systematic design tokens, accessibility compliance, and creative execution. Use when building websites, web applications, React/Vue components, dashboards, landing pages, or any web UI requiring both design consistency and aesthetic quality.
49
54%
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-design/SKILL.mdQuality
Discovery
82%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 solid description that clearly communicates both what the skill does and when to use it, with good trigger term coverage across common frontend technologies and use cases. Its main weakness is that the capability description is somewhat abstract ('transform UI style requirements into production-ready frontend code') rather than listing specific concrete actions, and the broad scope could cause overlap with other frontend or coding skills.
Suggestions
Add more specific concrete actions to improve specificity, e.g., 'generate CSS custom properties, build component style systems, implement responsive layouts, create color palettes and typography scales'
Narrow the scope or add distinguishing constraints to reduce conflict risk with general frontend coding skills, e.g., emphasize that this is specifically for design-system-driven styling rather than general component logic
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (frontend/UI development) and mentions some actions like 'transform UI style requirements into production-ready frontend code' and references design tokens and accessibility compliance, but the specific actions are somewhat abstract rather than listing concrete discrete tasks like 'create component libraries, generate CSS variables, implement responsive layouts'. | 2 / 3 |
Completeness | Clearly answers both 'what' (transform UI style requirements into production-ready frontend code with design tokens, accessibility, creative execution) and 'when' (explicit 'Use when' clause listing specific scenarios like building websites, React/Vue components, dashboards, landing pages). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'websites', 'web applications', 'React/Vue components', 'dashboards', 'landing pages', 'web UI', 'design tokens', 'accessibility'. These cover a good range of terms a user would naturally use when requesting frontend UI work. | 3 / 3 |
Distinctiveness Conflict Risk | While it specifies frontend UI styling with design tokens and accessibility, the scope is quite broad ('any web UI') and could overlap with general coding skills, React component skills, or CSS/styling skills. The combination of design tokens + accessibility + aesthetic quality provides some distinction but the breadth reduces clarity of niche. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is comprehensive in scope but severely undermined by its verbosity — it reads more like a design system handbook than a concise skill file. It repeats information across sections (token scales appear in multiple places, checklists overlap), includes meta-prompt templates that Claude doesn't need, and explains fundamental concepts Claude already understands. The referenced bundle files don't exist, making the progressive disclosure structure hollow while the SKILL.md itself contains far too much inline content.
Suggestions
Reduce the file to under 150 lines by extracting token scales, design direction templates, prompt templates, and detailed checklists into separate referenced files (and actually provide those files in the bundle).
Remove the 'Standard Prompting Workflow' section entirely — Claude doesn't need prompt templates for prompting itself; convert any unique guidance from those templates into direct instructions.
Eliminate explanations of concepts Claude already knows (what design tokens are, why accessibility matters, what WCAG AA means) and replace with terse rules and concrete code examples only.
Add explicit validation gates between workflow phases with specific commands or checks to run (e.g., 'Run contrast checker on all token pairs before proceeding to component development').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~600+ lines. Explains concepts Claude already knows (what design tokens are, what accessibility means, basic CSS/React patterns). Includes full prompt templates that Claude doesn't need to be told how to prompt itself. The typography scale, spacing scale, radius scale, and shadow scale definitions are repeated or restated multiple times. The 'Design Direction Templates' section, multiple prompt templates, and extensive checklists massively inflate token cost with marginal value. | 1 / 3 |
Actionability | Contains some concrete, executable code snippets (fluid typography CSS, skeleton component TSX, motion CSS) but much of the content is descriptive checklists, abstract guidelines, and prompt templates rather than directly executable guidance. The 'Master Prompt Template' and other prompt sections are meta-instructions about how to prompt, not actionable implementation code. Many code blocks are incomplete or illustrative rather than copy-paste ready. | 2 / 3 |
Workflow Clarity | The four-phase workflow (Design Analysis → Component Development → Page Assembly → Quality Assurance) provides a clear sequence, and the verification checklist at the end is thorough. However, there are no explicit validation checkpoints between phases — no 'stop and verify tokens before proceeding to components' gates, no error recovery loops. The QA phase is a passive checklist rather than an active validation step with specific commands or tools to run. | 2 / 3 |
Progressive Disclosure | The skill references multiple supporting files (examples/css/tokens.css, examples/typescript/design-tokens.ts, templates/tailwind-config.js, etc.) but no bundle files are provided, meaning all those references are broken. Meanwhile, the SKILL.md itself is a monolithic wall of text that inlines enormous amounts of detail (full token scales, multiple design direction templates, four complete prompt templates, extensive checklists) that should be in separate referenced files. The content that claims to be in external files is effectively duplicated or described inline anyway. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (982 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- jjyaoao/HelloAgents
- Commit
52b2597
- 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.