Lavori Chi sono Competenze Blog
Instagram LinkedIn Telegram
// Mestre, Venezia - Italia
Design Pills

Design Pills - Capitolo 08

Come creare la tua prima skill di Claude: guida passo passo per designer.

Autore
Daniele Scanferlato
Pubblicato
Argomento
AI • Design Workflow • Claude
Lettura
11 min

Introduzione

Ogni designer ha una lista di controlli che fa a memoria prima di passare un file: gli stati vuoti, i messaggi d'errore, il contrasto, i nomi lunghissimi che rompono il layout. La fa a memoria, quindi a volte salta un punto.

Una skill serve a mettere quella lista per iscritto una volta sola, in un formato che Claude legge e applica ogni volta che serve. Nell'articolo sulle 13 Skills di Claude per experience designer ho raccolto quelle già pronte. Qui costruiamo la tua, passo per passo, su un esempio reale: una skill che fa la revisione di design di una schermata.

Il momento è buono. Dal 22 ottobre 2026 le skill sono uno standard aperto gestito dalla Linux Foundation, adottato secondo Anthropic da più di 70 piattaforme. La skill che scrivi oggi per Claude la porti anche in Cursor, GitHub Copilot o ChatGPT.

Cos'è una skill, in concreto

Una skill è una cartella. Dentro c'è almeno un file, SKILL.md, con due parti: un'intestazione con il nome e la descrizione, e sotto le istruzioni scritte in Markdown. Puoi aggiungere altre cartelle: references/ per i documenti da consultare, scripts/ per il codice, assets/ per modelli e immagini.

reviewing-designs/
├── SKILL.md
└── references/
    └── checklist.md

Claude la carica a strati, ed è questo che rende le skill leggere:

  • All'avvio legge solo nome e descrizione di ogni skill installata: circa cento token a skill, secondo la specifica.
  • Quando una richiesta corrisponde alla descrizione, legge tutto il SKILL.md.
  • Solo se serve apre i file di riferimento citati nelle istruzioni.

Puoi installare decine di skill senza appesantire le conversazioni. In cambio, la descrizione deve fare un lavoro preciso: è l'unica cosa che Claude legge per decidere se usarla.

Scegli cosa mettere in una skill

Una buona prima skill nasce da un lavoro che fai spesso e che ha regole che sai scrivere. Tre candidati tipici per un designer:

  • Revisione di design: la checklist prima di un test con gli utenti o dell'handoff.
  • Tono di voce: il vocabolario approvato e le regole del microcopy di un prodotto.
  • Note di handoff: il formato delle annotazioni che il tuo team di sviluppo si aspetta.

Lasciale fuori le cose che dipendono dal gusto del momento. Se non riesci a spiegare una regola a un collega in due righe, Claude non la applicherà meglio di lui.

Passo 1: la cartella e il nome

Il nome ha regole rigide, perché deve funzionare su tutte le piattaforme:

  • al massimo 64 caratteri, solo lettere minuscole, numeri e trattini;
  • niente trattino all'inizio, alla fine o doppio;
  • identico al nome della cartella;
  • niente parole riservate come "claude" o "anthropic", che le API rifiutano.

La guida di Anthropic suggerisce un verbo in "-ing" che dica l'azione: reviewing-designs, writing-microcopy. È un consiglio, non un obbligo. Evita nomi generici come helper o tools: tra dieci skill installate non sapresti più cosa fanno.

Passo 2: la descrizione

È la parte più importante, e la più sbagliata. La descrizione dice due cose: cosa fa la skill e quando usarla. Le linee guida ufficiali chiedono di scriverla in terza persona e con le parole che l'utente userebbe nella richiesta.

Troppo vaga

Aiuta con il design.

Funziona

Revisiona schermate, mockup e frame Figma: stati mancanti, accessibilità, testi e casi limite. Usala quando l'utente chiede una revisione, un parere o un controllo su un'interfaccia.

Due accorgimenti:

  • Sii un po' insistente. La skill-creator di Anthropic nota che Claude tende a non attivare le skill quando potrebbe. Elencare i modi in cui la richiesta può arrivare ("revisione", "parere", "controllo") aiuta.
  • Stai sotto i 200 caratteri. Lo standard ne ammette fino a 1.024, ma l'help center di Claude.ai indica 200 come massimo. Con 200 sei sicuro ovunque.

