Skills de Emil Kowalski: tu agente anima con criterio

Le pides a tu agente un menú desplegable y te lo entrega en un minuto. Compila, se abre, se cierra. Pero algo chirría y no sabes qué.

Abre con ease-in. Crece desde el centro en vez de desde el botón. Tarda 400 ms. Y cuando lo abres con el teclado, también anima, las cien veces que lo abras hoy.

Ninguno de esos fallos rompe nada. Todos juntos hacen que la interfaz se sienta lenta, torpe, hecha por una IA.

Emil Kowalski lleva años cazando esos detalles. Es el autor de Sonner (la librería de toasts que usa medio ecosistema React) y de Vaul (el drawer), y ha trabajado en Vercel y Linear. Este año ha volcado su criterio en un repositorio de 16 agent skills para diseñadores e ingenieros. Lo he destripado entero y, además, he hecho un experimento: la misma interfaz construida por dos agentes, uno con su skill principal y otro sin ella, medida frame a frame.

En este artículo vas a ver:

• Qué hay dentro del repo emilkowalski/skills y cómo se reparte el trabajo entre sus 16 skills
• La skill madre, emil-design-eng, desmontada pieza a pieza: tablas, curvas, duraciones y reglas
• Los patrones de escritura de skills que puedes copiar para las tuyas
• El experimento con capturas, filmstrip y medición con getAnimations(), bugs incluidos (también los de la versión con skill)
• Cuándo merece la pena instalarlas y cuándo no

¿Qué son las skills de Emil Kowalski? ¶

Son 16 agent skills en formato SKILL.md que meten en tu agente el criterio de un design engineer: cuándo animar, cómo animar y cuándo no animar. Funcionan en Claude Code, Codex, Cursor y cualquier agente que lea el estándar de skills.

El repositorio arrancó el 16 de marzo de 2026 y a finales de octubre suma 58 commits; el último, del 28 de octubre, añade remove-animations. Entre las 16 skills y sus ficheros de apoyo hay unas 5.100 líneas de markdown. No es un prompt con cuatro consejos: es un manual.

El README lo deja claro desde la primera línea útil:

“Agents don’t have great taste.”

Y pone dos ejemplos que vas a ver repetidos en todo el repo: el agente elige ease-in para una animación de entrada cuando toca ease-out, o pone un borde sólido donde iría una sombra semitransparente. Detalles pequeños que, sumados, separan una interfaz buena de una que “funciona”.

El párrafo de en medio es el que más me gusta. Emil dice que estas skills son un efecto secundario de tener experiencia en un dominio, y que la IA no sustituye esa experiencia: la amplifica. Su consejo final no es “instala esto”, es “aprende a programar, a diseñar o lo que sea, porque eso es lo valioso”.

Viniendo de alguien cuya librería de toasts tiene 47,4 millones de descargas semanales en npm (semana del 21 al 27 de octubre de 2026, según la API pública de npm), el consejo pesa.

Curso gratis por email

Antes de instalar las 16, aprende cómo funciona una skill por dentro

Un minicurso por email, a tu ritmo, para instalar skills en tu agente y crear la tuya. Justo lo que hizo Emil: convertir su criterio en un SKILL.md.

Apúntate al minicurso →

¿Cómo se instalan las skills de emilkowalski/skills? ¶

Con el CLI de skills.sh, en una línea:

# Instala la colección completa en tu proyecto
npx skills@latest add emilkowalski/skills

Si solo quieres una o dos, copia su carpeta de skills/ a la ruta de skills de tu agente (.claude/skills/ en Claude Code). Cada skill es autocontenida: su SKILL.md y, en algunos casos, un fichero de apoyo al lado (RECIPES.md, STANDARDS.md, CATALOG.md, PICKER.md…).

⚠️ Tres de las 16 llevan disable-model-invocation: true en el frontmatter: review-animations, prototype y pick-ui-library. El agente nunca las carga por su cuenta. Las invocas tú, con su nombre. Tiene sentido: una revisión que bloquea por defecto o un generador de variantes no deberían saltar sin que los pidas.

