Come parliamo
con Claude.

Claude legge le parole che gli scrivi. Tutte. Più sei specifica, meno deve indovinare.

Le skill non sempre si attivano da sole. Forzare l'attivazione all'inizio del prompt cambia la qualità del risultato.

La trappola peggiore: chiedere "tutto perfetto al primo colpo". Pattern che funziona:

1. Struttura — chiedi prima il layout, header, blocchi vuoti.
2. Vedi — apri in browser, guarda che ne pensi.
3. Rifinisci — chiedi modifiche concrete su quello che esiste.

Tre giri da 5 minuti battono un giro da 30 minuti, sempre.

Trascina screenshot direttamente nella chat. Funziona per: layout di riferimento, errori visivi, mockup Figma, documenti scansionati, tabelle complesse.

Spesso uno screenshot vale 200 parole di descrizione. "Fai così, ma con i nostri colori" + immagine = risultato in 2 minuti.

Copia/incolla l'errore esatto. Tutto il messaggio, tutto lo stack trace. Niente parafrasi, niente "non funziona". Claude legge bene gli errori.

Se il bug è in browser: copia console + network. Se è in build: copia l'output di npm run build dal primo errore in poi.

Bonus: per bug strani, prefissa il prompt con "Usa la skill systematic-debugging".

• Mai credenziali in chiaro nei prompt. Né API key, né password, né token. Se serve, usa env vars referenziate per nome.
• Mai modifiche distruttive senza branch. Niente git reset --hard, rm -rf su cose preziose, DROP TABLE in prod.
• Mai DB di produzione direttamente. Migrations versionate, applicate da CLI con review. Console Supabase prod = solo lettura.
• Mai file .env committati. Devono essere in .gitignore e basta.

I subagent sono potenti, ma lenti da gestire. Vale la pena solo se:

• Il task richiede >1h di lavoro lineare.
• Ci sono 2+ task veramente indipendenti (es: generare 6 OG image diverse).
• Vuoi mantenere il contesto principale pulito mentre uno scava in profondità.

Non usare subagent per: cambiare un copy, aggiungere un link, fixare un import.

Crea un branch sandbox/<nome> ogni volta che:

• Vuoi iterare a lungo senza paura di rompere prod.
• Stai esplorando un'idea che potrebbe finire in cestino.
• Lavori in parallelo con qualcun altro su un'altra parte del sito.

Per fix banali su main va bene direttamente. Il branch è sicurezza, non burocrazia.

La regola più importante. Mai dire "fatto" prima di:

1. npm run build verde in locale.
2. npm run smoke verde dopo deploy (32/32 check).
3. curl della URL nuova ritorna 200 con il contenuto giusto.
4. Apertura in browser incognito + hard reload.

La skill verification-before-completion è il tuo amico — usala come prefisso.

Quando trovi un pattern utile, una decisione importante, un fix ricorrente — scrivilo subito:

• Pattern di studio → qui, in /handbook.
• Decisioni progetto-specifiche → in CLAUDE.md del progetto.
• Note personali / preferenze → in ~/.claude/projects/<id>/memory/MEMORY.md.

La memoria che non scrivi nel momento giusto, la perdi.