Passo 3: le istruzioni

Sotto l'intestazione scrivi cosa deve fare Claude. Le regole che contano, prese dalle linee guida ufficiali:

  • Breve. Claude sa già cos'è un'interfaccia: scrivi solo quello che non può sapere, cioè il tuo metodo e i tuoi criteri. Sotto le 500 righe, meglio molto meno.
  • All'imperativo. "Controlla gli stati vuoti", non "sarebbe utile controllare".
  • Con il perché. Una regola spiegata viene applicata con giudizio anche ai casi che non hai previsto. Una regola urlata in maiuscolo viene applicata alla cieca.
  • Con il formato della risposta. Se vuoi una tabella con le priorità, dillo. Altrimenti ogni revisione avrà una forma diversa.

Passo 4: i file di riferimento

La checklist completa è lunga, e non serve leggerla tutta a ogni richiesta. Mettila in references/checklist.md e citala nel SKILL.md: Claude la apre quando arriva a quel punto. La specifica raccomanda di tenere i riferimenti a un solo livello di profondità, senza file che rimandano ad altri file.

La skill completa

Questo è il SKILL.md. Puoi copiarlo e adattarlo.

---
name: reviewing-designs
description: Revisiona schermate, mockup e frame Figma: stati mancanti, accessibilità, testi e casi limite. Usala quando l'utente chiede una revisione, un parere o un controllo su un'interfaccia.
---

# Revisione di design

Rivedi l'interfaccia come un designer senior prima di un test con gli
utenti. Cerchi i problemi che costano caro dopo il rilascio: il gusto
estetico resta fuori.

## Come procedere

1. Capisci cosa stai guardando: quale schermata, per chi, quale compito
   deve permettere. Se non è chiaro, chiedilo prima di iniziare.
2. Controlla i cinque gruppi di references/checklist.md, nell'ordine.
3. Segnala solo i problemi che vedi o che deduci con sicurezza. Quello che
   un'immagine statica non mostra (il focus da tastiera, le animazioni)
   va tra le domande aperte.

## Formato della risposta

Una tabella con quattro colonne: priorità (bloccante, importante,
ritocco), dove, cosa succede all'utente, come correggerlo.
Poi al massimo tre domande aperte.
Chiudi con una riga sul punto più riuscito della schermata, così chi
riceve la revisione sa cosa non toccare.

## Da evitare

- Proporre un redesign completo: correggi quello che c'è.
- Commentare colori o font, se non violano un punto della checklist.

E questo è references/checklist.md:

# Checklist di revisione

## 1. Stati
Vuoto, caricamento, errore, successo, contenuto parziale, offline, primo
uso. Ogni stato che manca è una schermata che lo sviluppo inventerà.

## 2. Accessibilità
- Contrasto del testo almeno 4.5:1; 3:1 per testo grande e componenti
  (WCAG 2.2, livello AA).
- Bersagli tattili da 44x44 pt su iOS e 48x48 dp su Android.
- Ogni icona senza testo ha un'etichetta.
- L'informazione non passa solo dal colore.

## 3. Testi
- Un concetto, una parola: niente sinonimi per la stessa azione.
- Pulsanti con un verbo che dice cosa succede.
- Ogni errore dice cosa fare dopo.

## 4. Casi limite
Nomi lunghissimi, numeri grandi, zero elementi, mille elementi, rete
lenta, testi tradotti più lunghi dell'originale.

## 5. Design system
Componenti, token e spaziature del sistema in uso. Ogni eccezione deve
avere un motivo.

Passo 5: installala

Dipende da dove lavori.

  • Claude Code. Metti la cartella in ~/.claude/skills/ per averla in tutti i tuoi progetti, oppure in .claude/skills/ dentro un progetto per condividerla con il team attraverso il repository. Puoi anche richiamarla a mano con /reviewing-designs.
  • Claude.ai e app desktop. Comprimi la cartella in un file ZIP, poi vai in Customize, Skills, premi "+", "Create skill" e "Upload a skill". Le skill sono disponibili su tutti i piani, compreso quello gratuito, con l'esecuzione del codice attiva; sui piani Enterprise le deve abilitare un amministratore.
  • API. Le skill si caricano con l'endpoint dedicato e si passano alla richiesta insieme allo strumento di esecuzione del codice.

