design-system-starter
tessl i github:softaworks/agent-toolkit --skill design-system-starterCreate and evolve design systems with design tokens, component architecture, accessibility guidelines, and documentation templates. Ensures consistent, scalable, and accessible UI across products.
Validation
81%| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (604 lines); consider splitting into references/ and linking | Warning |
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 13 / 16 Passed | |
Implementation
35%This skill is significantly over-engineered and verbose, explaining foundational concepts Claude already understands (design systems, atomic design, WCAG). The content would be more effective as a lean overview pointing to the bundled reference files, rather than duplicating extensive token schemas and component patterns inline. The actionability is moderate but hampered by incomplete examples that reference external files.
Suggestions
Remove the 'Design System Philosophy' and 'What is a Design System?' sections entirely - Claude knows these concepts
Move the extensive JSON token examples to the referenced templates/design-tokens-template.json file and keep only a minimal example inline
Reduce the Component Architecture section to a brief overview with links to references/component-examples.md for full implementations
Add explicit validation steps to the workflow (e.g., 'Run contrast checker before finalizing colors', 'Validate tokens with schema before implementation')
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at 400+ lines. Explains concepts Claude already knows (what a design system is, atomic design methodology, WCAG basics). Includes extensive JSON examples that could be in referenced 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. The component examples show interfaces but not full implementations. Code is mostly illustrative rather than copy-paste executable. | 2 / 3 |
Workflow Clarity | The 'Design System Workflow' section lists phases but lacks explicit validation checkpoints. The 'Quick Start Checklist' is helpful but doesn't include verification steps or feedback loops for catching errors during implementation. | 2 / 3 |
Progressive Disclosure | References bundled resources appropriately (templates, references, checklists), but the main file contains massive amounts of content that should be in those referenced files. The token examples, component architecture details, and theming sections should be split out. | 2 / 3 |
Total | 7 / 12 Passed |
Activation
43%The description effectively communicates specific capabilities around design systems with concrete deliverables. However, it 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 natural user language variations.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when the user asks about design systems, UI consistency, component libraries, or creating style guides'
Include common user-facing synonyms such as 'UI kit', 'style guide', 'theme tokens', 'component library' to improve trigger term coverage
Specify file types or contexts if applicable (e.g., 'Figma tokens', 'CSS variables', 'JSON tokens') to reduce overlap with general documentation skills
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'design tokens, component architecture, accessibility guidelines, and documentation templates' along with outcomes 'consistent, scalable, and accessible UI'. | 3 / 3 |
Completeness | Describes what the skill does 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 misses common user variations like 'UI kit', 'style guide', 'theme', 'components library', or 'brand guidelines'. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on 'design systems' is somewhat specific, but terms like 'accessibility guidelines' and 'documentation templates' could overlap with general accessibility or documentation skills. | 2 / 3 |
Total | 8 / 12 Passed |
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.