CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

63

1.20x
Quality

58%

Does it follow best practices?

Impact

93%

1.20x

Average score across 2 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

The canonical home for this skill is emil-design-eng in emilkowalski/skills

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 an exceptionally actionable distillation of design-engineering opinion — concrete values, executable code, decision frameworks, and a review format — but it front-loads philosophical prose and textbook CSS that pads the token budget, and its 675-line monolithic structure ignores progressive disclosure entirely.

Suggestions

Trim the "Core Philosophy" narrative, Paul Graham quote, and "Initial Response" script, and cut textbook CSS explanations (translateY percentages, scale-children behavior, transform-origin basics) that Claude already knows.

Split the file into one-level-deep references (e.g., references/component-patterns.md, references/clip-path-patterns.md, references/debugging.md) and keep SKILL.md as a concise overview with the decision framework and review format.

Add an explicit verification feedback loop to the review workflow (e.g., re-check the fixed properties in the rendered result and confirm durations/origins against the checklist) to lift workflow clarity.

DimensionReasoningScore

Conciseness

Mostly efficient and packed with non-obvious curated guidance (custom cubic-bezier values, duration tables, Framer Motion hardware-acceleration caveat, Sonner principles), but includes unnecessary padding: the "Core Philosophy" prose with a Paul Graham quote, an "Initial Response" persona script, and textbook CSS explanations Claude already knows ("scale() scales children too", translateY percentage semantics, transform-origin basics). It is not a 2 because the majority of the material is genuinely non-generic, opinionated guidance Claude cannot derive on its own.

3 / 5

Actionability

Fully executable copy-paste CSS/JS throughout: exact easing curves (cubic-bezier(0.23, 1, 0.32, 1)), duration tables, a velocity-dismiss formula with threshold 0.11, WAAPI and @starting-style snippets, and a mandated review-output table with both correct and incorrect formats shown. Not below 5 because the specific examples cover the common cases comprehensively.

5 / 5

Workflow Clarity

The Animation Decision Framework is an explicitly ordered four-question sequence with decision tables, followed by a required review format and a closing review checklist — a clear sequence with most checkpoints present. It is not a 5 because there are no error-recovery/feedback-loop steps (e.g., verify on real devices only appears as prose advice), and not a 3 because the decision sequence and checkpoints are explicit, not implicit.

4 / 5

Progressive Disclosure

Section headers are clear and well-ordered, but the skill is a single ~675-line monolithic file with no bundle files; clearly separable material (component patterns, clip-path recipes, debugging procedures, CSS transform reference) is inlined rather than split into one-level-deep reference files. It is not a 2 because the internal structure is strong, not minimal; it is not a 4 because none of the content that should live in separate files is externalized.

3 / 5

Total

15

/

20

Passed

Description

45%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 conveys the skill's topical identity (Emil Kowalski's design-engineering philosophy on UI polish and animation) but never states what the skill actually does or when to invoke it. It reads as a domain statement rather than a capability-plus-trigger description.

Suggestions

Add an explicit trigger clause, e.g. "Use when reviewing or writing UI code involving animations, transitions, hover/press states, or component polish, or when the user mentions easing, micro-interactions, or UI feeling sluggish."

Replace the topic-only framing with concrete actions, e.g. "Reviews UI code for animation/easing/duration issues using a Before/After/Why table, and guides animation, spring, gesture, and transition implementation per Emil Kowalski's design engineering philosophy."

Include natural trigger keywords users would actually say (animations, transitions, easing, micro-interactions, popovers, toasts, feels sluggish/janky) to reduce overlap risk with general design or styling skills.

DimensionReasoningScore

Specificity

The description names the domain ("UI polish, component design, animation decisions, and the invisible details") but lists no concrete actions — "encodes Emil Kowalski's philosophy" describes subject matter rather than anything the skill does, matching the anchor 'Names the domain but actions are minimal or generic'. It is not a 3 because there are no 1-2 concrete actions stated, only topics.

2 / 5

Completeness

There is a 'what' (the domain the skill covers) but no 'when' clause at all — no "Use when..." or equivalent trigger guidance, which caps completeness at 3. It is not a 2 because the 'what' is stated concretely enough (four named topic areas) rather than being extremely vague.

3 / 5

Trigger Term Quality

"UI polish", "component design", and "animation decisions" are relevant keywords a user might say, but common natural variations and synonyms (micro-interactions, transitions, easing, CSS animation, hover states) are missing. Not a 4 because the coverage is topic-level, not the good keyword coverage of anchor 4.

3 / 5

Distinctiveness Conflict Risk

"UI polish" and "component design" are somewhat specific but could still overlap with other design, styling, or frontend-related skills, and there are no distinct trigger phrases to disambiguate. Not a 4 because nothing in the description minimizes overlap risk with closely related skills.

3 / 5

Total

11

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

skill_md_line_count

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

Warning

Total

15

/

16

Passed

Repository
stevenknowswhy/ProfessionalBuyer
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.