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

62%

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.

This is a rich, highly actionable reference for UI animation and component polish, carried by concrete code and decision frameworks. Its main weaknesses are philosophical/heroic padding and repetition that hurt conciseness, and a monolithic structure with no progressive disclosure into separate reference files.

Suggestions

Trim the philosophical preamble and de-duplicate repeated points (press feedback, ease-in vs ease-out) and the review checklist that restates the review table, to improve conciseness.

Split deep reference material (e.g. 'CSS Transform Mastery', 'clip-path for Animation', 'Gesture and Drag Interactions') into separate files under references/ and link to them from SKILL.md so the main file stays an overview.

Add an explicit 'when NOT to use this skill' or scope note so Claude can disambiguate it from generic frontend/design guidance.

Dimension	Reasoning	Score
Conciseness	The bulk is dense, useful craft knowledge (easing curves, transform-origin rules, clip-path patterns, performance rules), but the philosophical preamble ('Taste is trained, not innate', the Paul Graham quote, 'Beauty is leverage') and repetition of the same points (scale(0.97) press feedback and ease-in-vs-ease-out are explained multiple times, and the review checklist duplicates the review table) could be tightened.	3 / 5
Actionability	Provides extensive copy-paste-ready CSS/JS/JSX with specific values (durations, cubic-bezier curves, scale factors) and decision tables that cover the common animation/component cases, fully executable.	5 / 5
Workflow Clarity	The Animation Decision Framework is a clear numbered sequence (should it animate? purpose? easing? duration?) and the Debugging/Review Checklist sections serve as verification checkpoints, but it is not a destructive/batch workflow so the validate-fix-retry loop is only implicitly present.	4 / 5
Progressive Disclosure	The file is well-organized with clear section headers, but it is a single ~660-line monolith with no bundle files or external references, and substantial reference-style content (CSS Transform Mastery, clip-path patterns, Gesture interactions) that could live in separate files is inlined; the under-50-line simple-skill exception does not apply.	3 / 5
	Total	15 / 20 Passed

Description

53%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 clearly scopes the skill to UI polish and animation craft via a named author's philosophy, but it reads as a topic statement rather than a trigger-equipped skill description. It lacks an explicit 'Use when' clause and concrete action verbs, which cap specificity and completeness.

Suggestions

Add an explicit trigger clause, e.g. 'Use when polishing UI, designing component animations, reviewing motion/interaction details, or deciding whether and how to animate.'

Replace the abstract 'encodes philosophy' with concrete actions the skill performs, e.g. 'Reviews UI code for animation polish, recommends easing/duration/transform-origin fixes, and decides when to animate.'

Include natural user-facing synonyms such as 'micro-interactions', 'transitions', and 'feel' to broaden trigger-term coverage.

Dimension	Reasoning	Score
Specificity	Names the domain and several sub-domains ('UI polish, component design, animation decisions, and the invisible details') but uses the abstract action 'encodes philosophy' rather than concrete verbs like build/review/animate, so it lists topics not executable actions.	3 / 5
Completeness	Gives a clear 'what' (encodes a philosophy across several UI/animation areas) but provides no 'when should Claude use it' trigger guidance; per the rubric, a missing 'Use when' clause caps completeness at 3.	3 / 5
Trigger Term Quality	Includes relevant keywords ('UI polish', 'component design', 'animation') a user might say, but misses common variations and natural trigger phrases like 'make this feel better' or 'polish my UI', and there is no explicit 'Use when' guidance.	3 / 5
Distinctiveness Conflict Risk	The named persona ('Emil Kowalski's philosophy') plus the narrow animation/polish niche make it mostly distinct from general frontend skills, with only minor overlap risk; it is not a 5 because no explicit triggers are given.	4 / 5
	Total	13 / 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: 7945b29

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.