Create and evolve design systems with design tokens, component architecture, accessibility guidelines, and documentation templates. Ensures consistent, scalable, and accessible UI across products.
Install with Tessl CLI
npx tessl i github:softaworks/agent-toolkit --skill design-system-starter59
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillEvaluation — 100%
↑ 1.07xAgent success when using this skill
Validation for skill structure
Discovery
42%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 effectively communicates specific capabilities around design systems with concrete deliverables, but critically lacks explicit trigger guidance ('Use when...') which would help Claude know when to select this skill. The trigger terms are domain-appropriate but could benefit from more user-facing variations.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when the user asks about design systems, UI consistency, component libraries, design tokens, or creating style guides'
Include common user-facing variations such as 'UI kit', 'style guide', 'theme system', 'component library', or 'brand system' to improve trigger term coverage
Consider adding file type triggers if applicable (e.g., 'Figma tokens', 'CSS variables', 'JSON tokens') to further distinguish from generic design or documentation skills
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'design tokens, component architecture, accessibility guidelines, and documentation templates' along with clear outcomes 'consistent, scalable, and accessible UI across products'. | 3 / 3 |
Completeness | Describes what the skill does well but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. | 1 / 3 |
Trigger Term Quality | Contains relevant domain terms like 'design systems', 'design tokens', 'component architecture', 'accessibility' but missing common user variations like 'UI kit', 'style guide', 'theme', 'components library', or 'brand guidelines'. | 2 / 3 |
Distinctiveness Conflict Risk | The 'design systems' focus provides some distinction, but terms like 'accessibility guidelines' and 'documentation templates' could overlap with general accessibility or documentation skills. | 2 / 3 |
Total | 8 / 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 significantly over-engineered and verbose, explaining fundamental concepts Claude already understands (design systems, atomic design, WCAG basics). While it provides useful token structures and references external files, the main document contains far too much inline content that should be split into referenced materials. The actionable guidance is diluted by explanatory content.
Suggestions
Remove the 'Design System Philosophy' and 'What is a Design System?' sections entirely - Claude knows these concepts
Move the detailed token JSON examples to templates/design-tokens-template.json and reference it instead of inlining 100+ lines of JSON
Move Component Architecture and Theming sections to separate reference files, keeping only a brief overview with links
Add explicit validation steps to the workflow (e.g., 'Run contrast checker before finalizing colors', 'Test keyboard navigation before marking component complete')
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at 400+ lines. Explains basic concepts Claude already knows (what a design system is, atomic design methodology, WCAG basics). Includes extensive JSON examples that could be referenced from external files. The 'Design System Philosophy' section is entirely unnecessary padding. | 1 / 3 |
Actionability | Provides concrete JSON token examples and TypeScript interfaces, but many are incomplete or reference external files for 'complete' implementations. The component examples are interface definitions rather than executable code. Quick Start section is vague ('Just describe what you need'). | 2 / 3 |
Workflow Clarity | The 'Design System Workflow' section lists phases but lacks validation checkpoints or feedback loops. The Quick Start Checklist is helpful but doesn't sequence steps with explicit verification points. No guidance on what to do when things go wrong. | 2 / 3 |
Progressive Disclosure | References external files appropriately (references/component-examples.md, templates/), but the main file contains massive amounts of content that should be in those referenced files instead. The token examples, component architecture details, and theming sections should be separate documents. | 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 (604 lines); consider splitting into references/ and linking | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 11 Passed | |
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.