Figma Make: 3 skill personalizzate per il design system

La build consegnata fuori brand

La build arrivata in revisione era quasi giusta. Ed è proprio questo il caso più insidioso. I pulsanti avevano un raggio di 12px, nonostante il sistema fosse bloccato su 8px fin dal rebranding. L'accento principale risultava simile a #18C5DA: visivamente vicino al #06B6D4 del cliente, ma bastava incollarlo nel selettore colore di Figma per vedere subito lo scostamento. Al terzo frame, la scala tipografica usava un corpo da 18px dove il sistema ne prevede 16px.

Il prompt scritto quella mattina non aveva nulla che non andasse. Il problema era quello scritto sei prompt prima. Figma Make conserva il contesto durante una sessione, ma le regole del design system perdono peso man mano che ci si allontana dal punto in cui sono state inserite. Quando si arriva a rifinire la terza variante della hero, il modello comincia così a improvvisare valori dei token plausibili. Le note di rilascio di maggio 2026 indicano espressamente questo vuoto come il problema che le custom skill devono risolvere: un insieme di istruzioni confezionato e richiamabile, da agganciare a ogni prompt senza doverlo incollare di nuovo. (Riepilogo delle note di rilascio di Figma, maggio 2026)

Dopo aver creato il pacchetto di skill qui sotto, ho eseguito di nuovo lo stesso brief in Make. Raggio dei pulsanti: 8px. Accento: #06B6D4. Corpo del testo: 16px. La skill non ha reso Make più intelligente: ha reso le regole impossibili da dimenticare.

Il brief: i requisiti effettivi del design system

Il sistema citato in questo articolo appartiene a un cliente reale. Ecco i token, ripuliti dagli elementi identificativi:

• Colore: sfondo #0A0E14, primo piano #E6EDF3, un solo accento #06B6D4. Nessun accento secondario. Nessun gradiente.
• Spaziatura: base 8px. Scala consentita 8 / 16 / 24 / 40. Nessun valore intermedio o esterno.
• Scala tipografica: 14 / 16 / 20 / 32 / 48. Il corpo è 16. Mai 18.
• Raggio: 8px su ogni superficie interattiva. 0 sulle card. Nessuna eccezione.
• Pulsante: un componente, tre stati: predefinito, hover, disabilitato. L'accento riempie lo stato predefinito; nello stato disabilitato, il colore di primo piano ha opacità al 30%.

Un prompt generico come "segui il nostro brand" fallisce su ciascuno di questi punti, perché gli aggettivi lasciano spazio all'interpretazione. "Freddo, minimale, con un solo accento" potrebbe descrivere mille sistemi. Al modello non serve la moodboard, ma la tabella. L'obiettivo è fare in modo che ogni build prodotta in Make per questo cliente venga verificata rispetto a quella tabella, senza doverla riscrivere a ogni sessione.

Le 3 skill per Figma Make: i file .md completi

Le custom skill di Figma Make sono singoli file Markdown conformi alla specifica Agent Skills. Il valore name nel frontmatter diventa il comando slash. Le skill si installano a livello di account, restano disponibili in tutti i file Make di cui si è proprietari e, dettaglio importante, devono essere autosufficienti: niente directory scripts/, references/ o assets/. Tutto ciò che il modello deve usare va inserito direttamente nelle istruzioni. (Custom skill per Figma Make, guida di Figma)

Tre skill coprono il 90% di quello che prima dovevo riscrivere.

/follow-ds-guidelines

La tabella letterale dei token, incollata nelle istruzioni. Nessuna interpretazione, nessun aggettivo.

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

È la skill dedicata alla revisione. Make controlla il frame corrente rispetto alla tabella dei token e restituisce un elenco di elementi conformi o non conformi, indicando per questi ultimi i valori esatti in esadecimale e in pixel.

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

La skill per i dati di esempio inserisce testi segnaposto già approvati dal cliente. In questo modo, le build di revisione non arrivano più con lorem ipsum o nomi di aziende inventati dal modello, che in seguito l'ufficio legale potrebbe contestare. (Riepilogo delle note di rilascio di maggio 2026)

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

Tre file. Ognuno sostituisce qualcosa che prima dovevo incollare di nuovo.

Collegare Notion per leggere il design system aggiornato

L'approccio con token statici di /follow-ds-guidelines funziona per un sistema stabile. Non appena il cliente aggiorna un token — e prima o poi succede — la tabella incorporata diventa obsoleta. La soluzione è affiancare alla skill un connettore, così Make recupera la fonte aggiornata. (Connettori in Figma Make, guida di Figma)

Nel file usato da questo cliente, il design system risiede in un'unica pagina Notion, con le stesse intestazioni della skill (Color, Spacing, Type ramp, Radius, Button). Richiamo la skill e il connettore nello stesso prompt.

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

