Expert UI/UX design guidance for unique, accessible interfaces. Use for visual decisions, colors, typography, layouts. Always ask before making design decisions. Use this skill when the user asks to build web components, pages, or applications.
43
43%
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 ./bencium-controlled-ux-designer/skills/bencium-controlled-ux-designer/SKILL.mdQuality
Discovery
59%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 covers both what and when, which is good for completeness, but the capabilities described are vague ('guidance', 'visual decisions') rather than concrete actions. The trigger scope is overly broad — triggering for any web component, page, or application build would cause significant conflicts with other development-focused skills. The description would benefit from narrowing its niche and listing more specific, actionable capabilities.
Suggestions
Narrow the 'Use when...' clause to be more distinctive — instead of 'build web components, pages, or applications' (which overlaps with general dev skills), specify triggers like 'choosing color schemes, designing layouts, improving accessibility, or making typography decisions'.
Replace vague terms like 'guidance' and 'visual decisions' with concrete actions such as 'recommends color palettes, selects typography pairings, designs responsive layouts, audits accessibility compliance'.
Add more natural trigger terms users would say, such as 'CSS styling', 'responsive design', 'WCAG', 'theme', 'dark mode', 'spacing', or 'design system'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (UI/UX design) and mentions some areas like colors, typography, and layouts, but the actions are vague ('guidance', 'visual decisions') rather than concrete tasks like 'create wireframes' or 'generate color palettes'. 'Always ask before making design decisions' describes behavior rather than capability. | 2 / 3 |
Completeness | Clearly answers both 'what' (UI/UX design guidance for visual decisions, colors, typography, layouts) and 'when' ('Use this skill when the user asks to build web components, pages, or applications'). The explicit 'Use when...' clause is present with trigger scenarios. | 3 / 3 |
Trigger Term Quality | Includes some natural terms users might say like 'colors', 'typography', 'layouts', 'web components', 'pages', 'applications', but misses common variations like 'CSS', 'responsive design', 'styling', 'theme', 'UI components', 'frontend design', or 'accessibility'. The coverage is partial. | 2 / 3 |
Distinctiveness Conflict Risk | The description is very broad — 'web components, pages, or applications' could trigger for virtually any web development task, conflicting with coding skills, CSS skills, or frontend framework skills. The scope of 'UI/UX design guidance' overlaps heavily with general web development skills. | 1 / 3 |
Total | 8 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more like a comprehensive UI/UX design textbook than a focused skill file. While it contains some useful concrete examples and specific values, the overwhelming majority of content explains design concepts Claude already understands (Gestalt principles, easing curves, accessibility basics, UX heuristics). The content would benefit enormously from being split into a lean overview SKILL.md with references to detailed topic files, reducing the main file from 500+ lines to under 100.
Suggestions
Reduce SKILL.md to a concise overview (~50-80 lines) covering the core protocol (ask before designing, avoid generic patterns, use shadcn/Tailwind) and move detailed guidance on color, typography, animation, and UX patterns into separate referenced files.
Remove explanations of concepts Claude already knows (Gestalt principles, what easing is, basic UX heuristics like 'direct manipulation' and 'progressive disclosure') and keep only project-specific decisions and non-obvious guidance.
Create the referenced bundle files (DESIGN-SYSTEM-TEMPLATE.md, MOTION-SPEC.md) and add additional ones for COLOR-GUIDE.md, TYPOGRAPHY-GUIDE.md, and UX-PATTERNS.md to properly implement progressive disclosure.
Add explicit validation feedback loops in the design workflow, e.g., 'If user rejects direction → ask clarifying questions about what didn't resonate → present revised alternatives' and concrete playwright MCP commands for visual testing.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines. Extensively explains fundamental design concepts Claude already knows (what easing is, what accessibility means, basic UX principles like 'direct manipulation', Gestalt principles). Much of this reads like a design textbook rather than actionable skill instructions. Sections like 'Core UX Principles' and 'Animation & Gestalt Principles' explain well-known concepts at length. | 1 / 3 |
Actionability | Contains some concrete, executable code examples (button implementation, typography hierarchy, Framer Motion snippets) and specific values (timing guidelines, spacing scales). However, much of the content is philosophical guidance and abstract principles rather than concrete instructions. The examples are helpful but buried in extensive descriptive text. | 2 / 3 |
Workflow Clarity | The 'Design Workflow' section provides a clear 4-step sequence (Understand → Explore → Implement → Validate), and the 'Design Decision Protocol' establishes a clear ask-first pattern. However, validation steps are vague ('Use playwright MCP to test visual changes') without concrete commands, and there's no explicit feedback loop for when designs fail validation or user rejects proposals. | 2 / 3 |
Progressive Disclosure | The content is a monolithic wall of text with nearly everything inline. References to DESIGN-SYSTEM-TEMPLATE.md and MOTION-SPEC.md are mentioned but no bundle files are provided, making these dead references. The vast majority of content (color theory, typography scales, animation physics, UX patterns) should be split into separate reference files, with SKILL.md serving as a concise overview. | 1 / 3 |
Total | 6 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (739 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
2e2fa33
Table of Contents
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.