bencium-controlled-ux-designer
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.
60
51%
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
67%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 adequately communicates the skill's domain (UI/UX design) and includes explicit 'Use when' triggers, which is a strength. However, the capabilities listed are more like topic areas than concrete actions, and the trigger scope is broad enough to potentially conflict with general web development skills. The description would benefit from more specific actions and narrower, more distinctive trigger terms.
Suggestions
Replace vague terms like 'guidance' and 'visual decisions' with concrete actions such as 'create color palettes', 'design responsive layouts', 'recommend typography pairings', 'audit accessibility compliance'.
Add more natural trigger terms users would say, such as 'CSS styling', 'responsive design', 'WCAG', 'dark mode', 'design system', 'UI mockup'.
Narrow the 'Use when' clause to reduce conflict risk — instead of 'build web components, pages, or applications', specify 'when the user needs design guidance on visual styling, accessibility, or layout decisions for web interfaces'.
| 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 accessible interfaces covering colors, typography, layouts) and 'when' (explicit 'Use this skill when the user asks to build web components, pages, or applications' and 'Use for visual decisions'). Has explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some natural keywords users might say like 'colors', 'typography', 'layouts', 'web components', 'pages', 'applications'. However, it misses common variations like 'CSS', 'responsive design', 'styling', 'UI components', 'frontend design', 'accessibility', or 'WCAG'. | 2 / 3 |
Distinctiveness Conflict Risk | The scope is quite broad — 'build web components, pages, or applications' could easily overlap with general web development, frontend coding, or CSS skills. The design focus provides some distinction, but the trigger for 'applications' is overly broad and could conflict with many other skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is comprehensive in coverage but severely over-verbose, explaining many fundamental design concepts that Claude already understands (Gestalt principles, easing functions, WCAG basics, typography fundamentals). The core value—the ask-before-implementing protocol and the emphasis on avoiding generic patterns—is buried under hundreds of lines of general design education. The actionable code examples are good but sparse relative to the overall length.
Suggestions
Reduce content by 60-70%: Remove explanations of concepts Claude already knows (Gestalt principles, what easing is, basic UX heuristics like progressive disclosure, forgiveness) and keep only project-specific decisions and constraints.
Move the detailed color theory, typography scales, animation timing, and UX patterns sections into separate reference files (e.g., COLOR-GUIDE.md, TYPOGRAPHY.md, ANIMATION.md) and link to them from the main skill, keeping only the key rules inline.
Add concrete validation commands for the testing workflow—specify exact playwright MCP commands or accessibility checking tools rather than just mentioning them abstractly.
Consolidate the do/don't lists and design checklist into a single concise reference section rather than repeating similar guidance across multiple sections (e.g., 'avoid generic SaaS blue' appears in multiple places).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines. Extensively explains fundamental design concepts Claude already knows (what easing is, what Gestalt principles are, what progressive disclosure means, basic UX heuristics). Massive sections on color theory, typography basics, and animation principles that are general design knowledge, not project-specific guidance. | 1 / 3 |
Actionability | Includes some concrete code examples (button implementation, typography hierarchy, Tailwind classes, framer-motion snippets) which are helpful. However, much of the content is philosophical guidance and abstract principles rather than executable instructions. The code examples that exist are good but represent a small fraction of the overall content. | 2 / 3 |
Workflow Clarity | The Design Workflow section provides a clear 4-step process (Understand → Explore → Implement → Validate), and the examples demonstrate the ask-first protocol well. However, the validation step mentions 'use playwright MCP' without concrete commands, and there are no explicit feedback loops for error recovery when designs fail accessibility checks or visual tests. | 2 / 3 |
Progressive Disclosure | References DESIGN-SYSTEM-TEMPLATE.md and MOTION-SPEC.md for detailed content, which is good progressive disclosure. However, the main file itself is a monolithic wall of text with enormous inline sections (color theory, typography, animation, UX patterns) that should be split into separate reference files rather than included in the primary skill file. | 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (739 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- bencium/bencium-marketplace
- Commit
20077d3
- 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.