ux-ui-component
UI 컴포넌트 명세 에이전트. 컴포넌트의 UI/UX 명세를 작성합니다.
Install with Tessl CLI
npx tessl i github:shaul1991/shaul-agents-plugin --skill ux-ui-component44
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
22%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 description is too brief and vague to effectively guide skill selection. It lacks concrete actions, explicit trigger conditions, and sufficient keywords. The description would benefit significantly from listing specific capabilities and adding a clear 'Use when...' clause.
Suggestions
Add a 'Use when...' clause with trigger terms like 'component spec', 'UI documentation', 'component API', 'design specification', or 'component 명세'
List specific concrete actions such as 'defines props and states', 'documents component interactions', 'specifies accessibility requirements', 'creates usage examples'
Include common file types or output formats this skill produces (e.g., 'generates .md specification files', 'creates Storybook documentation')
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description only mentions 'UI/UX 명세를 작성합니다' (writes UI/UX specifications) which is vague. It doesn't list concrete actions like 'define props', 'document states', 'specify interactions', or 'create accessibility guidelines'. | 1 / 3 |
Completeness | Only partially answers 'what' (writes UI/UX specifications) and completely lacks a 'when' clause. There's no explicit trigger guidance like 'Use when documenting components' or 'Use when creating component specifications'. | 1 / 3 |
Trigger Term Quality | Contains some relevant keywords like 'UI 컴포넌트' (UI component), '명세' (specification), and 'UI/UX', but missing common variations users might say like 'component docs', 'design spec', 'component API', or file extensions. | 2 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to UI components and specifications, but could overlap with general documentation skills, design system skills, or frontend development skills. The term '명세' (specification) is fairly distinctive but not enough to prevent conflicts. | 2 / 3 |
Total | 6 / 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 concise but lacks actionable content. It reads more like a role description than an instructional skill. Claude would not know how to actually write a UI component spec from this content - there are no templates, examples, format specifications, or process steps.
Suggestions
Add a concrete template or example of what a completed UI component spec should look like (e.g., spec for a Button component with states, variants, interactions)
Define the specific format/structure for specs - what sections are required, what information goes in each section
Add a step-by-step workflow: 1. Identify component states 2. Define each variant 3. Document interactions 4. Validate against design system
Include example output showing the expected file structure and content in `docs/ui/components/`
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is extremely lean with no unnecessary explanations. Every line serves a purpose - role, responsibilities, triggers, and output location. | 3 / 3 |
Actionability | The skill provides no concrete guidance on HOW to write UI/UX specs. It lists responsibilities abstractly ('상태별 디자인 정의', '인터랙션 정의') without examples, templates, or executable instructions. | 1 / 3 |
Workflow Clarity | No workflow or process is defined. The skill doesn't explain how to approach spec writing, what steps to follow, or how to validate the output quality. | 1 / 3 |
Progressive Disclosure | The content is appropriately brief for an overview, and references an output location. However, there are no links to templates, examples, or detailed guides that would help Claude actually perform the task. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 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.