L'esercizio del pre-work: costruire il VOSTRO progetto — almeno la fase 1, probabilmente di più — usando il loop visto in aula la settimana scorsa:
Com'è andata sul serio? Tre di voi raccontano — due minuti a testa:
La demo gira sul Generatore di Asset — il progetto di L2 (brief di installazione → case study, post, testo sito). Il suo CLAUDE.md ha due settimane di lavoro dentro, come il vostro. E chi l'ha scritto non si accorge più di cosa è invecchiato: lo conosce a memoria, non lo legge davvero. Una sessione NUOVA di Claude lo legge con occhi freschi — e vede quello che voi non vedete più.
"Leggi il CLAUDE.md di questo progetto. Cosa è obsoleto, cosa manca, cosa dovrebbe diventare una regola?"
In L2 le regole vivevano dentro CLAUDE.md. Funziona — finché non diventano venti. Le regole hanno una casa propria:
Valgono in questo progetto. Es.: lo stile Essedi negli asset di marketing.
Valgono in tutti i vostri progetti. Es.: "verifica dalla fonte primaria, non per inferenza".
paths:)Valgono solo per certi file — es. la regola sul naming serve solo per i file in output/. Si carica da sola SOLO quando Claude lavora su quei file; quando non serve, non occupa la sua memoria.
.claude/rules/naming-asset.md». Una regola è solo un file markdown nel posto giusto — la descrivete, non la scrivete.
paths: in cima dice QUANDO si carica — solo quando Claude tocca i file che corrispondono.
.claude/rules/ si carica da solo. Con paths: solo quando Claude tocca i file giusti; senza, sempre. (Volete essere espliciti? Potete richiamarla dal CLAUDE.md — ma non è obbligatorio.)
outputs/) — un refuso: la cartella è output/. La regola non trova nessun file e resta muta. Zero errori, zero avvisi.output/) — stessa richiesta, la regola ora viene rispettata.«Verifica sempre dalla fonte primaria, non per inferenza». Se un dato non ce l'hai davanti, dillo — non riempire il vuoto con ciò che sembra plausibile.
Un'inferenza plausibile ma sbagliata non dà segnale d'errore: sembra giusta finché qualcuno non la verifica. La regola vi obbliga a fermarvi prima.
Non dipende dal progetto: vale per il codice, le email, una ricerca di mercato. Tutto ciò che producete con Claude.
Sullo schermo: la SECONDA cartella del vostro workspace VS Code — ~/.claude, quella che non abbiamo mai aperto. È lì da due settimane e la usate senza saperlo. Apriamo tre cose, in ordine:
model: torna tra mezz'ora e vi farà risparmiare.grill-me. Da Pre-L2. Ora sapete perché funziona in ogni progetto.Una skill è una ricetta, e una ricetta ha due tipi di passi. «Forno a 180 gradi»: un numero fisso, non si discute, non serve talento — quello è un compito da script. «Aggiusta di sale»: bisogna assaggiare e decidere — quello è un compito da Claude.
Due versioni buone possono essere diverse. Il testo di un case study, il tono di un'email, la scelta di cosa evidenziare.
La regola si può scrivere come codice, la risposta deve essere identica ogni volta, o sbagliare è catastrofico: nomi dei clienti, conformità, formati, archiviazione.
"Trasforma il generatore in una skill /pubblica-installazione con quattro passi: valida il brief (script) → genera i tre asset (tu) → controlla la conformità: max 700 caratteri, mai il nome del cliente, HTML valido (script) → archivia e aggiorna il log (script). Gli script esatti ogni volta; la generazione flessibile."
Guardate il passo 2 di /pubblica-installazione: non fa il lavoro — lo AFFIDA. Come un capocantiere: non posa i mattoni, decide chi fa cosa e in che ordine. Qui chiama le tre skill, una per ogni materiale del generatore di L2:
Il capocantiere mette in fila i passi e li affida: alcuni agli script (fissi), alcuni a Claude (giudizio), alcuni ad altre skill. Più template e note di riferimento: questo è un tier-3.
Finora Claude ha lavorato su ciò che sta nei vostri file. Ma il calendario, le email, il gestionale non sono file — sono strumenti. MCP è la presa che li collega.
Email, calendario, database, Notion, fogli di calcolo — se ha una presa MCP, Claude lo può usare.
Claude smette di sapere solo ciò che gli scrivete e comincia a vedere i dati veri, aggiornati, del vostro lavoro.
La colleghi con un login e basta: non si installa niente, non si scrive niente. Come una spina nella presa a muro. Es.: Gmail, Google Calendar, Notion.
Quasi ogni software ne ha una. Non c'è la spina pronta — ma Claude l'adattatore se lo SCRIVE da solo. Es.: Calendly non ha MCP, ha un'API: si collega lo stesso.
Connessione a strumenti esterni. Se un giorno leggete «questo tool non ha MCP», non è un no — è solo una presa diversa.
"Prendi il case study appena generato da /pubblica-installazione e mandalo via email a un collega, chiedendo una revisione entro giovedì."
Non si collega tutto. Si collega ciò che ha già fatto male due volte. A turno, ognuno risponde:
Cercate la presa MCP di quello strumento — o la sua API, se l'MCP non c'è. Solo di quello.
Non ancora. Ed è la risposta giusta: il gate è un filtro, non una vendita.
In /pubblica-installazione l'AI girava solo dove serviva — un passo su quattro. Lo stesso criterio vale DENTRO i passi AI: quale cervello, quanto sforzo.
Haiku: veloce ed economico, per compiti semplici. Sonnet: il quotidiano. Opus: il ragionamento profondo. Si cambia con /model, in un secondo.
Basso: risponde rapido. Alto: riflette più a lungo prima di rispondere — più lento, più accurato. Compito banale → basso. Decisione importante → alto.
La riga model vista nel tour di ~/.claude: cambiatela una volta, ogni sessione parte così.
/usage dentro Claude Code, o claude.ai → Impostazioni → Utilizzo. Lì vedete dove vanno i crediti.
Quello che insegniamo è UN'ABITUDINE: a fine build, non fermatevi a «sembra giusto». Chiedete a Claude: «dimostramelo» — fallo girare, mostrami il risultato, prova i casi limite. Da spettatori a collaudatori: è il salto che rende affidabile tutto il resto.
Claude sbaglia il nome del cliente, il formato, il tono. Una volta.
La correzione si scrive — CLAUDE.md, poi un rule file con la casa giusta.
Il gesto che si ripete diventa un workflow con le mani: script dove serve esattezza.
La regola che continua a fallire diventa enforcement: l'errore non può più accadere.
Il vostro progetto, con le regole e le skill di oggi dentro.
Il metodo completo di "dimostramelo": criteri, test, verifica.
La regola ignorata due volte che avete segnato — la convertiamo insieme.
Codice esatto che la VOSTRA skill chiama. Parte quando lanciate la skill.
Codice esatto che si chiama DA SOLO: a ogni evento, ogni volta, senza che nessuno se lo ricordi.