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.
65
58%
Does it follow best practices?
Impact
Pending
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') rather than listing concrete discrete 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, but the specific actions are somewhat abstract rather than listing concrete discrete tasks like 'create component libraries, generate CSS variables, build 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
35%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 over-engineered for a SKILL.md file. It contains extensive content that Claude already knows (design system fundamentals, accessibility basics, CSS concepts) and includes meta-prompt templates that are unnecessary when the skill itself should be the instruction. The strongest aspects are the concrete code examples (fluid typography, oklch colors, skeleton patterns) and the clear phase-based workflow, but these are buried in excessive verbosity.
Suggestions
Reduce content by 60-70%: Remove explanations of concepts Claude already knows (WCAG basics, what semantic HTML is, DRY principles, how Tailwind installation works) and focus only on project-specific conventions and non-obvious decisions.
Move the design direction templates, prompt templates, common pitfalls, and advanced techniques into separate referenced files, keeping SKILL.md as a concise overview with clear pointers.
Remove the 'Standard Prompting Workflow' section entirely — Claude doesn't need prompt templates for itself; convert the key requirements from those prompts into direct implementation rules.
Add explicit validation gates between workflow phases (e.g., 'Run token audit script before proceeding to component development') rather than relying solely on a final checklist.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~600+ lines. Explains concepts Claude already knows (what WCAG is, what semantic HTML means, how Tailwind works, what DRY means). 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 are standard design system knowledge. The 'trigger patterns' section explains when to use the skill in excessive detail. Much of this could be reduced to 20% of its size. | 1 / 3 |
Actionability | Contains some concrete, executable code examples (CSS custom properties, TSX skeleton component, fluid typography clamp values, motion CSS), but much of the content is checklists, abstract guidelines, and prompt templates rather than directly executable code. The 'Master Prompt Template' and other prompt sections are meta-instructions about how to prompt, not actionable implementation guidance. Many code blocks are incomplete or illustrative rather than copy-paste ready. | 2 / 3 |
Workflow Clarity | Has a clear 4-phase workflow (Design Analysis → Component Development → Page Assembly → Quality Assurance) with numbered steps, which is good. However, validation is limited to a self-review checklist at the end rather than explicit checkpoints between phases. There's no feedback loop for catching token violations during component development, and no explicit 'stop and validate before proceeding' gates between phases. | 2 / 3 |
Progressive Disclosure | References external files (examples/css/, examples/typescript/, templates/) which is good progressive disclosure structure. However, the SKILL.md itself is monolithic with massive inline content that should be in those referenced files instead. The design direction templates, prompt templates, advanced techniques, and common pitfalls sections could each be separate files. The main file tries to contain everything rather than serving as a concise overview. | 2 / 3 |
Total | 7 / 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
07048a9
- 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.