Este es el mapa completo, agrupado por lo que hace cada una:

Si es la primera vez que instalas skills, en la diferencia entre agent skills, prompts y MCP tienes el contexto de cómo las carga el agente.

¿Qué tiene dentro emil-design-eng, la skill principal? ¶

emil-design-eng es la skill madre: 674 líneas con la filosofía de Emil y casi todas las reglas que el resto de skills reutiliza. Si solo instalas una, es esta.

Arranca con tres ideas que marcan el tono de todo lo demás:

1. El gusto se entrena, no se trae de serie. Es un instinto que se educa mirando buen trabajo y preguntándote por qué funciona.
2. Los detalles que nadie ve se acumulan. El usuario no nota que el popover sale del botón. Nota que la app “se siente bien” y no sabe explicar por qué.
3. La belleza es palanca. Cuando todo el software es “suficientemente bueno”, el acabado es lo que te diferencia.

Hasta aquí, filosofía. Lo que la hace útil para un agente viene después: tablas, umbrales y valores exactos. Un modelo no sabe qué hacer con “que se sienta fluido”; sí sabe qué hacer con “dropdown entre 150 y 250 ms”.

El formato de revisión es obligatorio ¶

Una de las primeras secciones obliga al agente a revisar UI con una tabla Before | After | Why. Nada de listas con “Antes:” y “Después:” en líneas sueltas. Incluso muestra el formato incorrecto para que el modelo no tenga dudas.

Parece un detalle menor y no lo es. Una tabla fuerza al agente a dar el valor concreto de antes, el valor concreto de después y el motivo. Una lista le deja escaquearse con “mejora la transición”.

El marco de decisión: cuatro preguntas antes de animar ¶

El corazón de la skill es un marco de decisión que el agente tiene que recorrer en orden antes de escribir una línea de animación:

La primera pregunta es la que más trabaja. La skill clasifica cada animación por cuántas veces al día la verá el usuario:

El ejemplo que repite en varias skills es Raycast: no anima su apertura, y eso es lo correcto para algo que abres cientos de veces al día.

La segunda pregunta es el propósito. Vale feedback, consistencia espacial, indicar un cambio de estado, explicar algo o evitar un salto brusco. “Queda chulo” no vale si el usuario lo va a ver a menudo.

Curvas y duraciones con números ¶

La skill no se queda en “usa ease-out”. Dice que las curvas que trae CSS son demasiado flojas y da tres concretas:

/* Ease-out fuerte para interacciones de UI */
--ease-out: cubic-bezier(0.23, 1, 0.32, 1);

/* Ease-in-out fuerte para movimiento en pantalla */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);

/* Curva tipo iOS para drawers (de Ionic) */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);

Y una regla que repite como un mantra: nunca ease-in en UI. Arranca lento justo en el momento en que el usuario está mirando. Un dropdown con ease-in a 300 ms se siente más lento que uno con ease-out a 300 ms, aunque duren lo mismo.

Las duraciones también vienen tabuladas: feedback de botón entre 100 y 160 ms, tooltips entre 125 y 200, dropdowns entre 150 y 250, modales y drawers entre 200 y 500. Y un techo general: la UI se queda por debajo de 300 ms.

Los componentes, uno a uno ¶

Luego baja a recetas concretas. Las que más se repiten en el resto del repo:

• Botones con scale(0.97) en :active. Feedback instantáneo al pulsar. La escala entre 0.95 y 0.98, nunca más agresiva.
• Nunca animar desde scale(0). Nada en el mundo real aparece de la nada. Empieza en scale(0.95) con opacity: 0.
• Popovers que salen de su botón. transform-origin en el disparador, no en el centro. Con la excepción explícita de los modales, que no están anclados a nada.
• Tooltips sin retardo en el segundo. El primero espera; si ya hay uno abierto, los vecinos se abren al instante y sin animación.
• Transiciones en vez de keyframes para todo lo que se puede disparar rápido (toasts, toggles), porque una transición se reorienta desde donde está y un keyframe vuelve a empezar de cero.
• Un blur(2px) para disimular un crossfade que no termina de convencer: mezcla los dos estados y el ojo ve una sola transformación.

