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.
54
59%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/building-components/SKILL.mdQuality
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. Its weakness is that the domain of 'UI components' is broad enough that it could overlap with other frontend or design system skills, and the actions listed are more categorical than granularly specific.
| 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, and npm publishing helps narrow it, but 'UI components' is still a fairly wide domain. | 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 instructional content in the body itself. While it's concise and the references are clearly labeled, it provides zero actionable guidance—no code examples, no workflows, no concrete steps for any of the listed use cases. A user reading only this file would have no idea how to start building a component.
Suggestions
Add a quick-start section with a concrete, executable example of building a minimal component (e.g., a Button with proper accessibility attributes and TypeScript types).
Include a high-level workflow sequence for building a new component, e.g.: 1. Define the API/props → 2. Implement with accessibility → 3. Add data attributes → 4. Test keyboard navigation → 5. Document.
Add at least one or two inline code snippets demonstrating key patterns (e.g., composable slot pattern, controlled/uncontrolled state) so the skill provides immediate value without requiring reference file lookups.
Consider adding a brief decision tree or guidance on which reference to consult for common scenarios (e.g., 'Building a new primitive? Start with definitions.mdx then accessibility.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 and provides only the navigation structure needed to find detailed guidance. | 3 / 3 |
Actionability | The skill body contains zero concrete code, commands, or executable guidance. It is entirely a table of contents with no quick-start example, no code snippet, and no specific instructions for any task. Everything is deferred to reference files. | 1 / 3 |
Workflow Clarity | There is no workflow, sequence, or process described. The skill doesn't outline how to approach building a component step-by-step, nor does it provide any validation checkpoints. It's purely a list of topics and references. | 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 has no quick-start or overview content—it's essentially only references with no substantive body, making it an empty shell rather than a proper overview that points to details. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
100%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
1cfe305
- 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.