Idea Organizer, da GPT personalizzato a plugin

OpenAI ha annunciato il ritiro dei GPT personalizzati per l'11 dicembre 2026. Un modo per mantenerli è trasformarli in plugin, ho applicato questo processo a uno dei miei GPT personalizzati, Idea Organizer, utilizzando la funzione di migrazione disponibile nell'account. In questo passaggio ho rivisto il comportamento dello strumento insieme a Codex. Il plugin ora analizza gli appunti, apre un breve confronto con l'utente e richiede due approvazioni prima di produrre il documento. Il caso mostra quali elementi si trasferiscono, quali richiedono una revisione e come controllare il risultato prima di condividerlo.

Che cosa passa dal GPT al plugin

Idea Organizer trasforma un testo disorganizzato, una trascrizione di una registrazione audio o anche un testo scritto velocemente, in un documento strutturato utile per successive analisi.
Un GPT personalizzato raccoglie istruzioni, eventuali file di conoscenza e capacità selezionate. Un plugin può riunire una o più skill, cioè procedure riutilizzabili, ed eventuali collegamenti a servizi esterni. Nel caso di Idea Organizer, la parte centrale è una skill, descrive quando intervenire, quali passaggi seguire e quando fermarsi per chiedere una decisione all'utente. La documentazione OpenAI sulle skill dei plugin spiega questa struttura.

Il processo di migrazione previsto da OpenAI prende l'ultima versione pubblicata del GPT, le istruzioni diventano una skill, i file di conoscenza vengono copiati come materiali di riferimento e le app collegate entrano nel plugin. Le conversazioni precedenti non vengono trasferite. Neppure il modello selezionato nel GPT passa al plugin. Le custom actions, cioè i collegamenti del GPT a servizi esterni configurati dal suo creatore, richiedono una soluzione separata. La migrazione non le converte automaticamente.

Il trasferimento dei file, inoltre, non garantisce che le istruzioni siano già adatte alla nuova situazione. Una procedura può contenere riferimenti a funzioni del GPT, presupporre strumenti che ora non sono disponibili o lasciare implicite decisioni che andrebbero concordate. In Idea Organizer il punto da rivedere era proprio il processo con cui si passa da note disordinate a un documento finito.

Perché il plugin deve chiarire gli appunti

La descrizione iniziale presentava Idea Organizer come uno strumento per trasformare una bozza caotica in un documento ordinato. Restavano però da definire il trattamento degli appunti incompleti, la scelta del documento e il momento in cui l'utente corregge l'interpretazione del plugin.

Nella conversazione ho precisato una situazione comune. Gli appunti possono essere scarsi perché scritti in fretta, oppure perché l'idea non è ancora chiara nemmeno a chi li ha prodotti. In entrambi i casi, partire subito con la riscrittura può fissare nel testo una lettura parziale se non persino sbagliata. Per questo il plugin comincia dall'analisi del materiale originale, seguito da un brainstorming breve, limitato alle domande necessarie per capire meglio la richiesta.

Le domande dipendono dalle lacune e dalle ambiguità presenti nel materiale, il confronto aiuta il plugin a interpretare gli appunti e l'utente a chiarire a sé stesso ciò che vuole ottenere.

Due verifiche prima di produrre il documento

Dopo l'analisi e il breve brainstorming, Idea Organizer propone una sintesi degli appunti e dei chiarimenti ricevuti. L'utente può correggerla, il plugin continua il suo lavoro solo dopo l'approvazione della sua analisi.

A quel punto si passa alla fase di generazione dell'output. Se l'utente ha già indicato un formato, il plugin lo esamina e propone la struttura del documento coerente con la sintesi approvata. Se dall'analisi risulta più adatto un formato diverso, il plugin lo segnala e spiega perché; la decisione resta all'utente. Se il formato non è stato richiesto, viene suggerito in base all'analisi. Anche formato e struttura richiedono un'approvazione esplicita prima della stesura.

Con la prima approvazione l'utente verifica l'interpretazione del materiale, le proprie intenzioni e i punti ancora aperti. Con la seconda approva il formato e la struttura del risultato.

