L'esercizio del pre-work: costruire la fase 1 del VOSTRO progetto — quello pianificato in L1 e impostato prima di L2 — 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.: "mai lavorare direttamente su main".
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/stile-essedi.md. Quelle con paths: si collegano da sole.
globs:) — la regola viene ignorata su tutti i file. Zero errori, zero avvisi.paths:) — stessa richiesta, la regola ora viene rispettata.La versione ufficiale del progetto — quella che funziona. Si lavora su una COPIA (un «branch») e si porta su main solo ciò che è verificato.
Se sbagliate su main, rompete la versione buona. Se sbagliate su un branch, non succede niente: si butta la copia e si riparte.
Appena il progetto non è più solo vostro: più persone che lavorano insieme, su GitHub. Ci arriviamo — il principio si impara adesso.
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 nate in 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.: Buffer 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. Solo di quello.
Non ancora. Ed è la risposta giusta: il gate è un filtro, non una vendita.
Quando i progetti diventano tre o quattro, ne nasce uno speciale: un progetto centrale che gli altri consultano — stato, decisioni, todo di tutto il vostro lavoro.
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.
Git salva FOTOGRAFIE dell'intero progetto: ogni fase chiusa è una foto a cui poter tornare. «Mai su main» viene da qui — main, branch, commit sono la stessa scatola — e GitHub è dove le foto vivono online, per lavorare in più persone. Claude lo gestisce per voi. E lo dimostriamo: foto della fase 1 → ROMPIAMO il mockup apposta → torniamo indietro con una frase.
"Committa la fase 1 con un messaggio chiaro."
Un'estensione di VS Code: il browser si aggiorna da solo mentre Claude modifica i file. Perché conta: vedete quello che Claude costruisce MENTRE lo costruisce — un errore si vede al secondo, non alla fine. Il ciclo «chiedi → guarda → correggi» diventa istantaneo.
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.