Hay también una sección entera sobre clip-path como herramienta de animación (pestañas con transición de color perfecta, botón de mantener para borrar, sliders de comparación) y otra de gestos: descartar un drawer por velocidad y no por distancia, con un umbral de 0,11 px/ms sacado de Sonner.

Rendimiento y accesibilidad ¶

Dos reglas de rendimiento que pocos agentes conocen:

1. Las variables CSS se heredan. Si actualizas --swipe-amount en el contenedor de un drawer con muchos hijos, recalculas estilos de todos ellos en cada frame. Mejor escribir el transform directo en el elemento.
2. Los atajos x, y y scale de Motion (antes Framer Motion) no van acelerados por hardware. Usan requestAnimationFrame en el hilo principal. Si quieres que no pierda frames mientras la página carga, anima el string completo: transform: "translateX(100px)".

En accesibilidad, la skill insiste en algo que suele hacerse mal: prefers-reduced-motion significa menos movimiento, no cero. Mantén los fundidos de opacidad que ayudan a entender qué pasa y quita los desplazamientos. Y los hover, detrás de @media (hover: hover) and (pointer: fine), porque en táctil un toque dispara un hover falso.

Cierra con los “principios de Sonner” (buena experiencia de desarrollo, buenos valores por defecto, nombres con identidad, casos raros resueltos sin que se note) y una tabla de revisión que es, en la práctica, la lista de errores que vas a ver en el experimento.

¿Cómo se reparten el trabajo las otras 15 skills? ¶

Cada skill hace una sola cosa y lo dice en su primer párrafo, con la lista de lo que no hace y a qué otra skill tienes que ir para eso. Gracias a eso, 16 skills conviven en tu agente sin pisarse.

Construir: animate y animate-expo ¶

animate construye una animación desde cero siguiendo una secuencia de siete pasos: si debe animarse, con qué propósito, con qué herramienta, qué propiedades, qué curva o muelle, cómo se interrumpe y cómo se gestiona el movimiento reducido. Sus reglas duras son muy claras:

• Nada de valores aproximados. Si la curva no está en sus tablas, se saca de easing.dev o easings.co. Nunca un cubic-bezier(0.4, 0, 0.2, 1) “porque suena”.
• La herramienta más barata que funcione. Transición CSS, luego @starting-style, luego animación CSS, luego WAAPI, y solo al final Motion. No instales una librería para un fade.
• Extiende los tokens del proyecto, no crees otros. Si ya hay un --ease-out, se usa ese.

Su primer modo de fallo, el peor, es animar algo que no debería animarse. A veces el resultado correcto de la skill es cero líneas de código.

animate-expo aplica el mismo listón a React Native y Expo, con Reanimated, Gesture Handler y expo-haptics. Añade lo que la web no tiene: mantener la animación fuera del hilo de JS, pulsación en vez de hover y háptica.

Revisar: review-animations, improve-animations y animation-performance ¶

review-animations es la más dura del repo. Su descripción lo dice todo: “Default to flagging; approval is earned”. Revisa un diff contra diez estándares no negociables (movimiento justificado, adecuado a la frecuencia, curva que responde, menos de 300 ms, origen correcto, interrumpible, solo propiedades de GPU, accesible, entrada y salida asimétricas y coherencia) y termina siempre con una decisión explícita: Block o Approve.

Lo más interesante es su jerarquía de remedios. La primera opción siempre es borrar la animación; la segunda, reducirla; y solo después vienen arreglar la curva, el origen o el rendimiento.

