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

63%

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 highly actionable with concrete, executable examples and a clear decision framework, but it is a long monolithic document padded with philosophy prose and lacks any progressive disclosure into reference files. Trimming the philosophy sections and splitting reference material into bundled files would raise conciseness and progressive disclosure.

Suggestions

Trim the motivational philosophy sections ("Taste is trained, not innate", the Paul Graham quote, "Beauty is leverage", Sonner naming/identity commentary) to keep only the craft guidance, improving token efficiency.

Split the long reference-style material (CSS Transform Mastery, clip-path patterns, Gesture and Drag Interactions) into bundled reference files in references/ and link to them one level deep from SKILL.md.

Add explicit validation/checkpoint language to the review workflow (e.g. 'After applying a fix, re-verify the transition does not animate keyboard-initiated actions') to strengthen workflow clarity.

Dimension	Reasoning	Score
Conciseness	The body is mostly actionable craft knowledge Claude lacks (specific cubic-bezier values, Radix transform-origin variables, the 0.11 velocity threshold), but it carries noticeable philosophy padding ("Taste is trained, not innate", the Paul Graham quote, "Beauty is leverage", Sonner naming commentary) that could be trimmed.	3 / 5
Actionability	It provides extensive copy-paste-ready CSS/JS/JSX examples covering the common cases (button :active scale, popover origins, clip-path reveals, spring config, WAAPI, momentum dismissal), with specific numeric values and library-specific variables.	5 / 5
Workflow Clarity	The Animation Decision Framework is a clearly ordered four-question sequence, the review format is mandatory and explicit, and a Review Checklist closes the skill; this is a guidance/review skill without destructive batch operations, so checkpoints are present with only minor gaps.	4 / 5
Progressive Disclosure	The file is well-sectioned with headers, but at ~680 lines all material is inlined with no bundle files in references/scripts/assets and no one-level-deep reference links, so content that clearly belongs in separate files (CSS transform mastery, clip-path patterns, gesture interactions) is not split out.	3 / 5
	Total	15 / 20 Passed

Description

56%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 uses correct third-person voice and names a clear, distinctive domain, but it is missing explicit trigger guidance and frames its capability abstractly ("encodes philosophy") rather than as concrete actions. Adding a "Use when reviewing UI polish, animation, or component feel" clause would lift the weakest dimensions.

Suggestions

Add an explicit 'Use when ...' clause naming the concrete trigger situations (e.g. reviewing UI animations, improving component polish, choosing easing/duration).

Replace the abstract verb 'encodes ... philosophy' with concrete actions such as 'Reviews UI code for polish, guides animation easing/duration decisions, and applies component design patterns.'

Include a few more natural trigger terms users say, like 'transitions', 'microinteractions', or 'motion design', to broaden keyword coverage.

Dimension	Reasoning	Score
Specificity	The description names the domain ("UI polish, component design, animation decisions, and the invisible details") but the only action verb is "encodes ... philosophy", which is abstract rather than a concrete capability like review, generate, or apply.	2 / 5
Completeness	It clearly states what the skill encodes but provides no "Use when..." trigger guidance, so per the rubric a missing explicit when-clause caps completeness at 3.	3 / 5
Trigger Term Quality	It includes natural phrases users would say ("UI polish", "component design", "animation", "make software feel great") with good keyword coverage, though common synonyms like "transitions" or "microinteractions" are missing.	4 / 5
Distinctiveness Conflict Risk	The niche (UI polish, animation decisions, invisible details) is mostly distinct and unlikely to fire for unrelated skills, with only minor overlap risk against general frontend/design skills.	4 / 5
	Total	13 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (683 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: openstatusHQ/data-table-filters
Path: .agents/skills/emil-design-eng/SKILL.md
Commit: 5017387

Reviewed: 1 day 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.