CtrlK
BlogDocsLog inGet started
Tessl Logo

radix-ui-design-system

Build accessible design systems with Radix UI primitives. Headless component customization, theming strategies, and compound component patterns for production-grade UI libraries.

46

Quality

49%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/radix-ui-design-system/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

46%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 skill provides extensive, actionable code examples for Radix UI component patterns, which is its primary strength. However, it is severely bloated—explaining concepts Claude already knows (accessibility basics, headless architecture, CSS variables), duplicating official documentation (primitives reference), and inlining content that should be split across multiple files. The lack of any bundle files means all ~500+ lines compete for context window space without progressive disclosure.

Suggestions

Cut the Overview, Core Principles, 'When to Use', and 'Do not use' sections entirely—Claude knows what Radix UI is and when to use component libraries. Start directly with the Basic Component Pattern.

Move the Common Primitives Reference, Real-World Examples, and Performance Optimization sections into separate bundle files (e.g., PRIMITIVES.md, EXAMPLES.md, PERFORMANCE.md) and reference them with one-line links.

Remove explanatory prose like 'Radix provides unstyled, accessible components (primitives) that you can customize to match any design system' and 'Every Radix primitive is built with accessibility as the foundation'—these add no actionable value.

Add a brief sequential workflow for building a new component: install primitive → scaffold with Root/Trigger/Content pattern → add styling → verify accessibility with checklist → integrate with app.

DimensionReasoningScore

Conciseness

Extremely verbose at ~500+ lines. Extensively explains concepts Claude already knows (what Radix UI is, what accessibility means, what headless architecture is, what CSS variables are). The 'When to Use' / 'Do not use' sections, 'Core Principles' explanations, and 'Overview' section are largely unnecessary padding. The primitives reference section duplicates official docs. Much of this could be cut by 60%+ without losing actionable value.

2 / 5

Actionability

Provides numerous concrete, executable code examples covering Dialog, Select, DropdownMenu, Tabs, Tooltip, animation patterns, form integration, and theming strategies. The examples are copy-paste ready and cover common use cases well. Minor gap: some examples use placeholder class names like 'your-button-styles' without concrete values, and the troubleshooting solutions are somewhat thin.

4 / 5

Workflow Clarity

This is primarily a reference/pattern skill rather than a multi-step workflow skill, so the bar is lower. However, the 'Getting Started' section lacks a clear sequential workflow (install → create component → style → test). The accessibility checklist is good but there's no validation step or feedback loop for verifying accessibility compliance after building components. For a design system skill, a build-validate-iterate workflow would strengthen this.

3 / 5

Progressive Disclosure

This is a monolithic ~500+ line file with no bundle files to offload content to. The Common Primitives Reference, Real-World Examples, Performance Optimization, and Integration sections should each be separate files. The 'Related Skills' section references skills that may not exist. Everything is inlined in one massive document with no actual supporting files provided.

2 / 5

Total

11

/

20

Passed

Description

53%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 identifies a clear niche (Radix UI design systems) and mentions relevant technical concepts, but relies on abstract category labels rather than concrete actions. The lack of an explicit 'Use when...' clause significantly weakens its utility for skill selection, and it could benefit from more natural trigger terms that users would actually say when needing help with Radix primitives.

Suggestions

Add an explicit 'Use when...' clause with trigger phrases like 'Use when the user mentions Radix UI, @radix-ui packages, headless components, or building accessible UI primitives in React.'

Replace abstract category labels with concrete actions, e.g., 'Build dialogs, dropdowns, popovers, and tooltips using Radix UI primitives; configure theme tokens; compose compound components.'

Include natural synonyms and terms users would say, such as 'unstyled components', 'accessible components', specific primitive names (Dialog, Popover, Select), and package references like '@radix-ui/react-*'.

DimensionReasoningScore

Specificity

Names the domain (Radix UI / design systems) and mentions a few concrete concepts like 'headless component customization', 'theming strategies', and 'compound component patterns', but these are more like category labels than specific actions. It doesn't list concrete tasks like 'create dropdown menus', 'build dialog components', or 'configure theme tokens'.

3 / 5

Completeness

The 'what' is present but somewhat abstract (build design systems, customize headless components, theming, compound patterns). There is no explicit 'when' clause — no 'Use when...' guidance telling Claude when to select this skill. Per rubric guidelines, missing 'Use when' caps completeness at 3.

3 / 5

Trigger Term Quality

Includes relevant terms like 'Radix UI', 'design systems', 'headless component', 'theming', and 'compound component patterns' which are useful for developers familiar with the ecosystem. However, it misses natural user phrases like 'unstyled components', 'accessible dropdown', 'dialog', 'popover', '@radix-ui', or specific primitive names users would mention.

3 / 5

Distinctiveness Conflict Risk

Mentioning 'Radix UI' specifically makes this fairly distinct from generic UI or component library skills. There's minor overlap risk with general React component or design system skills, but the Radix UI specificity helps differentiate it.

4 / 5

Total

13

/

20

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.

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (849 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

9

/

11

Passed

Repository
administrakt0r/AI-Agents-Safe-Coding-Skills
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.