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

70%

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 ./skills/emil-design-eng/SKILL.md

Quality

Content

62%

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

Highly actionable content with strong executable examples and a clear decision-framework workflow, but it is a monolithic single-file document with no progressive disclosure and carries some conceptual padding Claude does not need.

Suggestions

Split the body into reference files (e.g., references/animation-decisions.md, references/component-patterns.md, references/gestures.md) and keep SKILL.md as a concise overview that links one level deep, reducing the monolithic wall of text.

Trim the Core Philosophy narrative and Paul Graham quote — these describe taste concepts Claude already understands and pad the token budget without adding executable value.

Move the large Review Checklist and CSS Transform Mastery sections into linked reference files so the main skill surface stays lean.

Dimension	Reasoning	Score
Conciseness	Mostly efficient with copy-paste-ready code, but it carries conceptual padding Claude already knows (the Core Philosophy prose, Paul Graham quote, and 'beauty is leverage' paragraphs) and some re-explained CSS basics, keeping it just below lean.	2 / 3
Actionability	Provides fully executable CSS/JS/JSX snippets, concrete duration/easing tables, and exact values (cubic-bezier curves, scale(0.97), inset clip-path patterns) that are copy-paste ready across animation, components, and gestures.	3 / 3
Workflow Clarity	The Animation Decision Framework is an explicitly ordered multi-step process with a decision table at each step, and the Review Format and Review Checklist give clear sequenced guidance with validation-style checkpoints; simple skills section supports a 3 for clear single-action guidance.	3 / 3
Progressive Disclosure	The body is a 700-line monolithic wall of text with no bundle files (references/scripts/assets are absent) and no one-level-deep references; everything is inline with no navigation pointers to separate materials.	1 / 3
	Total	9 / 12 Passed

Description

77%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A clearly scoped, distinctive description with strong trigger coverage, weakened only by the absence of an explicit 'Use when...' guidance directly in the description text. Specificity and distinctiveness are strong.

Suggestions

Add an explicit 'Use when...' clause to the description (e.g., 'Use when reviewing or building UI animation, component polish, or design-engineering decisions') so the when is stated in-prose, not only in the triggers list.

Lead the description with concrete verbs ('Guides animation, component, and CSS decisions...') rather than the framing 'This skill encodes ... philosophy', which is more of a meta-statement than a capability.

Dimension	Reasoning	Score
Specificity	Names multiple concrete capability areas: UI polish, component design, animation decisions, and the invisible details that make software feel great — a list of specific actions rather than a single vague domain.	3 / 3
Completeness	The description states what the skill does but lacks an explicit 'Use when...' clause describing when to invoke it; the when is only implied via the separate triggers field, which caps completeness at 2 per the rubric guideline.	2 / 3
Trigger Term Quality	The frontmatter triggers array surfaces natural user phrases ('emil kowalski', 'design engineering', 'animation philosophy', 'component design') plus bilingual variants, giving good coverage of terms users would actually say.	3 / 3
Distinctiveness Conflict Risk	It is tied to a specific named author (Emil Kowalski) and a narrow design-engineering niche with distinct triggers, making it unlikely to fire for the wrong skill.	3 / 3
	Total	11 / 12 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 (707 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: nexu-io/open-design
Path: skills/emil-design-eng/SKILL.md
Commit: f2760fd

Reviewed: about 15 hours 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.