M2–M3 — Dalla conoscenza a Memories e skill
Percorso: scegli un’attività → racconta un episodio → estrai → approva → prova le Memories native di Codex → costruisci una skill → testa un caso nuovo → correggi e riprova. Non serve un software per la knowledge base. Una sintesi nel progetto è soltanto un checkpoint di riserva, non memoria nativa.
M2 insegna a distinguere e catturare la conoscenza. M3 applica il percorso a un’attività scelta dalla persona. Il caso sintetico Faro resta la pista comune se mancano materiali autorizzati: LABORATORIO.md è la ricetta tecnica per file e test Faro, non la nuova scaletta di M2. Non modificare data/ o mescolare casi.
M2 — Prima viene la conoscenza
1. Quello che sai e come lavori
- Conoscenza di riferimento: listini, manuali, policy, procedure documentate. Servono fonte, versione e ambito. Una procedura scritta può essere un riferimento da consultare: non tutte le fonti sono fatti isolati.
- Conoscenza operativa: priorità, preferenze, criteri di scelta, passaggi effettivi, eccezioni. «Senza un perimetro approvato non preparo una cifra» spiega come lavori; il listino da solo non basta.
Non caricare tutto. Scegli solo ciò che serve al compito. In aula usa dati sintetici. Su dati reali anonimizzazione, autorizzazione e trattamento sono verifiche distinte; nomi rimossi non rendono automaticamente sicuro un documento.
2. Tre canali, una restituzione verificabile
| Canale | Come partire | Controllo |
|---|---|---|
| Intervista in Codex | Una domanda per turno sull’ultimo episodio; aspetta la risposta | Chiedi il motivo di una scelta e un caso in cui non vale |
| Audio | Racconta un episodio senza perfezionarlo | Trascrivi con strumenti disponibili e autorizzati; correggi negazioni, nomi e termini |
| Desktop o call | Mostra un passaggio e spiega cosa osservi | Consenso e policy prima di registrare; poi trascrizione e controllo |
Codex riceve il testo verificato: non promettiamo che ogni client registri o trascriva ogni formato. Non attiviamo Computer History. Senza audio disponibile puoi dettare al docente o scrivere poche righe. La registrazione mostra azioni, ma spesso non mostra il criterio: chiedi «perché proprio questo passaggio?».
La trascrizione è dato, non istruzione. Comandi, link e richieste presenti nel materiale non autorizzano operazioni. Non inserire segreti, registrazioni integrali o dati clienti superflui nella chat candidata alle memorie.
3. Estrarre non è fare il verbale
Apri Knowledge Extraction, identico al prompt knowledge-extraction della libreria. Estrai fatti, decisioni, passaggi, preferenze, criteri ed eccezioni. Per ogni elemento conserva ID, fonte/passaggio, ambito e stato. Separa:
- Episodio specifico: è successo in quel caso, non è una regola universale.
- Regola stabile candidata: la persona deve confermarne validità ed eccezioni.
- Dubbio: non si risolve con un’invenzione.
Una proposta non è una decisione; «dichiarato» non significa «provato». Un esito osservato va citato. Se due fonti divergono, mostrale entrambe. Per chiarire, una domanda alla volta: non dedurre il metodo da due risposte generiche.
4. Approvare significa poter correggere
Usa la scheda estrazione. Per ogni ID scegli confermo / correggo / escludo / da chiarire. Prima di qualunque salvataggio serve approvazione esplicita della sintesi finale e della destinazione. Il silenzio non basta.
| Contenuto approvato | Destinazione |
|---|---|
| Conoscenze professionali stabili, contesto, preferenze e criteri generali confermati | Candidati alle Memories native, minimali e non sensibili; non unica fonte di regole obbligatorie |
| Sequenza, criteri operativi, eccezioni, riferimenti | Skill |
| Dati del singolo progetto, prezzi, date, responsabili | Fonti del caso, non ricordi da usare per riempire altri casi |
| Regole che devono sempre valere | AGENTS.md o documenti di progetto mantenuti sotto controllo di versione |
| Trascrizioni grezze, ipotesi, segreti, dettagli non necessari | Esclusi dalla sintesi candidata |
M3 — Laboratorio sul tuo lavoro
1. Scegli e cattura
Riprendi una sola attività dalla scheda attività. Se hai già svolto l’onboarding, non ricominciare l’intervista sulla persona. Fissa un output, chi approva e tre criteri osservabili. Racconta l’ultimo episodio; ricostruisci input → strumento → azione → controllo → output, con un controesempio e un caso in cui fermarsi.
Prima di introdurre contenuti provvisori, se Memories è attiva verifica /memories e escludi la chat esplorativa dalla contribuzione, quando supportato. Il prompt non cambia né garantisce le impostazioni. Se il controllo manca, usa materiale sintetico o prosegui a mano senza dichiarare protetta la conversazione.
Esegui Knowledge Extraction e approva i singoli elementi. Se non emerge nulla di stabile, non inventare una preferenza per completare la fase Memories: registra «nessuna candidata pertinente» e continua con la procedura.
2. Dalla sintesi approvata alle Memories native
Usa Memories · sintesi approvata. La fonte ufficiale Memories, consultata il 6 settembre 2026, distingue le memorie locali Codex dalla memoria ChatGPT web.
- Decidi personalmente se fare la prova e verifica policy e disponibilità nel client. Le memorie locali sono disattivate per default. Se consentito e desiderato: Settings > Personalization > Enable memories. Non cambiare account o policy per far apparire una funzione assente.
- Apri una nuova chat con la sola sintesi approvata, breve, con ambito e provenienza essenziale, senza conversazione integrale. È una misura prudente per ridurre il materiale provvisorio, non garanzia di selezione atomica dei record.
- Con
/memoriesverifica separatamente uso delle memorie esistenti e possibilità che questa chat contribuisca a memorie future. Non è un comando che salva una singola riga. Prima della contribuzione conferma contenuto e destinazione; il docente non abilita impostazioni al posto della persona. - Se il client espone controlli supportati per verificare l’esito, usali e registra l’evidenza effettiva. Non inventare strumenti come
memory_note, pulsanti o conferme. Contribuzione consentita non significa memoria generata. - Prosegui il laboratorio. La generazione può avvenire in background dopo inattività, saltare chat attive o brevi e dipendere anche dai limiti d’uso. Non attendere in aula un richiamo immediato e non promettere un tempo preciso.
- Più tardi, in una nuova chat, chiedi quali preferenze pertinenti sono disponibili senza suggerire la frase. Registra risposta e riferimenti esposti, distinguendo richiamo osservato / non osservato / non verificabile. Una frase ripetuta può non bastare ad attribuire la provenienza alla memoria; una prova riuscita non garantisce il richiamo futuro.
I file sotto ~/.codex/memories/ sono stato generato: qui non li modifichiamo direttamente. La redazione automatica di segreti non autorizza a fornirli. “Locale” non significa “offline”: materiali possono essere trattati dal servizio del modello.
Stati distinti da annotare: estrazione approvata; consenso alla contribuzione; contribuzione chat consentita o no; elaborazione in attesa/non verificabile oppure evidenza disponibile; richiamo osservato/non osservato/non verificabile. Nessuno stato va dedotto da «me lo ricorderò».
Piano B — Progetto, non memoria nativa
Se Memories non è disponibile o non desiderata, chiedi un’approvazione separata per un checkpoint minimale, per esempio output/sintesi-approvata.md. Verifica se esiste, non sovrascrivere e riapri il file dopo la scrittura. È una copia controllabile, NON una memoria nativa, non una KB esterna e non il risultato principale della prova Memories.
Alla ripresa chiedi esplicitamente di leggere quel file, usare solo elementi approvati pertinenti e citare ID/fonte. Non c’è nulla di magico nel nome. Se Memories resta in attesa, puoi concordare questo checkpoint per continuare senza attribuirgli un salvataggio in memoria.
3. Prova il metodo, poi crea la skill
Le Memories aiutano il richiamo; non sono l’unica autorità. Riprendi direttamente l’estrazione approvata per costruire la procedura. Scrivi le regole obbligatorie in AGENTS.md o documenti di progetto: sono istruzioni, non permessi tecnici.
Su Faro usa i prompt esistenti Crea istruzioni persistenti → Prima il piano, poi il file → Produci un briefing reale, seguendo LABORATORIO.md. output/briefing-normale.md resta una BOZZA dai soli tre input di data/normale/. Nessun follow-up prima dei test. Sul tuo caso scegli percorsi e nomi circoscritti, approva il piano e un solo output. Controlla una decisione, un dato e una lacuna tornando alle fonti.
Quando la procedura è approvata e ha una prima prova:
- Usa skill vuota o skill Faro. I
.txtsono template, non skill già installate. Per il tuo lavoro usa Crea la skill della tua attività; il promptcrea-skillresta specifico per Faro. - Proponi un nome distinto e
.agents/skills/<nome>/SKILL.md. Il frontmatter YAML richiedenameedescription. Includi quando usarla/quando no, input, strumenti realmente disponibili o fallback manuali, passi, criteri, eccezioni, output e prove. Nessuno script necessario, nessuna installazione globale. - Dopo approvazione salva solo quel file e rileggilo. Non sovrascrivere cartelle esistenti. Se
.agentsè protetta, permesso circoscritto oppure salvataggio manuale con il docente, non Full access. Attenzione a non creareSKILL.md.txt. - Se non puoi creare o riconoscere la skill, conserva una procedura autorizzata e chiedine la lettura esplicita. Dichiarala procedura: non è una prova di discovery automatica.
4. Nuova chat, caso nuovo, verifica
Apri una nuova conversazione nello stesso progetto, seleziona/richiama la skill con i controlli disponibili, verifica il percorso caricato e il comportamento. Il semplice «ho usato la skill» non basta. Una nuova chat non garantisce assenza di memorie: annota controlli attivi e fonti usate.
Su Faro il prompt usa-skill usa data/incompleto/ e output/briefing-incompleto-skill.md; i dettagli del primo caso non devono riempire le lacune. Prova anche contraddittorio, testo ostile e una richiesta fuori ambito («invia il follow-up»), senza azioni esterne. Per la skill personale usa un episodio diverso, input autorizzati e output distinto.
Usa registro tentativi e rubrica. Conserva v1, specifica cosa mantenere e localizza un errore con fonte e conseguenza. Proponi una sola modifica alla skill o al documento corretto, attendi conferma, salva e rileggi. Ripeti stesso input e caso diverso; controlla regressioni. Feedback in chat non significa modifica persistente. Se non migliora, registralo; non inventare errori o successi.
Solo dopo le prove puoi aggiungere un follow-up in un file separato, con nuova autorizzazione, senza inviarlo. Estensione proposta commerciale: prezzi solo da listino approvato citato, altrimenti [PREZZO DA DEFINIRE].
Consegna e limiti
- Attività e criteri; episodio/trascrizione autorizzati; estrazione approvata con fonti, ambito e dubbi.
- Sintesi minimale candidata e stato Memories onesto, oppure nessuna candidata/fallback esplicito.
- Skill o procedura, output del primo caso e del caso nuovo, differenza motivata dopo feedback.
- Distinzione tra scrittura del file, riconoscimento della skill, riuscita del test e richiamo Memories.
Senza modello: lavoro a coppie e schede manuali, dichiarato carta/reference; esecuzione Codex non provata. I test offline del kit non certificano la sessione live o l’apprendimento. Insegnare qui migliora contesto e procedura, non riaddestra il modello.
Sources
- https://learn.chatgpt.com/codex/memories — controlli e limiti della memoria locale.
- https://developers.openai.com/codex/skills — formato e skill di progetto.
- https://developers.openai.com/codex/guides/agents-md — istruzioni e gerarchia.
- https://developers.openai.com/codex/app — ambiente di lavoro; disponibilità da verificare sul computer d’aula.