This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.
65
49%
Does it follow best practices?
Impact
90%
1.42xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/emil-design-eng/SKILL.mdQuality
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 abstract and philosophical, focusing on what the skill 'encodes' rather than concrete actions Claude can perform. It lacks explicit trigger guidance and actionable capabilities, making it difficult for Claude to know when to select this skill from a pool of options.
Suggestions
Add a 'Use when...' clause with specific triggers like 'Use when the user asks about micro-interactions, button animations, hover states, or making UI feel polished'
Replace abstract language with concrete actions such as 'Applies subtle animations to buttons, refines hover states, adds micro-interactions, improves transition timing'
Include natural user phrases like 'make it feel smooth', 'add polish', 'improve animations', 'micro-interactions' that would trigger skill selection
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses abstract language like 'philosophy', 'polish', and 'invisible details' without listing any concrete actions. It describes what the skill 'encodes' rather than what it does. | 1 / 3 |
Completeness | The description only vaguely addresses 'what' (encodes a philosophy) and completely lacks any 'when' guidance or explicit triggers for when Claude should use this skill. | 1 / 3 |
Trigger Term Quality | Contains some relevant terms like 'UI polish', 'component design', and 'animation' that users might mention, but lacks common variations and natural phrases users would actually say when needing this skill. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'Emil Kowalski's philosophy' provides some distinctiveness, but 'UI polish' and 'component design' are broad enough to potentially overlap with other UI/design skills. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality, highly actionable skill with excellent concrete guidance, executable code examples, and clear decision frameworks. The main weakness is its length—it's a comprehensive reference document that could benefit from splitting into overview + detailed reference files. Some explanatory content about why things work could be trimmed to respect Claude's existing knowledge.
Suggestions
Split into SKILL.md overview + separate reference files (e.g., ANIMATION-FRAMEWORK.md, COMPONENT-PATTERNS.md, PERFORMANCE.md) with clear navigation links
Trim explanatory passages like 'Why blur works' and 'Springs feel more natural because they simulate real physics' that explain concepts rather than instruct
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but includes some explanatory content Claude likely knows (e.g., explaining what springs are, why blur works visually). Some sections could be tightened, though most content earns its place with specific, actionable guidance. | 2 / 3 |
Actionability | Excellent actionability with fully executable CSS and JavaScript code examples throughout. Copy-paste ready snippets for buttons, tooltips, popovers, drag interactions, and more. Specific values provided (e.g., 'scale(0.97)', '150-250ms', 'cubic-bezier(0.23, 1, 0.32, 1)'). | 3 / 3 |
Workflow Clarity | The Animation Decision Framework provides a clear sequential process (should it animate → purpose → easing → speed). Review checklist with Before/After/Why table format is explicit. Decision tables throughout guide choices systematically. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear headers and logical sections, but it's a monolithic document (~500+ lines) with no references to external files. Some sections (like the full Sonner Principles) could be split into separate reference documents for better navigation. | 2 / 3 |
Total | 10 / 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 (680 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
ecf66bb
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.