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

53%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

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 content is an unusually actionable body of expert guidance — precise values, executable snippets, decision frameworks, and a review checklist — with a clear four-question decision workflow. Its weaknesses are repetition of the same rules across multiple sections and the total absence of progressive disclosure: everything lives inline in one very long SKILL.md instead of being split into reference files. Note that no references/, scripts/, or assets/ directories exist, so all content is in the single file.

Suggestions

Split reference-depth material into one-level-deep bundle files (e.g. references/animation-framework.md, references/css-transforms.md, references/gestures.md), keeping SKILL.md as an overview with clearly signaled links — the ~660-line monolith is the main structural deficit.

Deduplicate the repeated rules: scale(0.97) on :active, popover transform-origin (not modals), and the ease-in warning each appear in prose, the review-format table, and the checklist — state each once in its section and let the checklist reference it.

Trim the motivational philosophy sections ('Taste is trained', 'Beauty is leverage') to one or two sentences; Claude does not need persuasion about taste to apply the concrete rules.

Dimension	Reasoning	Score
Conciseness	The body is dense with genuinely expert, non-obvious guidance (duration tables, cubic-bezier values, the ~0.11 velocity threshold), but the philosophy prose ('Taste is trained, not innate', 'Beauty is leverage') is motivational padding, and key rules repeat three to four times across prose, the review-format table, and the checklist (scale(0.97) on :active, popover transform-origin, the ease-in warning). It fits 'mostly efficient but could be tightened' rather than 4, where only minor trimming would be needed.	3 / 5
Actionability	Nearly everything is copy-paste ready: exact CSS custom properties (cubic-bezier(0.23, 1, 0.32, 1)), Radix/Base UI transform-origin variables, @starting-style and data-mounted patterns, executable JS for velocity-based dismissal, and concrete duration ranges per element type. This matches the top anchor 'fully executable; copy-paste ready code covering the common cases'.	5 / 5
Workflow Clarity	The Animation Decision Framework gives a clearly ordered decision sequence (should this animate at all → purpose → easing → speed) with a frequency table, and the Review Checklist provides a final checkpoint — matching 'clear sequence with most checkpoints present'. It does not reach 5 because there are no explicit feedback-loop or verify steps beyond the checklist, though the destructive/batch cap does not apply since the skill involves no risky operations.	4 / 5
Progressive Disclosure	Section headers and tables make the file navigable, but it is a ~660-line monolith with no bundle files at all; entire sections (CSS Transform Mastery, clip-path, Gesture and Drag Interactions, Sonner Principles) are reference material that clearly belongs in one-level-deep references/ files. This is the anchor 'some structure but content that should be separate is inline'.	3 / 5
	Total	15 / 20 Passed

Description

36%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 its domain and niche authorship well but reads as a content inventory rather than a capability statement. It lacks concrete action verbs and, critically, any 'Use when...' trigger guidance, leaving both completeness and trigger quality well below the good examples. Adding an explicit trigger clause and natural synonyms would fix most of the deficit.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when reviewing or building UI animations, transitions, hover/press states, or when the user mentions animation, motion, easing, or UI polish.'

Replace the passive 'encodes philosophy' framing with concrete third-person actions, e.g. 'Reviews and writes UI animation code: easing curves, durations, transform origins, spring and gesture interactions.'

Include natural trigger synonyms users would actually say — 'animation', 'motion', 'transition', 'easing', 'micro-interactions', 'CSS animation' — to improve both trigger-term coverage and distinctiveness.

Dimension	Reasoning	Score
Specificity	The description names its domains clearly ("UI polish, component design, animation decisions") but contains no concrete actions — "encodes Emil Kowalski's philosophy" describes contents, not what the skill does. It matches the anchor 'Names the domain but actions are minimal or generic' rather than 3, which requires 1-2 concrete actions.	2 / 5
Completeness	The 'what' is vague (what the file contains rather than what it does) and the 'when' is entirely absent — there is no 'Use when...' clause or equivalent trigger guidance, which caps this dimension at 3. Anchor 2 ('Has a vague what and no when') is the best fit.	2 / 5
Trigger Term Quality	It includes some relevant keywords ("UI polish", "component design", "animation decisions") but misses the natural terms users would actually say — "animation", "motion", "transitions", "easing", "micro-interactions", "CSS animation". This fits the 'some relevant keywords but missing common variations or synonyms' anchor.	3 / 5
Distinctiveness Conflict Risk	The niche (Emil Kowalski's UI polish and animation philosophy) is somewhat specific, but without any trigger phrases it could overlap with general frontend/design-system skills. It does not reach anchor 4 ('mostly distinct; minor overlap risk') because nothing signals when to choose it over a sibling design skill.	3 / 5
	Total	10 / 20 Passed

Validation

87%

Warnings & errors only

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

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (661 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
Commit: 8725250

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.