CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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.

1.07x
Quality

62%

Does it follow best practices?

Impact

100%

1.07x

2 of 3 eval scenarios. Add 1 more for a full score.

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/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

63%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 exceptionally actionable — concrete values, executable code, and a required output format leave no ambiguity about what to do. Its weaknesses are length and structure: it re-explains CSS basics Claude already knows and packs 670 lines into one file instead of splitting reference material into bundle files.

Suggestions

Move reference-depth material (clip-path patterns, spring configuration, CSS transform mastery, Motion version caveats, debugging techniques) into references/ files and keep SKILL.md as the decision framework plus review format.

Cut explanations of CSS fundamentals (translateY percentages, transform-origin default, scale affecting children) down to the non-obvious guidance only.

Trim philosophical prose sections to one or two lines each so the actionable rules dominate the token budget.

DimensionReasoningScore

Conciseness

At ~670 lines the body explains CSS fundamentals Claude already knows ("Percentage values in translate() are relative to the element's own size", "scale() also scales children", transform-origin defaults, what clip-path is) and pads with philosophical prose. Several sections could be cut or tightened without losing guidance value.

2 / 5

Actionability

The guidance is fully executable throughout: duration tables (100-160ms for button press), exact cubic-bezier curves, a velocity threshold of 0.11 for dismissal, copy-paste CSS/JS/JSX blocks, and a mandated Before/After/Why review table format. Specific examples cover the common cases comprehensively.

5 / 5

Workflow Clarity

The Animation Decision Framework provides a clear ordered sequence (should this animate → purpose → easing → duration) and the Review Checklist plus debugging sections give followable procedures. Checkpoints are implicit rather than explicit validate-fix-retry loops, keeping it just below the top anchor.

4 / 5

Progressive Disclosure

The body is well-sectioned with clear headers, but it is a monolithic single file with no bundle: reference-worthy material (clip-path patterns, spring configuration, Motion version caveats, debugging techniques) is all inlined in SKILL.md. Structure exists, but content that should live in separate reference files is inline.

3 / 5

Total

14

/

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 names a clear niche and a distinctive source (Emil Kowalski's design engineering philosophy) but never states concrete capabilities or when to invoke the skill. Adding an explicit "Use when..." trigger clause and concrete actions (e.g., reviewing UI code, choosing animation timing/easing) would materially improve it.

Suggestions

Add an explicit trigger clause, e.g. "Use when reviewing or writing UI code involving animations, transitions, or component polish, or when the user mentions motion, easing, or microinteractions."

Replace topic nouns with concrete actions: "Reviews UI code for animation and polish issues, recommends easing curves, durations, and transform patterns" rather than "encodes... philosophy on".

Include common synonyms users would naturally say (transitions, motion, microinteractions, easing, springs) to improve trigger-term coverage.

DimensionReasoningScore

Specificity

"encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions" names the domain and several topics but describes no concrete actions the skill performs. It matches the anchor for naming the domain with minimal/generic actions rather than listing 1-2 concrete capabilities.

2 / 5

Completeness

The "what" is present but soft ("encodes... philosophy... invisible details") and there is no "when"/"Use when..." clause anywhere. Per the judging guidelines, a missing explicit trigger clause caps completeness at 3.

3 / 5

Trigger Term Quality

"UI polish", "component design", and "animation decisions" are natural terms a user might say, but common variations like "transitions", "motion", "microinteractions", or "easing" are missing. This is some relevant keyword coverage without synonyms.

3 / 5

Distinctiveness Conflict Risk

The Emil Kowalski anchor gives it a distinct identity, but the domain (UI polish, animation, component design) broadly overlaps with general design and front-end skills. Somewhat specific, but overlap risk with similar skills remains.

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 (677 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository

englishstreetventures/osn

Path

.agents/skills/emil-design-eng/SKILL.md

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.