Lo stesso prompt può recuperare da Drive un PRD con la stessa struttura — @Drive "Halcyon pricing PRD" — e Make combina in un solo passaggio il contesto del design system con quello delle specifiche. (Riepilogo delle note di rilascio di maggio 2026)

La scelta varia da cliente a cliente: uso token inline per i sistemi rimasti invariati nell'ultimo trimestre e token forniti dal connettore per quelli ancora in evoluzione. Il file .md della skill non cambia nei due casi; cambia il prompt. È una decisione intenzionale: non voglio una proliferazione di skill specifiche per ogni cliente, ma una sola skill che sappia accettare valori sostitutivi.

Un elemento correlato: la skill /prototype-to-figma del server MCP di Figma opera su un piano diverso. È preinstallata per i passaggi dal codice alla canvas e viceversa, e non viene scritta dall'utente. Le custom skill di Make funzionano al contrario: vengono scritte dall'utente, vivono in Make e non interagiscono con il livello MCP.

Cosa non ha funzionato: non determinismo e costo della condivisione

L'annuncio ha tralasciato tre aspetti.

La compatibilità con i modelli è più limitata di quanto lascino intendere i documenti. Al momento, le custom skill funzionano soltanto con il modello predefinito di Figma Make e con Claude Opus 4.7. Se il team ha adottato un modello diverso in Make, la skill non viene applicata e non compare alcun errore evidente: semplicemente, le regole non vengono rispettate. (Custom skill per Figma Make, guida di Figma) In una build di team, è il primo controllo che eseguo prima di chiedermi perché il raggio sia di nuovo sbagliato.

I risultati sono coerenti "molto spesso", non identici. Lo afferma la documentazione stessa di Figma. Il modello è non deterministico, quindi su un frame complesso /design-crit può occasionalmente ignorare uno scostamento o segnalarne uno intenzionale. (Custom skill per Figma Make, guida di Figma) Considero quindi la skill di revisione un primo controllo rapido, non un'approvazione definitiva.

Il costo della condivisione è il vero problema operativo. Oggi le custom skill appartengono al singolo account. Per fornire il pacchetto a un collega bisogna esportare i file .md, che poi dovrà caricare sul proprio account. Non esiste una pubblicazione a livello di organizzazione. (Custom skill per Figma Make, guida di Figma) Per uno studio che gestisce più sistemi cliente è un attrito concreto: ogni nuovo collega richiede un'installazione manuale per ciascuna skill attiva e ogni aggiornamento comporta una nuova esportazione. La soluzione è poco appariscente, ma funziona: versionare i file .md nel repository del cliente — noi li teniamo nello stesso monorepo, accanto ai design token — e contrassegnare le release. In questo modo, il caricamento parte da un'unica fonte affidabile anziché da un messaggio su Slack.

Una considerazione operativa per i designer che lavorano su piattaforme con questo tipo di costo per postazione: ho analizzato anche i costi dei piani premium di Webflow per gli studi di design, per lo stesso motivo. Gli strumenti fatturano la superficie visibile; il costo dell'attrito nell'integrazione resta a carico di chi li usa.

La lezione: cosa affidare a una skill e cosa lasciare alle persone

Dopo alcune settimane di utilizzo in DVNC.studio, ho adottato una regola: tutto ciò che ho dovuto riscrivere più di due volte finisce in una skill. Tabelle dei token, checklist di revisione, convenzioni per i dati di esempio, boilerplate per le annotazioni di accessibilità. Nulla di tutto questo è creativo. Tutto, invece, rappresentava un costo operativo.

Alle persone resta la decisione. /design-crit segnala un valore fuori sistema, ma non stabilisce se sia un errore o un'eccezione voluta per una superficie di marketing specifica. La skill sa riconoscere che "questo raggio è 12, mentre quello previsto è 8". Non sa capire che "questo raggio è 12 perché il concept della campagna richiedeva una card più morbida e martedì abbiamo deciso così". Il lavoro sta in quel giudizio.

La prova da fare martedì prossimo è questa: scegliere il sistema cliente utilizzato più spesso. Aprire un file .md. Incollare la tabella dei token come ho fatto sopra con quella di Halcyon. Salvarlo come follow-ds-guidelines.md, caricarlo come custom skill, provarlo su una build reale, quindi eseguire /design-crit sull'output e confrontare manualmente le differenze con la tabella dei token. Se la skill intercetta ciò che sarebbe emerso dalla revisione umana, ha eliminato un'ora alla settimana di nuovi prompt per ogni cliente. Se ignora qualcosa di evidente, la correzione va fatta nel .md, non nella cronologia dei prompt.