building-components

Guide for building modern, accessible, and composable UI components. Use when building new components, implementing accessibility, creating composable APIs, setting up design tokens, publishing to npm/registry, or writing component documentation.

Quality

59%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.agents/skills/building-components/SKILL.md

Quality

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. Its main strength is the explicit 'Use when...' clause with multiple specific scenarios. The primary weakness is that the capability description stays at a category level rather than listing deeply specific actions, and some trigger terms are broad enough to potentially overlap with adjacent skills.

Suggestions

Add more specific concrete actions to improve specificity, e.g., 'Generates component boilerplate with ARIA attributes, creates prop APIs with slot patterns, configures CSS custom properties for theming'

Sharpen distinctiveness by specifying the technology stack or framework context (e.g., React, Web Components) if applicable, to reduce overlap with general frontend or styling skills

Dimension	Reasoning	Score
Specificity	Names the domain (UI components) and lists several actions (building components, implementing accessibility, creating composable APIs, setting up design tokens, publishing, writing documentation), but these are somewhat high-level categories rather than deeply specific concrete actions like 'extract text from tables' or 'fill forms'.	2 / 3
Completeness	Clearly answers both 'what' (guide for building modern, accessible, composable UI components) and 'when' with an explicit 'Use when...' clause listing six specific trigger scenarios.	3 / 3
Trigger Term Quality	Includes strong natural keywords users would say: 'components', 'accessibility', 'composable', 'design tokens', 'npm', 'registry', 'component documentation'. These cover a good range of terms a developer would naturally use when needing this skill.	3 / 3
Distinctiveness Conflict Risk	While it targets UI component development specifically, terms like 'building new components' and 'writing documentation' are broad enough to potentially overlap with general frontend development skills, CSS/styling skills, or documentation skills. The combination of design tokens + composable APIs + npm publishing does help narrow it, but individually these triggers could conflict.	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 is essentially a well-organized index/table of contents with no substantive content of its own. While it's concise and the references are clearly labeled, it provides zero actionable guidance—no code examples, no workflow, no quick-start instructions. A developer or Claude reading only this file would have no idea how to actually build a component without reading every referenced file.

Suggestions

Add a quick-start section with a concrete, executable example of building a minimal component (e.g., a Button with proper accessibility, TypeScript types, and data attributes).

Add a workflow section that sequences the component-building process: e.g., 1) Define API/props → 2) Implement with composition patterns → 3) Add accessibility → 4) Add styling via data attributes → 5) Validate with checklist → 6) Publish.

Include a brief checklist or validation step (e.g., 'Before publishing, verify: ARIA roles present, keyboard navigation works, TypeScript types exported, design tokens used') to guide quality assurance.

Add a decision tree or brief guidance on when to use which reference (e.g., 'Building a primitive? See definitions.mdx + composition.mdx. Adding to an existing library? See registry.mdx or npm.mdx').

Dimension	Reasoning	Score
Conciseness	The content is lean and efficient. It doesn't explain what UI components are or how accessibility works—it assumes Claude's competence. Every section serves a clear purpose: when to use the skill and where to find detailed references.	3 / 3
Actionability	The skill body contains zero concrete code, commands, examples, or executable guidance. It is entirely a table of contents pointing to reference files, with no quick-start example, no code snippet, and no specific instructions for how to actually build a component.	1 / 3
Workflow Clarity	There is no workflow, sequence, or process described. Building components is inherently a multi-step process (design tokens → primitives → composition → accessibility → publishing), but no steps, ordering, or validation checkpoints are provided.	1 / 3
Progressive Disclosure	The references are well-organized and one-level deep with clear labels, which is good. However, since no bundle files were provided, we cannot verify the referenced paths exist. More importantly, the SKILL.md itself is essentially empty beyond the reference list—it lacks any overview content or quick-start guidance that would make the progressive disclosure effective.	2 / 3
	Total	7 / 12 Passed

Validation

100%

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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: databricks/devhub
Commit: 6338825

Reviewed: about 10 hours 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.