Le altre piattaforme che hanno adottato lo standard leggono la stessa cartella: cambia solo il punto in cui la metti.

Passo 6: provala

Una skill non funziona finché non l'hai vista attivarsi. Prepara due gruppi di richieste.

  • Richieste che devono attivarla, con un'immagine allegata: "Mi dai un parere su questa schermata di checkout?", "Controlla questo frame prima che lo passi agli sviluppatori".
  • Richieste che non devono attivarla: "Disegnami una schermata di login". Qui l'utente chiede di creare, non di rivedere.

Per sapere se la skill è stata caricata, su Claude.ai guarda il ragionamento di Claude; in Claude Code chiedi "Quali skill sono disponibili?". Se non si attiva quando dovrebbe, quasi sempre il problema è la descrizione: aggiungi le parole che hai usato nella richiesta.

Anthropic suggerisce di scrivere almeno tre casi di prova prima ancora delle istruzioni, e di lavorare con due conversazioni: una in cui scrivi la skill insieme a Claude, l'altra in cui la usi come farebbe un utente. Quello che va storto nella seconda ti dice cosa correggere nella prima.

Gli errori più comuni

  • La descrizione generica. "Aiuta con il design" non si attiva mai, o si attiva sempre.
  • Le istruzioni che spiegano cose ovvie. Ogni riga inutile ruba attenzione a quelle utili.
  • Troppe alternative. "Puoi fare A, oppure B, oppure C" lascia Claude a scegliere a caso. Indica una strada e quando cambiarla.
  • Le informazioni con una data. "Dal prossimo mese" invecchia. Scrivi regole che restano vere.
  • I campi di Claude Code nelle altre piattaforme. Claude Code accetta campi aggiuntivi nell'intestazione. Caricati su Claude.ai o via API, gli stessi campi bloccano l'installazione: per una skill da portare ovunque, usa solo nome e descrizione.
  • Password e chiavi nel file. Una skill si condivide come un documento: non metterci niente che non daresti a un collega.

Una nota sulla sicurezza

Una skill può contenere script e chiedere accesso a strumenti. Anthropic raccomanda di usare solo skill da fonti di cui ti fidi e di leggerne tutti i file prima di installarle, come faresti con un programma. Per le skill scritte da te il problema non si pone. Per quelle trovate in rete, cinque minuti di lettura valgono la pena.

Domande frequenti

Serve saper programmare per creare una skill?

No. Una skill di design è un file di testo in Markdown con un'intestazione di due righe. Gli script sono facoltativi.

Posso scrivere la skill in italiano?

Sì. Claude capisce le istruzioni in italiano, e se le tue richieste sono in italiano conviene che anche la descrizione lo sia, perché contiene le parole che fanno attivare la skill.

Quanto deve essere lunga la descrizione?

Lo standard ammette fino a 1.024 caratteri, ma l'help center di Claude.ai indica 200 come massimo. Restare sotto i 200 caratteri funziona ovunque.

Le skill funzionano con il piano gratuito di Claude?

Secondo l'help center di Claude, sì: le skill sono disponibili su tutti i piani, compreso Free, con l'esecuzione del codice attiva.

Posso usare la stessa skill fuori da Claude?

Sì, se rispetti lo standard Agent Skills: nome valido, descrizione e istruzioni in SKILL.md, nessun campo specifico di una sola piattaforma.

Conclusione

La tua prima skill non deve essere ambiziosa. Deve contenere una cosa che sai fare bene e che oggi ripeti a memoria, scritta in modo che un'altra persona, o Claude, possa farla al posto tuo con gli stessi criteri.

Parti dalla revisione di design di questo articolo, provala su tre schermate vere e correggi la descrizione finché non si attiva quando serve. Poi passa al tono di voce del tuo prodotto, e quando i testi sono pronti dagli una passata con Stop Slop.

Aggiornato al 2 novembre 2026, sulla base della specifica di agentskills.io e della documentazione ufficiale di Anthropic.

Successivo →
Prossimamente