Skills Design

Makes the agent create real visual art: it starts from an aesthetic philosophy and expresses it in a graphic piece exported as PNG or PDF.

When to use it

When you need a finished, static visual — a poster, a cover, an illustration — with an aesthetic point of view, not a template.

When to avoid it

It doesn't build interfaces or components and doesn't copy an artist's or brand's style: it only generates original PNG/PDF files, not editable design files.

A command from the impeccable skill: turns down the volume of an interface that's too aggressive or overstimulating, without draining its impact.

When to use it

When a screen is “shouting” — too many accents, colors and shadows competing — and you can't tell where to look first anymore.

When to avoid it

If the problem is too much stuff (extra fields and options), use distill; if you want a judgment rather than a change, use critique.

A command from the impeccable skill: removes fields, steps and options until only the essentials for completing the action remain.

When to use it

When a form or panel has grown by accumulation and nobody has ever removed anything.

When to avoid it

If the interface is already minimal but “shouts” visually, the problem is volume, not structure: use quieter.

A command from the impeccable skill: runs a UX review across multiple criteria, assigns a score and returns findings with the action to take.

When to use it

Before a human review, to get there with the obvious problems already found and ranked by severity.

When to avoid it

It doesn't touch the code: if you also want the problems fixed, move to polish or distill after the critique.

A command from the impeccable skill: the last pass over the details — alignments, radii, focus, digits that don't jump — before you ship.

When to use it

When the design is settled and works, and only the final finishing pass remains before shipping.

When to avoid it

It's not a redesign: if the layout itself is wrong, fix the structure (distill) or the volume (quieter) first, then polish.

<button
  class="h-8 text-[#9aa0aa]"
  onclick="salva()">
  Salva
</button>

Checks your interface code against Vercel's Web Interface Guidelines and flags violations in file:line format.

When to use it

When you want to know whether what you built passes a compliance and accessibility check, before a user finds out the hard way.

When to avoid it

It doesn't redesign or fix anything: it only reads and reports. For measuring real browser performance you need something else (Lighthouse, Core Web Vitals).

The routing layer of ibelick's UI collection: it understands the goal and loads the smallest, most targeted skill instead of a generic one.

When to use it

At the start of a UI task, when you have a clear goal but don't know which specific rule you need.

When to avoid it

For a non-UI task it just answers “no skill needed”; and if you already know exactly which skill you want, skip it and install that one directly.

Emil Kowalski’s design engineering philosophy (creator of Sonner and Vaul): how polish, components and motion add up to a UI that “feels right”.

When to use it

When you want to train the agent's taste on invisible details and get components that hold up against the best.

When to avoid it

It's broad and philosophical: for a hard rule on a specific detail (radii, alignment, shadows), make-interfaces-feel-better is more direct; to review only animations, use review-animations.

The concrete rules that make a UI feel polished: concentric radius, optical alignment, shadows instead of borders, interruptible animations, tabular figures.

When to use it

When the interface is right but “feels like a prototype” and you want a precise checklist of details to fix.

When to avoid it

If you're after the why and the taste behind the choices rather than the list of rules, go with emil-design-eng.

152 UI/UX rules across 12 categories — animation, timing, exits, audio, UX laws, typography — ranked by impact, with findings in file:line format.

When to use it

When you want a broad, reasoned review against rules — including motion, audio and cognitive laws — not just accessibility.

When to avoid it

It's a review rulebook, not a builder: for design and a11y compliance on code alone, web-design-guidelines is more targeted.

Builds color systems in OKLCH: conversion from hex/rgb/hsl, scales and palettes, APCA/WCAG contrast, gamut and Tailwind v4 theming.

When to use it

When you're building a design system's color scale and the steps look uneven, or a contrast check fails and you don't know how much to raise it.

When to avoid it

It only does color: for spacing, typography or layout you need a different skill.

Looks at a public site and extracts its primitives — colors, fonts, spacing, radii, shadows — generating starting token files for your project.

When to use it

When you're starting from a visual reference and want to translate its rules into variables instead of eyeballing them.

When to avoid it

It's a starting point, not a copy: the docs themselves say it's not pixel-perfect reproduction, it doesn't derive a component library, and a single page isn't an entire design system.

Translates Apple's approach to fluid motion for the web: interruptible springs, 1:1 gesture tracking, momentum, translucent materials, reduced-motion.

When to use it

When you're building gesture-driven interactions (drag, swipe, sheet) and want them to start from the on-screen value and stay grabbable mid-motion.

When to avoid it

For a simple, non-gestural transition a spring is often overkill, and it's not a static-graphics tool. To review animations already written, use review-animations.

A reverse-lookup glossary: from a vague description of a movement (“the thing that bounces when it opens”) it gives you the exact term.

When to use it

When you know which effect you want but not what it's called, and without the right name the agent gives you something else.

When to avoid it

It's for naming, not for building or designing: to create the motion use apple-design, to review it use review-animations.

Reviews animation code against a high quality bar (Emil Kowalski's philosophy): approval has to be earned, by default it flags.

When to use it

After you’ve had something animated, when you’re “almost there” and want to know what’s off: durations, curves, origin, dropped frames.

When to avoid it

That's all it does: it rejects non-motion code and doesn't write features. To build the motion use apple-design, to name it animation-vocabulary.