CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

emil-design-eng

This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/emil-design-eng/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a rich, highly actionable reference with concrete values, decision frameworks, and executable code covering animation, components, gestures, performance, and accessibility. Its weaknesses are length and redundancy — motivational sections, CSS-basic explanations, and duplicated checklists — plus the absence of any progressive disclosure: all advanced material is inlined in a single large file.

Suggestions

Trim the Core Philosophy motivational prose and the CSS-basic explanations (percentage translate, scale of children, transform-origin default) that Claude already knows.

Consolidate the Review Format example table and the Review Checklist into a single section to remove duplication.

Split advanced material (clip-path patterns, gesture/drag interactions, Sonner principles) into one-level-deep reference files under references/ and link them from a concise overview.

DimensionReasoningScore

Conciseness

Most sections deliver dense, specific values Claude cannot derive on its own, but the file carries motivational padding ("Taste is trained, not innate", "Beauty is leverage"), explanations of CSS basics Claude already knows ("Percentage values in translate() are relative to the element's own size", "scale() also scales an element's children", transform-origin defaults), and repetition (the Review Format table vs. the Review Checklist table; perceived-performance points restated across sections). This places it at anchor 3 — mostly efficient but with unnecessary explanation that could be trimmed — rather than 4, where only minor instances would exist.

3 / 5

Actionability

Guidance is fully executable: exact cubic-bezier curves, duration tables per element type, a concrete velocity threshold (0.11) with working JS, copy-paste CSS/JSX for press states, tooltips, @starting-style, clip-path, and WAAPI, plus named library CSS variables (--radix-popover-content-transform-origin). Specific examples cover the common cases, matching anchor 5.

5 / 5

Workflow Clarity

The Animation Decision Framework provides a clearly ordered four-question sequence with decision tables, and the Review Checklist plus debugging sections (slow-motion testing, frame-by-frame inspection) serve as verification steps. It is not a destructive or batch operation, so the validation cap does not apply, but validation checkpoints are implicit rather than the explicit validate-fix-retry loops of anchor 5.

4 / 5

Progressive Disclosure

There are no bundle files (references/, scripts/, assets/ are absent) and no external references in the body; everything sits in one ~660-line SKILL.md. Section headers and tables give it real structure, but clearly separable material — clip-path patterns, gesture/drag handling, the Sonner principles — is inlined rather than split into one-level-deep reference files, matching anchor 3's "content that should be separate is inline" rather than anchor 2's structureless wall of text.

3 / 5

Total

15

/

20

Passed

Description

48%Weight 40%Scale 1-5

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 identifies a distinct niche (Emil Kowalski's design-engineering philosophy, UI polish, animation) but describes no concrete actions and entirely lacks a "Use when..." trigger clause. It reads more like a source attribution than a capability statement, which limits discoverability and completeness.

Suggestions

Add an explicit trigger clause, e.g. "Use when building or reviewing UI animations, transitions, hover/press states, or component polish in frontend code."

Replace the abstract "encodes ... philosophy" framing with concrete actions such as "Guides animation and UI-polish decisions: easing curves, durations, press/hover states, popover origins, and drag gestures".

Include natural trigger synonyms users would say — "animation", "motion", "micro-interactions", "transitions", "CSS animations" — to broaden keyword coverage.

DimensionReasoningScore

Specificity

The description names its domains ("UI polish, component design, animation decisions, and the invisible details") but the only action verb is "encodes ... philosophy", which is generic; no concrete actions like reviewing UI code or building animations are stated. It is above anchor 1 (not entirely vague — the domain is clear) but matches anchor 2's minimal/generic action coverage.

2 / 5

Completeness

The "what" is reasonably clear (a knowledge base of design/animation philosophy), but there is no "when" — no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. It is not a 4 because the when-clause is entirely absent rather than merely imprecise.

3 / 5

Trigger Term Quality

Terms like "UI polish", "animation decisions", and "component design" are phrases users might say, but common variations such as "motion", "micro-interactions", "transitions", or "CSS animations" are missing. There is relevant keyword coverage but not the synonym breadth of anchor 4 or 5.

3 / 5

Distinctiveness Conflict Risk

Attribution to "Emil Kowalski's philosophy" and the animation-polish focus form a fairly distinct niche with clear triggers, with only minor overlap risk against general design-system or styling skills. It falls short of anchor 5 because the missing trigger clause leaves overlap with other UI/design skills more likely than in the exemplar.

4 / 5

Total

12

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (663 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

14

/

16

Passed

Repository

simstudioai/sim

Path

.agents/skills/emil-design-eng/SKILL.md

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.