Oltre l'hype: abbiamo eseguito 1416 skill di Claude per scoprire quante funzionano davvero

Probabilmente avrete visto i numeri: titoli e directory che pubblicizzano oltre 23.000 skill di Claude disponibili per l'installazione. Questa cifra suggerisce un ecosistema vasto e maturo di strumenti pronti ad aumentare le capacità del modello di base. È un numero impressionante, ma solleva una domanda tecnica fondamentale: cosa significa veramente "disponibile"? Nella maggior parte dei casi, significa che un manifest SKILL.md è stato trovato in un repository di codice pubblico. È un conteggio basato sul ritrovamento di file, non sulla verifica funzionale.

Questo approccio è semplice, scalabile e, in definitiva, fuorviante. Non dice nulla sulla possibilità che una skill si installi, venga eseguita senza errori o svolga efficacemente la sua funzione dichiarata. Non dice se si tratta di un progetto abbandonato, di un proof-of-concept non funzionante o se addirittura le sue prestazioni sono peggiori rispetto a non usare alcuna skill.

In SkillProof, adottiamo un approccio diverso. Non contiamo i repository; installiamo ed eseguiamo le skill su una serie standardizzata di task del mondo reale. Questo articolo presenta i nostri risultati ottenuti testando 1416 skill. È una risposta diretta e basata sui dati alla domanda su quante skill di codice di Claude funzionino effettivamente, e un'analisi sull'affidabilità dei marketplace di skill di Claude come fonti di strumenti pronti per la produzione.

Il problema nel contare i file

Il problema fondamentale di un conteggio di oltre 23.000 skill è che tratta il ritrovamento come una convalida. Fare lo scraping di piattaforme come GitHub alla ricerca di file SKILL.md è un compito banale. Il numero che ne risulta è ottimo per il marketing, ma è una vanity metric che ignora la realtà dello sviluppo software.

Un repository contenente un manifest di una skill è solo un punto di partenza. È una dichiarazione, non una garanzia. Quando abbiamo iniziato il nostro processo di test sistematico delle skill, abbiamo rapidamente identificato schemi di fallimento comuni che il semplice conteggio dei file ignora completamente:

• Manifest incompleti o malformati: Il file SKILL.md esiste, ma mancano sezioni obbligatorie, punta a definizioni di strumenti inesistenti o è sintatticamente scorretto. La skill è impossibile da installare senza una correzione manuale.
• Dipendenze non funzionanti: Il codice della skill si basa su librerie esterne obsolete, con breaking change, o non più disponibili. L'installazione potrebbe avere successo, ma la skill fallirà a runtime.
• Requisiti di ambiente non documentati: Una skill potrebbe richiedere variabili d'ambiente specifiche, un servizio locale in esecuzione o token di autenticazione non menzionati nella sua documentazione. Una skill che abbiamo testato richiedeva una versione specifica di un database in esecuzione su localhost:5433, un dettaglio scoperto solo leggendo il suo codice sorgente Python. Senza questo, non era funzionante.
• Progetti abbandonati: Il repository non viene aggiornato da anni. Il codice è stato scritto per una versione precedente dell'API di Claude e non è più compatibile.
• "Prompt-come-Skill": Alcune skill non contengono strumenti reali. Sono semplicemente prompt elaborati e impacchettati in un formato di skill. Sebbene potenzialmente utili, non rappresentano un'estensione funzionale delle capacità del modello e spesso non offrono prestazioni migliori di un prompt ben scritto.

Il semplice conteggio di questi repository gonfia le dimensioni e la salute percepite dell'ecosistema. Crea un panorama in cui trovare uno strumento funzionante e affidabile è una questione di tentativi ed errori. La nostra metodologia di test è stata progettata specificamente per superare questo rumore di fondo, rendendo l'esecuzione la misura principale della validità di una skill.

I nostri risultati: uno sguardo realistico al conteggio effettivo

Abbiamo installato e tentato di eseguire 1416 skill provenienti da varie directory e repository pubblici. Ogni skill è stata sottoposta a una serie di test automatizzati progettati per invocarne le funzionalità principali. I risultati forniscono un quadro molto più chiaro dello stato dell'ecosistema.

