Skills Design

Fa creare all’agente arte visiva vera: parte da una filosofia estetica e la esprime in un pezzo grafico esportato in PNG o PDF.

Quando usarla

Quando ti serve un visual statico e finito — un poster, una copertina, un’illustrazione — con un punto di vista estetico, non un template.

Quando evitarla

Non costruisce interfacce o componenti e non copia lo stile di un artista o di un brand: genera solo PNG/PDF originali, non file di design modificabili.

Un comando della skill impeccable: abbassa il volume di un’interfaccia troppo aggressiva o sovrastimolante, senza toglierle forza.

Quando usarla

Quando uno schermo «grida» — troppi accenti, colori e ombre in competizione — e non capisci più dove guardare per primo.

Quando evitarla

Se il problema è la troppa roba (campi e opzioni di troppo) usa distill; se vuoi un giudizio e non una modifica, usa critique.

Un comando della skill impeccable: toglie campi, passaggi e opzioni finché resta solo l’essenziale per completare l’azione.

Quando usarla

Quando un form o un pannello è cresciuto per accumulo e nessuno ha mai tolto niente.

Quando evitarla

Se l’interfaccia è già essenziale ma «urla» a livello visivo, il problema è il volume, non la struttura: usa quieter.

Un comando della skill impeccable: fa una review UX su più criteri, assegna un punteggio e restituisce i rilievi con l’azione da fare.

Quando usarla

Prima di una review umana, per arrivarci con i problemi ovvi già trovati e ordinati per gravità.

Quando evitarla

Non tocca il codice: se vuoi che i problemi vengano anche corretti, dopo la critica passa a polish o distill.

Un comando della skill impeccable: l’ultima passata sui dettagli — allineamenti, raggi, focus, cifre che non ballano — prima di pubblicare.

Quando usarla

Quando il design è deciso e funziona, e resta solo il giro finale di rifinitura prima di spedire.

Quando evitarla

Non è una riprogettazione: se l’impianto è sbagliato, prima sistema la struttura (distill) o il volume (quieter), poi rifinisci.

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

Controlla il codice dell’interfaccia contro le Web Interface Guidelines di Vercel e segnala le violazioni in formato file:riga.

Quando usarla

Quando vuoi sapere se ciò che hai costruito supera un controllo di conformità e accessibilità, prima che lo scopra un utente.

Quando evitarla

Non ridisegna e non corregge: legge e segnala soltanto. Per misurare le prestazioni reali nel browser serve altro (Lighthouse, Core Web Vitals).

Il livello di smistamento della collezione UI di ibelick: capisce l’obiettivo e carica la skill più piccola e mirata invece di una generica.

Quando usarla

All’inizio di un lavoro di UI, quando hai un obiettivo chiaro ma non sai quale regola specifica ti serve.

Quando evitarla

Per un compito non-UI risponde «nessuna skill serve»; e se sai già esattamente quale skill vuoi, saltalo e installala diretta.

La filosofia di design engineering di Emil Kowalski (autore di Sonner e Vaul): come polish, componenti e motion si sommano in una UI che «sembra giusta».

Quando usarla

Quando vuoi allenare il gusto dell’agente sui dettagli invisibili e ottenere componenti che reggono il confronto con i migliori.

Quando evitarla

È ampia e filosofica: per la regola secca su un dettaglio (raggi, allineamento, ombre) è più diretta make-interfaces-feel-better; per revisionare solo animazioni, review-animations.

Le regole concrete che fanno sembrare una UI curata: raggio concentrico, allineamento ottico, ombre invece di bordi, animazioni interrompibili, cifre tabulari.

Quando usarla

Quando l’interfaccia è giusta ma «sa di prototipo» e vuoi la checklist precisa dei dettagli da sistemare.

Quando evitarla

Se cerchi il perché e il gusto dietro le scelte più che la lista di regole, prendi emil-design-eng.

152 regole UI/UX su 12 categorie — animazione, timing, uscite, audio, leggi della UX, tipografia — ordinate per impatto, con rilievi in formato file:riga.

Quando usarla

Quando vuoi una revisione ampia e ragionata su regole — incluse motion, audio e leggi cognitive — non solo accessibilità.

Quando evitarla

È un rulebook di revisione, non un costruttore: per la sola conformità design e a11y su codice è più mirata web-design-guidelines.

Costruisce sistemi di colore in OKLCH: conversione da hex/rgb/hsl, scale e palette, contrasto APCA/WCAG, gamut e tema in Tailwind v4.

Quando usarla

Quando crei la scala colori di un design system e i passaggi sembrano irregolari, o un contrasto non passa e non sai di quanto alzare.

Quando evitarla

Fa solo colore: per spaziature, tipografia o layout serve un’altra skill.

Guarda un sito pubblico e ne estrae i primitivi — colori, font, spaziature, raggi, ombre — generando file di token di partenza per il tuo progetto.

Quando usarla

Quando parti da un riferimento visivo e vuoi tradurne le regole in variabili invece che a occhio.

Quando evitarla

È un punto di partenza, non una copia: la doc stessa dice che non è riproduzione pixel-perfect, non ricava una libreria di componenti e una pagina sola non è un intero design system.

Traduce per il web il modo Apple di fare movimento fluido: molle interrompibili, tracking 1:1 del gesto, momentum, materiali traslucidi, reduced-motion.

Quando usarla

Quando costruisci interazioni guidate dal gesto (drag, swipe, sheet) e vuoi che partano dal valore a schermo e restino afferrabili a metà.

Quando evitarla

Per una transizione semplice non-gestuale una molla è spesso eccessiva, e non è uno strumento di grafica statica. Per revisionare animazioni già scritte, review-animations.

Glossario a ricerca inversa: da una descrizione vaga di un movimento («quello che rimbalza quando si apre») ti dà il termine esatto.

Quando usarla

Quando sai che effetto vuoi ma non come si chiama, e senza il nome giusto l’agente ti dà altro.

Quando evitarla

Serve a nominare, non a costruire né a progettare: per creare il movimento usa apple-design, per revisionarlo review-animations.

Revisiona il codice di animazione contro un’asticella di qualità alta (filosofia Emil Kowalski): l’approvazione va guadagnata, di default segnala.

Quando usarla

Dopo aver fatto animare qualcosa, quando «quasi ci siamo» e vuoi sapere cosa non va: durate, curve, origine, frame persi.

Quando evitarla

Fa solo questo: rifiuta il codice non-motion e non scrive funzionalità. Per costruire il movimento usa apple-design, per nominarlo animation-vocabulary.