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.

52

Quality

58%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

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
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 an unusually rich, concrete pattern library with exact values and executable code — its main quality risk is volume, not vagueness. Philosophical padding, repetition, and the total absence of progressive disclosure (everything inline in one large file) hold it back from the top band. Splitting reference material into bundle files and trimming the editorial sections would raise both conciseness and structure scores.

Suggestions

Trim the Core Philosophy sections and the repeated scale(0.97)/hold-to-delete guidance to a single canonical statement each; the Review Checklist and Before/After table overlap and could be merged.

Split the pattern-library material (clip-path techniques, gesture/drag handling, debugging methods, Sonner principles) into references/ files with one-level-deep, clearly signaled links from SKILL.md, keeping the decision framework and review format inline.

Add small code snippets for the prose-only patterns (damping at boundaries, friction, pointer capture, tab-duplicate clip transition) to close the actionability gap.

DimensionReasoningScore

Conciseness

The body is dense with genuinely non-obvious specifics (exact cubic-bezier values, duration tables, Radix transform-origin variables, velocity thresholds), but philosophy sections like "Taste is trained, not innate", the Paul Graham quote, and "Beauty is leverage" are padding Claude does not need, and guidance repeats (scale(0.97) on :active appears in four places; the hold-to-delete pattern and its 2s-linear/200ms timing are described twice; the Before/After table and Review Checklist overlap heavily). This matches anchor 3 — mostly efficient with unnecessary material that could be trimmed — rather than 2, because the padding is a minority of the document.

3 / 5

Actionability

Most guidance is executable and copy-paste ready: complete CSS blocks for buttons, tooltips, @starting-style, clip-path, and stagger; JS for velocity-based dismissal and WAAPI; concrete decision tables for frequency, easing, and durations. It falls short of anchor 5 because several patterns — damping at boundaries, friction instead of hard stops, pointer capture, and the tab-duplicate clip technique — are prose direction with no code, and some snippets (e.g. the useSpring example) reference surrounding context that is not shown.

4 / 5

Workflow Clarity

The Animation Decision Framework gives an explicit ordered sequence ("answer these questions in order": animate at all → purpose → easing → duration), the review format is mandated with a required table and a wrong-format counterexample, and debugging guidance (slow-motion, frame-by-frame, real-device testing, next-day review) provides verification checkpoints. Not 5 because the checkpoints are advisory habits rather than explicit validate-fix-retry loops woven into the workflow.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent) and the entire 680-line body is inline in SKILL.md. Section headers are well-organized and easy to navigate, but substantial content that clearly belongs in separate reference files — the clip-path pattern library, gesture/drag handling, the Sonner principles, and the debugging guide — is inlined with no external references at all, matching anchor 3 rather than 4 (which expects most content appropriately split across files).

3 / 5

Total

14

/

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 names a distinctive, well-scoped domain but describes what the skill contains rather than what it does, and provides no 'Use when...' trigger guidance. As a result it would rarely be surfaced by a user's natural phrasing. It is serviceable but below the standard of the rubric's good examples.

Suggestions

Add an explicit trigger clause, e.g. "Use when building or reviewing UI animations, transitions, hover/press states, popovers, or component motion, or when the user mentions easing, micro-interactions, or UI polish."

Replace "encodes Emil Kowalski's philosophy" with concrete third-person actions, e.g. "Reviews and applies UI polish guidance: animation decision framework, easing curves, durations, spring configuration, and component patterns (buttons, popovers, tooltips, toasts)."

Include natural synonyms users would say — motion, easing, CSS transitions, micro-interactions, design engineering — to improve trigger-term coverage.

DimensionReasoningScore

Specificity

Phrases like "UI polish, component design, animation decisions" name specific domain topics, but the only action verb is "encodes Emil Kowalski's philosophy" — no concrete actions the skill performs are stated. It sits between anchor 2 (generic actions) and anchor 3 (domain plus concrete actions): the topical list is informative, but nothing operational like 'reviews UI code' or 'applies easing curves' appears.

3 / 5

Completeness

The 'what' is only loosely stated ("encodes... philosophy on UI polish") and the 'when' is entirely absent — there is no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3 per the rubric guidelines. It is not 2 because the topical scope is stated more clearly than a purely vague 'what'.

3 / 5

Trigger Term Quality

"UI polish", "component design", and "animation decisions" are natural phrases, but common variations users would actually say — "motion", "easing", "CSS transitions", "micro-interactions", "design engineering" — are missing. This matches anchor 3 (relevant keywords present, common synonyms absent) rather than 4, whose coverage is broader.

3 / 5

Distinctiveness Conflict Risk

"UI polish, component design, animation decisions" carves a mostly distinct niche with minor overlap risk only against closely related design/styling skills. It lacks the explicit trigger phrases of anchor 5, so 4 is the best fit.

4 / 5

Total

13

/

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

Warning

Total

15

/

16

Passed

Repository
openstatusHQ/data-table-filters
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.