Solo dopo queste due verifiche il plugin produce il documento. Se durante la scrittura si rende necessario un cambiamento sostanziale, deve renderlo esplicito prima di applicarlo. L'output può essere una scaletta, un testo completo, una relazione o un altro formato ancora. Un elenco chiuso avrebbe escluso alcuni risultati utili che l'analisi può suggerire.

In una prova ipotetica una persona consegna tre appunti e chiede una relazione. Idea Organizer deve prima dire che cosa ricava dagli appunti e quali dubbi restano. Dopo il chiarimento propone una sintesi, che la persona può correggere. Quando la sintesi è approvata, propone l'indice della relazione. Se dagli appunti risulta che serve soprattutto una decisione operativa, può suggerire una scheda di confronto e motivare la proposta. La persona decide quale formato usare.

Dalla conversazione alle istruzioni della skill

Il lavoro con Codex è stato iterativo. Ho aggiunto un vincolo alla volta, controllando le proposte e correggendo i punti in cui la procedura non rispecchiava ancora il modo in cui volevo usare lo strumento. Si tratta di vibe coding, si definisce il comportamento in linguaggio naturale, l'assistente lo traduce in un plugin funzionante che viene poi verificato. Per il ruolo della verifica nel vibe coding rimando al mio percorso sul metodo e sui suoi confini.

Il risultato di questo lavoro è soprattutto un insieme di istruzioni. Il plugin è stato organizzato come una skill che si attiva quando viene invocato e guida l'assistente attraverso l'analisi, il chiarimento, la sintesi, la scelta del formato e la produzione. Ho chiesto anche di aggiornare i riferimenti agli strumenti disponibili. Il plugin deve usare quelli presenti nella sessione, senza promettere funzioni che non ha.

Il caso richiama un tema già trattato sul blog a proposito delle skill come istruzioni per un metodo di lavoro. Una skill efficace descrive le decisioni e il loro ordine. Qui l'ordine impedisce che un'interpretazione non verificata diventi subito un documento definitivo.

Come affrontare il passaggio del proprio GPT

Ovviamente il percorso seguito con Idea Organizer può essere riutilizzato anche per altri GPT, adattandolo alla loro funzione. Conviene cominciare esaminando istruzioni, file, prompt di avvio e collegamenti del GPT esistente. OpenAI indica di salvare alcuni prompt abituali per confrontare le risposte del plugin con quelle del GPT. Quando la migrazione è disponibile nell'account, il comando "Migrate to plugin" si trova in "My GPTs". La migrazione usa l'ultima versione pubblicata del GPT. Eventuali modifiche rimaste in bozza non entrano nel trasferimento.

Dopo la migrazione, il GPT originale resta utilizzabile fino al ritiro, ma diventa di sola lettura. Le modifiche successive vanno fatte sul plugin. Per questo conviene completare nel GPT le revisioni che devono entrare nella versione trasferita. Il nuovo plugin non eredita nemmeno le impostazioni di condivisione del GPT. Chi usava il vecchio strumento non ottiene automaticamente l'accesso al sostituto.

Dopo la creazione, bisogna verificare se la skill si attiva al momento giusto, legge i materiali pertinenti e pone le domande necessarie. Occorre poi confrontare il risultato con quello previsto. Un caso semplice e uno più difficile possono mostrare differenze che una sola prova non rileva. I collegamenti esterni vanno verificati a parte, soprattutto se il GPT usava custom actions.

Per Idea Organizer le prove più utili riguardano i punti in cui l'assistente potrebbe anticipare una decisione. Una bozza volutamente incompleta permette di vedere se il brainstorming chiarisce davvero il contenuto. Una richiesta di produrre subito il testo permette di osservare se il plugin presenta comunque la sintesi da approvare. Un formato già richiesto dall'utente mostra se il plugin lo rispetta o se propone un'alternativa con una motivazione comprensibile. Occorre controllare anche che sappia fermarsi quando manca il materiale iniziale. Questi casi verificano che il plugin segua la sequenza concordata.

Il plugin ottenuto dalla migrazione nasce privato. Per la distribuzione pubblica OpenAI prevede una candidatura separata, con verifica dell'identità dello sviluppatore, informazioni per la scheda, casi di test e revisione. Solo dopo l'approvazione lo sviluppatore può pubblicarlo. Al momento il mio nuovo plugin è ancora personale, in attesa della revisione.