improve-animations hace lo mismo a escala de repositorio, pero con un giro que me encanta: no toca el código. Audita, prioriza y escribe planes en plans/ tan autocontenidos que los pueda ejecutar un modelo más barato sin contexto y “sin gusto propio”. El modelo caro pone el criterio; el barato pone las manos.

animation-performance va a por las animaciones que pierden frames. Su sección “Two traps that look correct” explica dos casos que usan transform y aun así van a tirones: la variable CSS heredada (le pasó a Vaul con drawers de más de unos 20 elementos) y el blur(), caro sobre todo en Safari. Sobre will-change, el consejo es ponerlo solo cuando veas el salto de un píxel o midas frames perdidos, nunca de forma preventiva.

Sumar y restar: find-animation-opportunities y remove-animations ¶

Esta pareja es mi parte favorita del repo, porque son espejo una de la otra.

find-animation-opportunities busca sitios donde falta movimiento, pero su postura de partida es la contención. Cita el artículo de Emil “You Don’t Need Animations” y avisa de que un buscador de oportunidades que sugiere animaciones en todas partes “es peor que inútil”. Limita la salida a 5–7 sugerencias por app y obliga a una sección de candidatos rechazados, con la pregunta que los tumbó.

remove-animations invierte la carga de la prueba: cada animación existente va a juicio y se queda solo si se defiende. Lo mejor es su lista de riesgos al borrar, que es pura experiencia:

• Estados iniciales ocultos: si borras la animación pero no el opacity: 0 de partida, el elemento se queda invisible para siempre.
• Código que espera a la animación: transitionend, onExitComplete o setTimeout calculados con la duración.
• Animaciones de layout que tapan un salto: quitas el layout de Motion y aparece el brinco que escondía.

También obliga a una sección de animaciones que se quedan, con el motivo que las salvó. Su argumento: es lo que la separa de borrar todas las transiciones del código.

Romper y prototipar: break-ui y prototype ¶

break-ui es la skill adversaria. Su postura arranca con un personaje: eres Aleksandra Wiśniewska-Kowalczyk, tu compañero tiene el email bartholomew.fitzgerald@northwind-industries-holdings.example.com, tu becario se llama Jo y tu espacio de trabajo tiene 1.284 miembros. Ninguno es inventado, todos existen en producción en algún sitio.

La skill mete esos datos del peor caso en tu componente, los pone detrás de un interruptor “Demo data / Worst case” y te devuelve una tabla con lo que se rompió y su arreglo (flex-shrink: 0 para el avatar aplastado, min-width: 0 para el texto que se desborda, Intl.PluralRules para el “1 members”). Con una regla que deberías tatuarte: los datos absurdos no prueban nada. Un nombre de 5.000 “a” no convence a nadie; uno real y largo, sí.

prototype genera de 3 a 5 versiones distintas de verdad de una pieza y las pone tras un selector flotante. Cada variante tiene que divergir en un eje con nombre (layout, densidad, personalidad, movimiento, modelo de interacción). Si dos solo cambian el color de acento, son la misma y hay que tirar una. El selector viene especificado al píxel en PICKER.md y la skill ordena copiarlo tal cual: es “chrome, no un concursante”.

El resto: librerías, móvil, Apple, vocabulario, Sonner y Swift ¶

