Quante skill di Claude dovresti installare?

Meno di quanto pensi. Per la maggior parte delle persone che svolgono lavoro normale in Claude Code, il numero che si mantiene stabile per mesi è tra cinque e otto skill attivamente utilizzate, senza contare ciò che viene fornito in bundle in un plugin che non hai scelto individualmente. Non è un limite invalicabile. È il punto in cui il portfolio a cui attingi smette di crescere, non importa quante altre ne installi.

Il motivo per cui è basso non è il disordine in una visualizzazione di cartelle. Ogni skill che installi, che tu la usi o meno, mette la sua descrizione del trigger davanti a Claude ad ogni richiesta, per sempre, e ogni descrizione extra è un'altra cosa che Claude deve ignorare correttamente. Oltre un certo punto, aggiungere skill non aggiunge capacità. Aggiunge rumore contro cui le buone skill devono competere.

Questo articolo è l'aritmetica dietro quel numero: cosa ti costa una skill installata ma inattiva, perché due skill sovrapposte sono peggio di una sola, e la struttura del portfolio che usiamo noi stessi dopo averne catalogate e testate 73.

Cosa ti costa effettivamente una skill installata

Le skill si caricano in due fasi. All'avvio della sessione, Claude legge solo il frontmatter, il name e la description, di ogni skill che può trovare, tipicamente da 50 a 150 tokens ciascuno. Questi metadati rimangono nel contesto per l'intera sessione indipendentemente dal fatto che la skill venga mai attivata. Il corpo completo, le istruzioni effettive, si carica solo quando una richiesta corrisponde alla descrizione. Questa è una divulgazione progressiva, ed è il motivo per cui le skill scalano meglio dei prompt incollati. Abbiamo trattato il meccanismo in cosa sono le skill di Claude.

La parte sempre attiva è quella che le persone dimenticano di contare. Supponiamo che tu abbia installato 30 skill con una media di 100 tokens di frontmatter ciascuna: 3.000 tokens che precedono ogni messaggio, ogni turno, ogni sessione, che siano rilevanti o meno. Con 30 turni in una sessione di lavoro, sono 90.000 tokens spesi a rileggere un elenco di metadati prima che Claude faccia qualsiasi cosa tu abbia chiesto. In 22 giorni lavorativi, quasi 2 milioni di tokens al mese di pura "tassa di attesa". Nessuno di questi è costoso di per sé, pochi centesimi alle tariffe Sonnet. Ma compete per lo spazio nella finestra di contesto e si somma a tutto il resto che viaggia insieme: CLAUDE.md, MCP tool schemas, cronologia della sessione. Abbiamo fatto l'analisi completa in ridurre i costi dei token di Claude.

Il costo maggiore non sono i dollari. È l'attenzione. Claude decide quale skill caricare confrontando la tua richiesta con uno stack di descrizioni, e quel confronto diventa meno affidabile man mano che lo stack cresce e le descrizioni iniziano a sovrapporsi nel vocabolario. Una skill che hai installato a marzo e non hai più usato è ancora in quello stack ogni volta che chiedi qualcosa ad aprile, rendendo silenziosamente la corrispondenza corretta un'opzione su 41 invece di un'opzione su 8.

Il problema delle collisioni: due skill, una richiesta

Installa abbastanza skill e alla fine due di esse descriveranno lo stesso compito con parole diverse. Questo non è un'ipotesi. L'abbiamo riscontrato costruendo il nostro catalogo di test: due pacchetti di marketing installati fianco a fianco fornivano entrambi una skill per la copia di outreach, cold-email e email-sequences, con descrizioni che si sovrapponevano abbastanza da rendere plausibile che un singolo prompt "write me a follow-up email" potesse corrispondere a entrambe.

Quando ciò accade, si verifica una delle tre cose, e nessuna ti viene annunciata. Claude ne sceglie una, silenziosamente, basandosi su quale descrizione sembra una corrispondenza leggermente migliore per la tua esatta formulazione, quindi lo stesso prompt chiesto in due modi diversi può attivare due skill diverse. Oppure una collisione dura sul campo name significa che una skill oscura completamente l'altra; la seconda semplicemente non si carica mai, e non riceverai un errore che te lo dica. Oppure, nel peggiore dei casi, Claude cerca di soddisfare entrambe le corrispondenze parziali contemporaneamente e produce un output che è cucito insieme da due set di istruzioni che non sono mai state progettate per cooperare: la tua skill email e la tua skill tono di voce che cercano entrambe di possedere la stessa frase.

La soluzione è diagnostica, non preventiva, perché generalmente non sai che due skill collidono finché non lo fanno. Abbiamo scritto la checklist completa di sei punti per questo in la skill di Claude non si attiva, ma la versione breve specificamente per la dimensione del portfolio: se non riesci a spiegare in una frase perché la skill A gestisce una richiesta invece della skill B, si sovrappongono troppo per rimanere entrambe installate. Uniscile, eliminane una, o riscrivi la descrizione più debole per ritagliare una fetta del lavoro più stretta e non sovrapposta. Il numero di collisioni in un portfolio scala approssimativamente con il quadrato della sua dimensione, che è la versione matematica di "mantienilo piccolo".

L'approccio del portfolio: ancore, situazionali, esperimenti

Una volta accettato che ogni skill installata ha un costo continuo, la domanda si sposta da "dovrei installare questa" a "in quale categoria rientra". Noi le ordiniamo in tre.

Ancore sono le due o cinque skill di cui ti accorgeresti entro un giorno se scomparissero. Generazione di documenti se scrivi report settimanalmente. Una disciplina di debugging se scrivi codice quotidianamente. Una skill di tono o editing se il tuo lavoro è fatto di parole. Queste si guadagnano una casa permanente in ~/.claude/skills/, disponibili in ogni progetto, e sono l'unica categoria che vale la pena installare sulla fiducia prima di aver dimostrato che il trigger funziona specificamente per te.

Situazionali sono reali e utili ma circoscritte a un contesto: una checklist di migrazione per una codebase, la brand voice specifica di un cliente, una skill di conformità di cui solo il tuo progetto regolamentato ha bisogno. Queste appartengono alla cartella .claude/skills/ di un progetto, non alla tua personale. Viaggiano con il repo, sono visibili ai colleghi che lo clonano, e, cosa fondamentale, la loro descrizione compete per l'attenzione solo all'interno delle sessioni in cui sono effettivamente rilevanti. Installare una skill specifica per un cliente a livello globale significa che la sua descrizione viaggia anche su ogni progetto non correlato che tocchi.

Esperimenti sono qualsiasi cosa tu stia provando perché un collega l'ha raccomandata o una voce del catalogo ha ottenuto un buon punteggio. Dai a queste un limite di due settimane dall'installazione. Se non ne hai usata una spontaneamente, naturalmente, senza fare di tutto per testarla, entro la fine delle due settimane, cancellala. La maggior parte degli esperimenti fallisce questo test, e va bene così; è a questo che serve il periodo di prova. L'errore non è provare le skill, è lasciare che quelle non testate passino silenziosamente allo stato di ancora permanente solo perché eliminare una cartella sembra ammettere che la prova è fallita.

Questa struttura risponde anche alla domanda "quante" in modo più utile di un singolo numero. Non è "installa 6 skill in totale". È "mantieni le tue ancore al minimo indispensabile, circoscrivi le situazionali a dove contano, e metti una data di scadenza su tutto il resto".

Cosa è sopravvissuto sul nostro banco di prova

Testiamo ogni skill nel catalogo SkillProof su un'installazione pulita prima che ottenga un verdetto, e separatamente, alcune di quelle skill testate diventano quelle che effettivamente utilizziamo quotidianamente, mesi dopo la pubblicazione della recensione. Questa seconda lista è breve, ed è informativa proprio perché è breve.

DOCX (9.6/10) è quella di cui ci accorgeremmo più velocemente se scomparisse. La skill di riferimento di Anthropic, e il motivo è banale: produciamo documenti Word quasi ogni settimana, e questa scrive documenti reali, indici, modifiche tracciate, carta intestata intatta, invece di markdown che dovremmo riformattare a mano.

Systematic Debugging (9.6/10) e Test-Driven Development (9.6/10), entrambi dalla collezione Superpowers, sono la coppia che ha cambiato il modo in cui le nostre sessioni si svolgono piuttosto che ciò che producono. Nessuno script, nessuno strumento esterno, puro cambiamento di comportamento: red-green-refactor applicato ogni volta, una disciplina di debugging che non permette a Claude di indovinare una soluzione prima di riprodurre il bug. Questi sono il caso più chiaro nel nostro catalogo di una skill che ottiene lo status di ancora solo in base all'output.

Memory Management (9.2/10) si guadagna il suo posto essendo invisibile nel migliore dei modi: impedisce che il contesto evapori tra le sessioni senza che noi gestiamo un file di note a mano.

Nota cosa manca. Il nostro catalogo contiene 73 skill; 35 hanno un verdetto di "pass" pulito. Noi usiamo forse otto di quelle 35 come vere ancore quotidiane. Le altre 27 sono buone, testate e oneste su ciò che fanno, e la maggior parte per noi rimane in stato situazionale o sperimentale, perché "testato e buono" e "appartiene alle tue cinque-otto permanenti" sono standard diversi. Una skill può ottenere 9/10 in una recensione ed essere comunque sbagliato mantenerla installata globalmente se tocchi il suo caso d'uso due volte a trimestre.

Il rituale di potatura mensile

I portfolio vanno alla deriva. Una skill installata per un progetto sopravvive al progetto. Un esperimento supera il suo limite di due settimane perché eliminare le cose non è il compito preferito di nessuno. La soluzione è un passaggio ricorrente di dieci minuti, non una pulizia una tantum.

Una volta al mese, esegui questo:

1. Elenca ciò che è effettivamente installato. ls ~/.claude/skills/ e ls .claude/skills/ per qualsiasi progetto in cui ti trovi. Se non riconosci un nome di cartella, hai già la tua risposta.
2. Chiediti quando è stata attivata l'ultima volta. Se non ricordi di averla usata nell'ultimo mese, e non è un'ancora che usi a intermittenza (stagione fiscale, report trimestrali), è una candidata alla potatura.
3. Verifica le sovrapposizioni. Leggi il campo description di ogni skill affiancate. Due che potrebbero plausibilmente rispondere allo stesso prompt sono una collisione in attesa di accadere; vedi la sezione precedente.
4. Conferma che le skill con ambito di progetto siano effettivamente con ambito di progetto. Qualsiasi cosa specifica per un cliente o un repo non ha motivo di stare nella tua cartella personale, viaggiando su ogni progetto non correlato.
5. Elimina, non archiviare. Una skill disabilitata da qualche parte non deve essere confusa con una attiva. Se non si sta guadagnando il suo posto, rimuovi la cartella.
6. Riprova le tue ancore. Chiedi qualcosa che ogni ancora dovrebbe gestire, senza nominarla, nel modo in cui testiamo i trigger per il catalogo. Se non si attiva correttamente, qualcosa aggiunto in seguito la sta probabilmente oscurando.

Dieci minuti, una volta al mese, e il portfolio mantiene le dimensioni utili invece di andare alla deriva verso le dimensioni che si accumulano e basta.

La qualità batte la quantità

Questa è l'intera tesi di SkillProof compressa in una sezione, e vale la pena dirlo chiaramente qui perché "quante skill" è in realtà un proxy per una domanda diversa: qual è il valore marginale della prossima che stai per installare?

Delle 45 skill che abbiamo sottoposto a test completi, 35 hanno superato il test e 10 hanno richiesto una configurazione aggiuntiva per funzionare. Questo non è un attacco all'ecosistema, il formato è intenzionalmente aperto, chiunque può pubblicare senza un gate di revisione, ed è esattamente per questo che è cresciuto rapidamente. Ma significa anche che la skill media su GitHub non è verificata, e installare dieci skill mediocri non equivale a una buona. Equivale a dieci descrizioni di trigger che competono con le tue buone per la stessa corrispondenza, dieci blocchi di metadati inattivi ad ogni richiesta, e un numero crescente di coppie che potrebbero silenziosamente ostacolarsi a vicenda. Abbiamo approfondito i modelli di fallimento specifici, descrizioni vaghe che non si attivano mai, output non migliore del default di Claude, passaggi di configurazione mancanti, in perché metà delle skill di Claude non funzionano.

