design-system-starter

Create and evolve design systems with design tokens, component architecture, accessibility guidelines, and documentation templates. Ensures consistent, scalable, and accessible UI across products.

1.07x

Quality

64%

Does it follow best practices?

Impact

100%

1.07x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/design-system-starter/SKILL.md

Quality

Content

57%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is rich with executable code and token examples, but it is verbose with tutorial-level explanations and inlines reference material. Its workflow lacks executable validation checkpoints, and it advertises bundle files that are not present.

Suggestions

Remove or compress concept primers Claude already knows (the 'What is a Design System?' list, atomic-design definitions, basic ARIA/semantic-HTML explanations) to tighten the token budget.

Move the large color/typography/spacing/radius/shadow token reference blocks into a references/tokens.md file and keep only a representative example inline, improving both conciseness and progressive disclosure.

Fix the 'Bundled Resources' list: the templates/*.json, templates/*.tsx, and checklists/*.md files referenced do not exist — either create them or remove the broken references so navigation is accurate.

Add explicit validation checkpoints to the workflow (e.g., 'Validate token references resolve', 'Run a contrast check against WCAG AA', 'Verify components compile and pass a11y tests') before advancing phases.

Dimension	Reasoning	Score
Conciseness	The body is mostly useful but padded: 'What is a Design System?', atomic-design definitions, basic ARIA explanations ('Use semantic HTML elements', 'Avoid div/span soup'), and Good/Bad props tutorials re-explain concepts Claude already knows, landing at the 'mostly efficient but could be tightened' anchor.	3 / 5
Actionability	Concrete, mostly copy-paste-ready examples abound — full token JSON blocks, TypeScript interfaces, CSS-variable dark mode, polymorphic component snippets — with only minor gaps where full implementations are deferred to references/component-examples.md.	4 / 5
Workflow Clarity	The Design System Workflow sequences Design→Development→Adoption→Maintenance with sub-bullets and a checklist, but these are phase descriptions rather than executable steps, and explicit validation checkpoints are absent (sequence present, checkpoints implicit).	3 / 5
Progressive Disclosure	There is a real one-level reference (references/component-examples.md) signaled inline, but the 'Bundled Resources' list also names templates/ and checklists/ files that do not exist, and large token reference blocks are inlined that arguably belong in a separate file.	3 / 5
	Total	13 / 20 Passed

Description

71%Weight 40%Scale 1-5

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 is specific and distinctive about what the skill does, but lacks any explicit 'when to use' trigger guidance, which caps its completeness. Adding a 'Use when...' clause would meaningfully raise the score.

Suggestions

Add an explicit 'Use when...' clause naming natural trigger phrases (e.g., 'Use when creating or evolving a design system, setting up design tokens, or establishing component architecture and accessibility guidelines').

Include common user synonyms alongside 'design systems' (e.g., 'design system', 'component library', 'UI library', 'design tokens') to improve trigger-term coverage.

Tighten the second sentence ('Ensures consistent, scalable, and accessible UI across products') — it is a benefit statement rather than a capability or trigger, and contributes fluff without adding trigger value.

Dimension	Reasoning	Score
Specificity	The description lists multiple specific concrete actions — 'Create and evolve design systems with design tokens, component architecture, accessibility guidelines, and documentation templates' — giving comprehensive coverage, matching the score-5 anchor.	5 / 5
Completeness	The 'what' is clear and concrete, but there is no explicit 'Use when...' or equivalent trigger clause; per the judging guidelines a missing 'when' caps completeness at 3.	3 / 5
Trigger Term Quality	Natural terms like 'design systems', 'design tokens', 'component architecture', 'accessibility', and 'UI' appear, but a few natural variations/synonyms users might say are missing, so it sits between anchors 3 and 5 (closer to 5 but not comprehensive).	4 / 5
Distinctiveness Conflict Risk	'Design systems' anchored by 'design tokens, component architecture, accessibility guidelines' carves a clear niche with minimal conflict risk, with only minor overlap against general frontend skills.	4 / 5
	Total	16 / 20 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 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	14 / 16 Passed

Repository: softaworks/agent-toolkit
Path: skills/design-system-starter/SKILL.md
Commit: 3027f20

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

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.