• pick-ui-library: una lista cerrada y opinada. base-ui para primitivas accesibles, cmdk para paletas de comandos, Sonner para toasts, Motion para animación general, NumberFlow para números animados, Virtuoso para listas largas, dnd kit para arrastrar, zustand para estado, clsx y cva para clases. Si la tarea no está en la lista, el agente tiene que decir que se sale de ella.
• mobile-native: once síntomas con su arreglo para que una web se sienta app en el móvil. 100dvh en vez de 100vh, inputs a 16 px como mínimo para que iOS no haga zoom, -webkit-tap-highlight-color fuera, env(safe-area-inset-*) para el notch. Y la última fila: “funciona en Chrome pero no en mi móvil” se arregla probando en un móvil de verdad.
• apple-design: los principios de las charlas de diseño de la WWDC traducidos a la web. Respuesta en el pointerdown y no en el click, manipulación directa 1:1, interrupción como principio número uno, traspaso de velocidad entre el gesto y la animación, rubber-banding.
• animation-vocabulary: un glosario inverso. Le describes “lo que rebota cuando se abre un popover” y te devuelve el término exacto para pedírselo bien a una IA o a un diseñador.
• ask-sonner: la guía de su propia librería de toasts, con los problemas típicos (toasts que no salen, salen dos veces o se quedan detrás de un modal).
• write-swift: la rara del grupo. Swift moderno con concurrencia de Swift 6, some frente a any y Swift Testing. Nada de animación; es el otro mundo en el que Emil trabaja.

¿Qué patrones de escritura de skills puedes copiar? ¶

Más allá de la animación, el repo es un curso de cómo escribir skills que funcionan. Si estás montando las tuyas, estas son las ideas que me llevo (y que encajan con las buenas prácticas para crear skills que ya vimos):

💡 Si solo te llevas una idea para tus skills: escribe qué no hace y a quién derivar. Es la línea que más ahorra en confusión cuando tienes más de cinco skills instaladas.

Del criterio al SKILL.md

Escribe tus propias skills con la disciplina de las de Emil

Verás cómo convertir lo que le repites a tu agente en skills que se cargan solas y no pisan a las demás, con la estructura que funciona en Claude Code, OpenCode y 25+ agentes.

Abrir la guía →

Plantillas SKILL.md descargables incluidas

¿Qué pasa si construyes la misma UI con y sin la skill? ¶

Leer reglas está bien. Quería ver si cambian algo de verdad.

El montaje fue sencillo. Dos agentes con el mismo modelo y la misma petición, palabra por palabra: un centro de notificaciones para una app SaaS, con campana y contador, un panel desplegable con cuatro notificaciones, “Marcar todo como leído” con toast de confirmación, borrar una a una, “Vaciar todo” con confirmación y cierre con Escape o clic fuera. “Moderno y pulido, con animaciones y microinteracciones donde creas que aportan”. HTML autocontenido, sin librerías.

La única diferencia: al segundo le pedí que leyera emil-design-eng antes de empezar y la aplicara como criterio. Las skills no las instalé en ningún proyecto; vivían en una carpeta temporal.

Después lo medí todo con Playwright: capturas, un filmstrip de la apertura congelando las animaciones en cada instante y la lista de animaciones activas con document.getAnimations().

En una captura, casi no hay diferencia ¶

Galería · 2 imágenes

El mismo centro de notificaciones, con el panel abierto

Ampliar

1 / 2 · Sin skill

1Sin skill 2Con emil-design-eng

Las dos están bien. Si te las enseño sin decirte cuál es cuál, dudo que aciertes.

Hay detalles estáticos que vienen de la chuleta de UI del repo (cifras tabulares con tabular-nums en el contador y las horas, Intl.PluralRules para los plurales, flex-shrink: 0 en los avatares), pero no saltan a la vista. Y es normal: emil-design-eng habla poco de color, tipografía o composición. Habla de tiempo.

En el tiempo, la diferencia es enorme ¶

Este es el filmstrip de la apertura del panel, congelado en seis instantes:

Sin la skill, el agente hizo lo que haría casi cualquiera: panel con opacity en ease a 200 ms, transform a 280 ms y, encima, las cuatro notificaciones entrando con keyframes de 450 ms escalonadas cada 55 ms. La última termina a los 615 ms. Y eso, cada vez que abres el panel.

Con la skill: opacity y transform del panel a 200 ms con cubic-bezier(0.23, 1, 0.32, 1) y nada más. A los 60 ms ya puedes leerlo.

La línea de tiempo de arriba lo enseña mejor, con los tres casos medidos:

Fíjate en la fila del teclado. El agente con emil-design-eng detectó si el clic venía del teclado (event.detail === 0) y quitó la transición en ese caso. Nadie se lo pidió. Lo dedujo de la regla “never animate keyboard-initiated actions”.

La skill como revisora: Block, con 21 hallazgos ¶

Después le pasé review-animations a la versión sin skill. El veredicto fue Block, con una tabla de 21 filas Before | After | Why y citas de línea.

Una de esas filas destapó un bug que yo no había visto en las capturas. Las notificaciones entraban con animation: in .45s ... both, y ese fill-mode mantiene los valores del último keyframe. Como una animación CSS gana a una transición en la cascada, el fundido y el desplazamiento al borrar una notificación nunca se veían: solo se encogía la altura.

Lo comprobé con Playwright: a 120 ms de pulsar borrar, la fila seguía con opacity: 1 y transform sin mover. La skill cazó un bug real solo leyendo el código.

Otras filas de la revisión que vale la pena ver:

• La campana se balanceaba 800 ms en cada carga de página, sin una notificación nueva que lo justificara.
• El botón “Vaciar todo” hacía un shake al pedir confirmación. La revisión lo tumba: un temblor significa error, y pedir confirmación no lo es.
• El prefers-reduced-motion ponía todas las duraciones a 0,01 ms. Demasiado: debería quitar el movimiento y conservar los fundidos.

Lo que la skill no ve ¶

Ahora la parte honesta. La versión con skill también tiene un bug, y bastante feo.

Galería · 2 imágenes

La confirmación de «Vaciar todo», justo después de pulsar

Ampliar

1 / 2 · Sin skill

1Sin skill 2Con skill (bug)

