Design system management for building and reusing UI components, tokens, and patterns. Use when working with component libraries, design tokens, style guides, or reusable UI patterns to ensure consistency and promote component reuse.
63
59%
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 ./plugins/product-design/skills/design-system/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 purpose and trigger conditions. The 'Use when...' clause provides good explicit guidance. However, the capabilities could be more specific with concrete actions, and there's moderate risk of overlap with general frontend/UI development skills.
Suggestions
Add more specific concrete actions like 'create design tokens', 'document component APIs', 'generate theme configurations', or 'audit component consistency'
Include file type triggers if applicable (e.g., '.tokens.json', 'theme.ts', 'design-system.config') to improve distinctiveness from general UI skills
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (design system management) and lists some actions (building, reusing UI components, tokens, patterns), but lacks specific concrete actions like 'create color tokens', 'document component APIs', or 'generate style documentation'. | 2 / 3 |
Completeness | Clearly answers both what ('Design system management for building and reusing UI components, tokens, and patterns') and when ('Use when working with component libraries, design tokens, style guides, or reusable UI patterns') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Good coverage of natural terms users would say: 'component libraries', 'design tokens', 'style guides', 'reusable UI patterns', 'UI components'. These are terms developers and designers naturally use when discussing design systems. | 3 / 3 |
Distinctiveness Conflict Risk | While design systems are a specific domain, there could be overlap with general UI/frontend development skills or CSS styling skills. The triggers like 'UI components' and 'style guides' might conflict with broader frontend skills. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
37%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable conceptual overview of design system architecture but lacks the actionable, executable guidance needed for practical use. It describes what a design system should look like rather than providing concrete steps to build or maintain one. The content would benefit from actual code examples, clear workflows for common tasks, and better progressive disclosure to detailed implementation guides.
Suggestions
Add executable code examples showing how to define and use design tokens in a specific framework (e.g., CSS custom properties, styled-components theme)
Create a clear workflow for the most common task: 'How to add a new component to the design system' with validation checkpoints
Replace the static checklist with an actionable process: when to audit, how to identify issues, steps to remediate
Split detailed content (token implementation, component patterns, documentation standards) into separate referenced files
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains useful information but is somewhat verbose with decorative ASCII boxes and tables that could be more compact. The 'Automatic Behaviors' framing adds unnecessary context about what Claude will do rather than just providing the guidance. | 2 / 3 |
Actionability | Provides structural guidance and patterns but lacks executable code examples. The file structures and token hierarchies are illustrative but not copy-paste ready implementations. No actual code showing how to implement tokens or components. | 2 / 3 |
Workflow Clarity | No clear workflow or sequence for building/maintaining a design system. The checklist at the end is static rather than a process. Missing validation steps for when to apply patterns or how to migrate existing code to design system patterns. | 1 / 3 |
Progressive Disclosure | Content is organized into logical sections with headers, but everything is inline in one file. For a topic this broad (tokens, components, patterns, documentation), references to detailed guides for each area would improve navigation. | 2 / 3 |
Total | 7 / 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
0ebe7ae
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.