La versione pratica: prima di installare qualsiasi cosa, chiediti se sopravviverebbe al limite di due settimane dell'esperimento e se fa qualcosa di significativamente migliore di quanto farebbe Claude senza prompt. Se non puoi rispondere sì a entrambi, non ti costa molto saltarla, ma non ti sta nemmeno aiutando. Le nostre classifiche di efficienza ordinano le skill testate specificamente in base a quella barra di output-rispetto-alla-baseline, che è un filtro più veloce che leggere venti README da solo.

FAQ

Esiste un limite massimo al numero di skill di Claude che posso installare?

Nessun limite tecnico che abbiamo riscontrato nei test. Claude scansiona ogni cartella di skill che trova e carica tutto il loro frontmatter all'avvio della sessione, che si tratti di 5 skill o 150. Il limite che conta non è una barriera imposta da Claude, è il punto in cui la "tassa" dei metadati sempre attivi e le crescenti probabilità di sovrapposizione delle descrizioni iniziano a costare più di quanto una nuova skill aggiunga. Quel punto tende a situarsi intorno alle 30-40 skill installate per la maggior parte delle persone, ben prima di qualsiasi limite a livello di formato.

Le skill inattive rallentano Claude o costano solo token?

Principalmente token e accuratezza della corrispondenza, non una latenza grezza in modo drammatico. Il frontmatter di una skill inattiva rimane nel contesto ad ogni turno, il che aggiunge un piccolo, reale costo che si accumula nel corso di un mese, ed è un'altra descrizione che Claude deve considerare quando decide cosa attivare. Una manciata di skill inattive è genuinamente innocua. Quaranta di esse sono un'altra storia, principalmente perché le probabilità che una skill obsoleta oscuri o corrisponda parzialmente a una richiesta che ti interessa aumentano con il numero.

Come faccio a sapere se una skill che ho installato viene effettivamente utilizzata?

Chiedi qualcosa che dovrebbe gestire senza nominarla, lo stesso test di trigger che eseguiamo per ogni voce del catalogo. Se il comportamento di Claude cambia visibilmente, ad esempio, produce un vero .docx invece di markdown incollato, si è attivata. Se nulla cambia, o la descrizione non corrisponde a come formuli effettivamente le richieste, o un'altra skill sta vincendo la corrispondenza per prima. La nostra guida alla skill che non si attiva ha il processo completo di sei controlli per distinguere le due situazioni.

Le skill personali e di progetto dovrebbero contare per lo stesso limite?

Trattale separatamente. Le skill personali in ~/.claude/skills/ viaggiano con ogni progetto che tocchi, quindi dovrebbero essere la breve lista di ancore che ti mancherebbero quotidianamente indipendentemente dal contesto. Le skill di progetto in .claude/skills/ caricano il loro frontmatter solo nelle sessioni all'interno di quel repository, quindi un progetto può ragionevolmente contenere più skill situazionali senza gravare affatto sul tuo altro lavoro. L'errore che vediamo più spesso è mettere skill specifiche per il cliente o per il repo nella cartella personale, dove gravano su ogni progetto non correlato per sempre.

Qual è il modo più veloce per ridurre un elenco di skill troppo esteso?

Esegui il rituale di potatura mensile una volta, immediatamente, invece di aspettare il prossimo passaggio programmato. Elenca tutto ciò che è installato, taglia qualsiasi cosa che non ricordi di aver attivato nell'ultimo mese e che non sia un'ancora nota per l'uso a intermittenza, controlla le skill rimanenti per sovrapposizioni di descrizione e sposta qualsiasi cosa specifica per il cliente o il progetto fuori dalla tua cartella personale. La maggior parte delle configurazioni troppo estese scende da oltre 30 skill a meno di dieci al primo passaggio, perché la maggior parte dell'elenco è costituita da esperimenti che nessuno si è preso la briga di eliminare.