Cuando pulsas “Vaciar todo”, el botón cambia a “¿Seguro? Eliminar” con texto blanco sobre rojo. Pero el ratón sigue encima, y la regla de hover (#clear-all:not(:disabled):hover) tiene más especificidad que #clear-all.confirm. Resultado: texto blanco sobre rosa pálido, justo en el momento en que tienes que leerlo para confirmar.

Ninguna regla de emil-design-eng cubre la especificidad de CSS. Es una skill de movimiento y acabado, no un linter. La de review-animations, que solo mira animaciones, tampoco lo habría marcado. Para eso tendrías que mirar la interfaz en un navegador, que es justo lo que el repo pide una y otra vez: revisar al día siguiente, en cámara lenta y en un dispositivo real.

🔑 La skill no convierte al agente en diseñador. Le quita los errores de movimiento que más se repiten y le da un vocabulario para justificar cada decisión. El resto sigue siendo trabajo tuyo.

¿Cuándo merece la pena instalar estas skills? ¶

Depende de cuánto movimiento tenga tu interfaz y de quién lo esté escribiendo.

Y un aviso práctico. Instalar las 16 no tiene mucho sentido. Las descripciones se cargan siempre en el contexto del agente, y tienes skills de Swift, Expo y Sonner que quizá no uses nunca. Elige las tres o cuatro de tu stack.

¿En qué se diferencian de Taste Skill, Impeccable o frontend-design? ¶

Por aquí ya hemos repasado otras skills de diseño: Taste Skill, Impeccable y la skill oficial frontend-design. Las de Emil no compiten con ellas. Atacan otra capa.

De hecho, la skill good-css que vimos hace poco delega las animaciones en las de Emil. Ese es el reparto natural: una skill decide cómo se ve, y las de Emil deciden cómo se mueve.

TL;DR ¶

• 🎬 emilkowalski/skills son 16 agent skills del autor de Sonner y Vaul para que tu agente anime con criterio: cuándo, cómo y cuándo no.
• 🧭 La skill madre, emil-design-eng, decide por frecuencia de uso: lo que se ve 100+ veces al día o se dispara con el teclado no se anima nunca.
• 📏 Todo viene con números: cubic-bezier(0.23, 1, 0.32, 1), UI por debajo de 300 ms, scale(0.97) al pulsar, nunca scale(0).
• 🧪 En mi experimento, la misma UI con la skill se lee a los 60 ms frente a 615 ms sin ella, y no anima nada al abrirse con el teclado.
• ⚠️ No es un linter: la versión con skill tenía un botón ilegible por especificidad CSS. Mira siempre el resultado en el navegador.

Preguntas frecuentes ¶

¿Qué son las skills de Emil Kowalski?
Son 16 agent skills publicadas en el repositorio emilkowalski/skills que enseñan a un agente de IA a tomar decisiones de animación y acabado de interfaz: cuándo animar, con qué curva, cuánto tiempo y cuándo no hacerlo. Emil Kowalski es el autor de Sonner y Vaul y ha trabajado en Vercel y Linear.

¿Cómo se instalan las skills de emilkowalski/skills?
Con npx skills@latest add emilkowalski/skills. Si solo quieres algunas, copia sus carpetas a la ruta de skills de tu agente, como .claude/skills/ en Claude Code. Cada skill es autocontenida.

¿Cuál es la skill más importante del repositorio?
emil-design-eng. Contiene la filosofía, el marco de decisión por frecuencia, las curvas y duraciones recomendadas y el formato de revisión Before/After que el resto de skills reutiliza.

¿Funcionan con Codex, Cursor u otros agentes además de Claude Code?
Sí. Siguen el formato estándar de SKILL.md con frontmatter, así que cualquier agente que soporte agent skills puede cargarlas. El CLI de skills.sh las instala en la ruta que use tu herramienta.

¿Qué curva de animación recomienda Emil Kowalski?
Para entradas y salidas de UI, un ease-out fuerte: cubic-bezier(0.23, 1, 0.32, 1). Para movimiento en pantalla, cubic-bezier(0.77, 0, 0.175, 1), y para drawers estilo iOS, cubic-bezier(0.32, 0.72, 0, 1). Nunca ease-in en elementos de interfaz.

¿Cuánto debe durar una animación de interfaz?
Según las skills, por debajo de 300 ms en casi todos los casos: feedback de botón entre 100 y 160 ms, tooltips entre 125 y 200, dropdowns entre 150 y 250 y modales o drawers entre 200 y 500.

¿Por qué no se deben animar las acciones de teclado?
Porque se repiten cientos de veces al día y cualquier animación se percibe como retraso. El ejemplo que usa Emil es Raycast, que no anima su apertura. En el experimento, el agente con la skill quitó la animación del panel cuando se abría con Enter.

¿Qué diferencia hay entre review-animations e improve-animations?
review-animations revisa un diff concreto y emite un veredicto Block o Approve. improve-animations audita todo el repositorio sin tocar código y escribe planes autocontenidos para que otro agente, incluso un modelo más barato, los ejecute.

¿Las skills de Emil sustituyen a Taste Skill o Impeccable?
No. Las de Emil cubren movimiento, interacción y casos límite; Taste Skill, Impeccable y frontend-design cubren la estética visual. Se complementan: una decide cómo se ve la interfaz y la otra cómo se mueve.

¿Una skill de diseño garantiza una interfaz sin errores?
No. En el experimento, la versión construida con emil-design-eng tenía un botón de confirmación ilegible por un conflicto de especificidad CSS. Las skills reducen los errores de movimiento más comunes, pero hay que revisar el resultado en un navegador real.

Fuentes ¶

• emilkowalski/skills en GitHub: el repositorio con las 16 skills, el README y las chuletas de UI y rendimiento.
• Agents with Taste: el artículo de Emil Kowalski que explica el porqué de las skills.
• You Don’t Need Animations: la base de find-animation-opportunities y remove-animations.
• 7 Practical Animation Tips: el origen de la regla de ease-out en las entradas.
• Sonner y la API de descargas de npm para la cifra de descargas semanales.
• skills.sh: la ficha del repositorio en el directorio de skills.

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter