Una skill è un pacchetto di istruzioni e risorse che un agente AI può caricare per un’attività. Prima di aggiungerla, conviene capire quale errore dovrebbe aiutarci a evitare. Un agente può produrre una buona risposta anche senza quel pacchetto; una procedura utile può invece sembrare inefficace se la valutiamo nel momento sbagliato.
Per rendere concreta questa scelta, il confronto qui esamina due procedure pubbliche: grilling, usata da grill-me di Matt Pocock per chiarire decisioni, e una parte di Supabase Postgres Best Practices per ragionare sulle query. I casi mostrano una differenza puntuale nel piano di verifica SQL, diversi risultati equivalenti e un limite della griglia usata per giudicare l’intervista. Sono elementi con cui decidere che cosa provare nel proprio lavoro, prima di adottare una skill.
Che cosa aggiunge il pacchetto
Nel formato Agent Skills, SKILL.md contiene metadati e istruzioni; la cartella può includere riferimenti, script e modelli di documento. La procedura può indicare all’agente quali informazioni raccogliere, come ordinare le decisioni o quali controlli eseguire. Gli strumenti e gli accessi necessari dipendono dall’attività.
Per esempio, le istruzioni per leggere un piano SQL non forniscono automaticamente una connessione al database. Analogamente, chiedere all’agente di seguire un’intervista non dimostra che il client sappia scoprire e invocare il plugin che la distribuisce. La guida su costruzione e attivazione delle skill tratta quel passaggio; qui interessa il contenuto delle risposte dopo la lettura delle istruzioni.
La versione di grilling esaminata organizza le decisioni in base alle dipendenze. In ogni turno chiede ciò che può essere deciso senza presumere risposte ancora mancanti; attende il riscontro prima di proseguire. Il wrapper grill-me richiama questa procedura.
Per Supabase sono stati selezionati il file principale e tre riferimenti: indici mancanti, indici composti e diagnosi con EXPLAIN ANALYZE. È una porzione della raccolta, sufficiente per i casi scelti. Entrambi i repository usano la licenza MIT; i collegamenti fissano le revisioni lette, così eventuali aggiornamenti restano distinguibili.
Il confronto e il suo perimetro
Il metodo parte dal confronto con e senza istruzioni aggiuntive descritto nella guida di valutazione Agent Skills. Il 26 ottobre 2026 sono state raccolte dodici prime risposte: sei casi sintetici, ciascuno assegnato a due agenti separati. Una condizione riceveva il caso e una richiesta circoscritta; l’altra aggiungeva la lettura della procedura e dei riferimenti selezionati.
Le sessioni usavano lo stesso modello nominale, gpt-6-astra, con ragionamento ultra, e partivano senza la conversazione dei trial precedenti. Condividevano però le istruzioni dell’ambiente e il catalogo delle skill. La build esatta del modello non era esposta. Il protocollo, i file di input e i criteri erano stati fissati prima delle risposte; le tracce permettono di verificare letture e output, mentre il testo integrale degli incarichi trasmessi non è ispezionabile nell’audit.
Sono state caricate istruzioni manualmente, senza installare i plugin. Nessun database è stato interrogato: schemi, piani e tempi SQL erano dati inventati per gli esercizi. Per ogni caso è stata raccolta una sola risposta per condizione, limitata al primo turno. Il confronto descrive quei testi; non misura affidabilità, risparmio di token, durata del lavoro o qualità di un’intervista completa.
Una richiesta chiara può già bastare
Il caso sui requisiti già definiti descriveva un report settimanale degli ordini: destinatari autorizzati, soli aggregati, intervallo temporale, accesso al documento, conservazione, ritentativi e responsabilità erano tutti stabiliti. La domanda era se mancasse una decisione di prodotto necessaria per iniziare la progettazione.
Entrambe le risposte hanno riconosciuto che si poteva procedere, senza inventare un ostacolo o riaprire decisioni approvate. Quella con grilling ha spiegato che non restavano decisioni aperte; quella senza procedura è arrivata allo stesso esito.
Questo caso era stato scelto proprio per osservare se l’intervista sapesse fermarsi. Lo ha fatto anche la risposta di partenza. Per una richiesta così definita, il risultato non offre un motivo per aggiungere la procedura. Resta da capire che cosa succede quando il problema è meno preparato.
Un altro caso presentava due requisiti incompatibili: inviare dati nominativi come allegato leggibile senza account, oppure mostrare soltanto aggregati nell’area autenticata. Entrambe le risposte hanno chiesto una decisione autorizzata senza inventare un accordo. Con la procedura, la prima domanda riguardava soltanto chi avesse l’autorità di risolvere il conflitto; senza, veniva chiesto anche quali requisiti sarebbero stati confermati. La differenza riguarda la sequenza. Contare le domande non dice quale intervista porterà prima a una decisione valida.
SQL: una differenza utile e due controprove
Nel caso selettivo, una query restituiva 100 righe su un milione filtrando per cliente e stato. L’unico indice disponibile era sulla chiave primaria. Il piano sintetico mostrava una scansione della tabella; lo scenario includeva anche circa 200 scritture al secondo, per rendere visibile il costo di mantenere un nuovo indice.
Entrambe le risposte hanno proposto un candidato plausibile. Quella senza procedura ha scelto un indice sulla colonna cliente, limitato agli ordini pending; quella con procedura un indice composto su cliente e stato. Sono alternative da valutare sul carico, non una risposta corretta e una sbagliata.
La differenza più utile era nel piano di verifica. La risposta con procedura richiedeva esplicitamente un confronto prima/dopo in condizioni rappresentative. L’altra chiedeva di verificare piano, tempi e impatto sulle scritture con l’indice, ma lasciava meno chiaro il riferimento misurato senza indice. Il valutatore ha mantenuto questo requisito come non determinabile, anziché considerarlo soddisfatto. È una lacuna circoscritta nella risposta, non la prova che la skill migliori stabilmente la diagnosi.
Le altre due situazioni mettevano alla prova la tendenza a prescrivere indici troppo presto:
| Caso sintetico | Risposta senza procedura | Risposta con procedura |
|---|---|---|
| Esportazione del 95% delle righe; indice sullo stato già presente | La scansione sequenziale è plausibile; misurare l’esportazione completa | Stessa decisione; nessun motivo per duplicare o forzare l’indice |
| Segnalazione di lentezza con solo piano stimato | Raccogliere tempi, distribuzione e indici esistenti prima di modificare | Stessa decisione; il costo stimato non viene scambiato per millisecondi |
Il primo controcaso è rilevante perché il riferimento Supabase esaminato contiene la scorciatoia “Seq Scan on large tables = missing index”. È troppo assoluta: leggere quasi tutta una tabella può rendere appropriata una scansione sequenziale. La documentazione PostgreSQL su EXPLAIN mostra come il piano dipenda dalla selettività e distingue i costi stimati dai tempi effettivi.
La risposta con procedura ha corretto la scorciatoia alla luce del caso. Questa risposta non basta a valutarne l’effetto su altri input: prima di riusare la skill, conviene correggere la formulazione che trasforma un indizio in una diagnosi.
Per una verifica reale, EXPLAIN ANALYZE esegue la query: va usato con accessi e condizioni adatti al carico.
Quando il test giudica il turno sbagliato
Il caso con requisiti incompleti chiedeva di chiarire un report automatico senza scegliere al posto del responsabile di prodotto. La griglia preparata prima delle prove richiedeva già nel primo turno domande su destinatari, contenuto e consegna.
La risposta senza procedura le includeva. Quella con grilling chiedeva prima scopo, destinatari e responsabilità operativa, rinviando esplicitamente contenuto e consegna alle risposte successive. Per la griglia, due requisiti mancavano.
Quel risultato va conservato, ma la sua interpretazione cambia dopo aver letto la procedura: rinviare una decisione dipendente è proprio ciò che grilling chiede di fare. Il test misura la copertura del primo turno; non stabilisce se l’intervista avrebbe dimenticato quei temi. Per valutarla servirebbe proseguire entrambe le conversazioni con risposte coerenti e confrontare le decisioni irrisolte alla fine, le assunzioni introdotte e le domande premature. Questo confronto completo resta da svolgere.
Che cosa terrei nel catalogo
La scelta che propongo è legare ogni skill a un errore ricorrente e a una verifica mantenibile. Se l’agente omette il confronto prima/dopo, una procedura che lo rende esplicito merita una prova sul proprio carico. Se sa già riconoscere dati insufficienti, aggiungere istruzioni va giustificato da un’altra esigenza concreta.
Prima dell’adozione sceglierei un’attività reale, una richiesta di partenza ragionevole e un risultato verificabile. Aggiungerei un caso in cui la procedura dovrebbe fermarsi o non intervenire. La durata della prova deve corrispondere al lavoro promesso: una prima risposta può bastare per esaminare una diagnosi iniziale; per un’intervista conta anche ciò che emerge nei turni successivi.
Conserverei poi la revisione della skill, gli input e gli errori trovati, assegnando a qualcuno la responsabilità di aggiornare istruzioni e casi. Per le procedure con script o servizi esterni, strumenti, credenziali e permessi vanno esaminati insieme al testo. Un risultato equivalente alla richiesta di partenza non giustifica da solo un nuovo elemento da mantenere. Queste dodici risposte aiutano a scegliere il prossimo controllo; l’adozione richiede che quel controllo risolva un problema del proprio lavoro.