design-system
Produce production-grade UI designs using clear design tokens, layout rules, motion guidance, and accessibility checks for consistent, scalable frontend development.
64
48%
Does it follow best practices?
Impact
92%
1.31xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agent-skills/design-system/SKILL.mdQuality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description communicates the general domain (UI design systems) and lists relevant capability areas, but lacks concrete action verbs and completely omits trigger guidance for when Claude should select this skill. The language is somewhat buzzword-heavy ('production-grade', 'scalable') without providing the specificity needed for reliable skill selection.
Suggestions
Add an explicit 'Use when...' clause with trigger terms like 'design system', 'design tokens', 'component library', 'theme', or 'style guide'.
Replace abstract categories with concrete actions: instead of 'clear design tokens', specify 'define color palettes, typography scales, and spacing systems'.
Include common file/format triggers users might mention: 'CSS variables', 'Tailwind config', 'Figma tokens', or specific framework references.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (UI designs) and lists some actions (design tokens, layout rules, motion guidance, accessibility checks), but these are somewhat abstract categories rather than concrete specific actions like 'create color palettes' or 'generate spacing scales'. | 2 / 3 |
Completeness | Describes what the skill does but completely lacks a 'Use when...' clause or any explicit trigger guidance. Per rubric guidelines, missing explicit trigger guidance caps completeness at 2, and this has no trigger guidance at all. | 1 / 3 |
Trigger Term Quality | Includes some relevant terms like 'UI designs', 'design tokens', 'accessibility', and 'frontend development', but misses common user phrases like 'design system', 'component styles', 'CSS variables', 'theme', or 'styling guide'. | 2 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to UI/design systems but could overlap with general frontend development skills, CSS skills, or accessibility-focused skills. The phrase 'production-grade UI designs' is moderately distinctive but not sharply defined. | 2 / 3 |
Total | 7 / 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 skill provides highly actionable, executable code examples for frontend design systems with good coverage of tokens, layout, motion, and accessibility. However, it suffers from verbosity—particularly the inline token definitions and extensive examples that could be externalized. The workflow lacks integrated validation checkpoints, treating accessibility as a separate checklist rather than a continuous verification step.
Suggestions
Move the full design-tokens.ts content to a separate TOKENS.md or reference file, keeping only a minimal example in the main skill
Integrate validation checkpoints into the workflow steps (e.g., 'After Step 3, run contrast checker before proceeding') rather than having a separate accessibility checklist
Remove the 'When to use this skill' section—Claude can infer appropriate usage from the skill description and content
Consolidate the three examples into one detailed example, or move additional examples to an EXAMPLES.md file
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes substantial concrete code examples which is good, but contains some unnecessary verbosity like the full design tokens object (which could be referenced externally) and explanatory sections like 'When to use this skill' that explain obvious use cases Claude would understand. | 2 / 3 |
Actionability | Provides fully executable TypeScript/TSX/CSS code examples, concrete YAML specifications, and copy-paste ready component structures. The design tokens, motion guidelines, and component examples are all directly usable. | 3 / 3 |
Workflow Clarity | Steps 1-5 provide a clear sequence, but validation is relegated to a checklist (Step 4) rather than integrated feedback loops. There's no explicit 'validate -> fix -> retry' pattern for catching design system inconsistencies before handoff. | 2 / 3 |
Progressive Disclosure | The skill references related skills at the bottom but includes extensive inline content (full token definitions, multiple examples, troubleshooting) that could be split into separate reference files. The 200+ line token definition particularly bloats the main file. | 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 |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
- Repository
- supercent-io/skills-template
- Commit
c033769
- 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.