Delle 1416 skill che abbiamo testato, solo 889 (63%) hanno superato i nostri test di esecuzione iniziali senza alcun intervento manuale.

Ecco una scomposizione completa dei nostri risultati:

Stato	Conteggio	Percentuale sul totale
Superato (Funziona out-of-the-box)	889	63%
Richiede configurazione (Necessita di config. manuale)	467	33%
Fallito (Prestazioni inferiori al modello base)	60	4%
Totale testato	1416	100%

Analizziamo cosa significa ciascuna di queste categorie per uno sviluppatore che cerca di utilizzare questi strumenti.

Superato (63%): Queste skill si sono installate correttamente e sono state eseguite sul nostro testbed senza errori. Questo è il vero numero di skill funzionanti nel nostro campione, il sottoinsieme immediatamente utilizzabile. Questa è la base di riferimento che un utente dovrebbe aspettarsi da qualsiasi skill elencata in una directory. Tuttavia, come vedremo, "funzionante" non significa automaticamente "di alta qualità."

Richiede configurazione (33%): Questa è una categoria significativa e spesso trascurata. Queste 467 skill non erano rotte, ma non erano plug-and-play. Le ragioni più comuni includevano:

• Richiesta di impostare manualmente API key come variabili d'ambiente.
• Necessità di connettersi a un database fornito dall'utente o a un servizio di terze parti.
• Dipendenza da file locali o configurazioni di sistema non specificate nel file SKILL.md.

Ad esempio, una skill per interagire con un'API di project management è inutile senza una API key e un URL di endpoint. Queste skill non sono dei fallimenti, ma elencarle senza istruzioni di configurazione chiare e preventive è un cattivo servizio per l'utente. Una directory che non distingue tra una skill 'Superato' e una 'Richiede configurazione' presenta un quadro inaffidabile.

Fallito (4%): Questa è la categoria più preoccupante. Queste 60 skill non solo non hanno eseguito la loro funzione, ma hanno prodotto risultati attivamente peggiori rispetto all'uso del modello base senza alcuna skill. Questo accade quando la logica di una skill è difettosa, portando il modello a:

• Bloccarsi in un loop, tentando ripetutamente di chiamare uno strumento non funzionante.
• Avere allucinazioni sull'uso di strumenti che non esistono nella sua stessa definizione.
• Interpretare erroneamente l'intento dell'utente e applicare uno strumento in modo errato, causando errori o output senza senso.

Una skill che abbiamo testato era progettata per formattare snippet di codice. Quando le è stata fornita una semplice funzione Python, ha tentato di chiamare uno strumento format_javascript, ha fallito e ha restituito un messaggio di errore. La stessa richiesta a Claude senza skill avrebbe prodotto uno snippet Python correttamente formattato. Queste 60 skill non sono solo inutili; sono dannose. Nessuna directory affidabile dovrebbe elencarle senza un chiaro avvertimento. Pubblichiamo questi fallimenti perché sono una parte fondamentale dei dati.

Oltre l'esecuzione: cosa definisce la qualità di una skill?

I dati mostrano che circa due skill su tre che potreste trovare funzioneranno. Ma questo risponde solo alla prima parte della domanda. La seconda parte, più importante, riguarda la qualità. La "qualità delle 23000 skill di Claude" non è una questione di quantità, ma di prestazioni.

Una skill che viene eseguita ma svolge il suo compito in modo scadente è poco meglio di una che non funziona affatto. Per questo motivo, dopo che una skill supera il nostro test di esecuzione iniziale, le assegniamo un punteggio su una scala da 1 a 10 in base alle sue prestazioni su una batteria di task del mondo reale. La nostra griglia di valutazione completa è dettagliata nella nostra metodologia, ma si concentra su alcuni principi chiave:

