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:
Il CLAUDE.md del progetto demo ha due settimane di lavoro dentro — come il vostro. Chi l'ha scritto non vede più cosa è invecchiato. Una sessione fresca sì.
"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:)Si attivano da sole solo quando Claude tocca i file giusti. Zero contesto sprecato.
.claude/rules/naming-asset.md. Non la scrivete voi — la descrivete a Claude.
paths: in cima al file dice QUANDO si carica: solo quando Claude tocca i file che corrispondono. Regola giusta al momento giusto.
@.claude/rules/stile-essedi.md. Quelle con scope si caricano da sole.
globs:) — la regola viene ignorata su tutti i file. Zero errori, zero avvisi.paths:) — stessa richiesta, la regola ora viene rispettata.È nel vostro workspace VS Code da due settimane — la seconda cartella, quella che non abbiamo mai aperto. La usate senza saperlo:
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. "Forno a 180 gradi" non si chiede allo chef di intuirlo — è lo script. "Aggiusta di sale" è giudizio — è 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 genera — DELEGA. Chiama le tre skill nate in L2. La skill è un direttore d'orchestra, non un generatore.
Il direttore sequenzia passi deterministici e passi AI, e delega alle skill figlie. Più template e note di riferimento come file di supporto: questo è un tier-3.
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.
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.
MCP è la presa standard, pronta all'uso. API è la presa propria dello strumento: Claude può usarla lo stesso — il collegamento lo scrive lui. Es.: Buffer non ha MCP, ma ha un'API. Il concetto è uno solo: connessione a strumenti esterni.
"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ì.
Version control senza impararlo: Claude esegue git per voi. E lo dimostriamo: committiamo la fase 1, ROMPIAMO il mockup apposta, e torniamo indietro con una frase. Ogni fase chiusa è un posto sicuro a cui tornare.
"Committa la fase 1 con un messaggio chiaro."
Un'estensione di VS Code: il browser si aggiorna da solo mentre Claude modifica i file. Il mockup HTML di L2, ma vivo — niente più refresh a mano.
Da oggi, una domanda in più a fine build: "dimostramelo". Chiedete a Claude di provare che ciò che ha costruito funziona davvero — non di mostrarvelo, di provarlo.
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.