• Affidabilità: La skill riesce costantemente a svolgere il compito dichiarato? Utilizza gli strumenti corretti per il lavoro?
• Accuratezza: L'output è corretto e privo di errori? Se interagisce con un'API, gestisce i dati correttamente?
• Efficienza: Risolve il problema senza passaggi o chiamate a strumenti non necessari?
• Gestione degli errori (Graceful Failure): Quando incontra un caso limite o un input non valido, restituisce un messaggio di errore utile o va in crash?

La differenza tra una skill con un punteggio alto e una con un punteggio basso è netta.

Una skill con un punteggio alto, come uno strumento di infrastruttura cloud ben costruito, interpreterà correttamente una richiesta come "elenca tutte le istanze EC2 in us-east-1", userà il suo strumento list_instances con il parametro region corretto, gestirà la risposta paginata dall'API e presenterà all'utente un elenco pulito e accurato.

Una skill con un punteggio basso potrebbe avere lo stesso obiettivo ma fallire nell'esecuzione. Ad esempio, un altro strumento cloud che abbiamo testato ignorava la regione specificata ed elencava le istanze dalla sua regione predefinita. "Funzionava" nel senso che non andava in crash, ma produceva la risposta sbagliata, rendendolo inaffidabile.

Le 60 skill che hanno ottenuto un punteggio inferiore al modello base rappresentano il livello minimo. Sono una dimostrazione tangibile che una skill progettata male è peggio di nessuna skill. Questo è un dato critico che si perde quando le directory danno priorità alle dimensioni del catalogo rispetto alle prestazioni verificate.

Trovare il segnale nel rumore

La disparità tra le oltre 23.000 skill pubblicizzate e il nostro tasso di successo del 63% nei test evidenzia il problema principale: l'ecosistema è pieno di rumore. Il numero reale di skill funzionali e di alta qualità è una piccola frazione del totale pubblicizzato.

Testare manualmente ogni skill che si trova non è una soluzione pratica per nessuno sviluppatore. Il processo richiede molto tempo e molte risorse. Il nostro test di 1416 skill ha richiesto un notevole sforzo ingegneristico per costruire il test harness e notevoli risorse di calcolo per eseguire le valutazioni. Questo è esattamente il motivo per cui la maggior parte delle directory non lo fa. È molto più facile eseguire uno scraper e pubblicare un numero elevato e non verificato.

L'obiettivo di una directory di skill dovrebbe essere quello di filtrare il segnale dal rumore. Dovrebbe svolgere il lavoro di validazione per conto dell'utente. Ciò significa:

1. Eseguire ogni skill: Una skill non è "verificata" finché non è stata eseguita.
2. Testare la correttezza: La skill deve essere valutata su task reali per vedere se funziona come dichiarato.
3. Pubblicare i fallimenti: Una directory che non mostra ciò che ha fallito nasconde metà della storia. I dati sui fallimenti sono tanto importanti quanto quelli sui successi.

Testando le skill in decine di categorie, dall'analisi dei dati allo sviluppo web, costruiamo una mappa di ciò che funziona, di ciò che necessita di modifiche e di ciò che è da evitare completamente.

Questo approccio basato sui dati è l'unico modo affidabile per rispondere alla domanda: "i marketplace di skill di Claude sono affidabili?". La risposta è: sono affidabili tanto quanto il loro processo di verifica. Un marketplace che è solo un elenco di repository non è una fonte affidabile di strumenti professionali. Una directory che esegue, testa e valuta ogni singola voce fornisce una base di fiducia.

Letture correlate: quante superano effettivamente il modello base · la nostra metodologia di test.

Abbiamo svolto questo lavoro su tutto il nostro catalogo. Le 889 skill che hanno superato i nostri test sono disponibili per la consultazione, complete di punteggi e verdetto sulle loro prestazioni. Per gli sviluppatori che necessitano di un set di strumenti collaudati, offriamo un pacchetto curato delle nostre skill con la valutazione più alta a 10 $, tutte garantite per funzionare e performare come previsto. Questa è la nostra soluzione al problema del rapporto segnale/rumore: un sottoinsieme piccolo, verificato e di alta qualità del vasto ecosistema pubblico non verificato.