Metodo

Come è fatta una richiesta

1. RuoloChi deve essere il modelloUna competenza precisa, non un generico assistente.
2. ContestoChe cosa deve sapereIl progetto, i vincoli, che cosa è già stato fatto.
3. CompitoUn obiettivo chiaroCon un risultato che si possa verificare. Se gli obiettivi sono due, le richieste sono due.
4. VincoliChe cosa non deve fareTecnologie da non introdurre, file da non toccare, limiti di stile.
5. OutputIn che forma rispondereUn elenco, una tabella, una modifica: qualcosa che si possa controllare.

Prompt e prove

Sul sito precedente questa raccolta si chiamava Vibe Coding

Otto prompt, otto categorie

• ScaffoldingPrima versione, senza fronzoliOttenere qualcosa che funziona subito, senza dipendenze che non servono.

  Che cosa dare al modello

  Cosa deve fare la pagina o il componente, e i vincoli del progetto.

  Risposta attesa

  Il codice completo, le scelte contestabili una per riga, e cosa non funziona senza JavaScript.

  Modello

  Qualsiasi modello recente.

  Testo del prompt

  Sei uno sviluppatore che scrive la prima versione di qualcosa, non la versione definitiva.
  
  CONTESTO
  Ti descrivo una pagina o un componente da costruire. Quello che non ti dico non esiste: non c'è un design system, non c'è una libreria di componenti, non c'è un backend, se non te li do io.
  
  COMPITO
  Scrivi la versione più semplice che funziona.
  
  VINCOLI
  - Nessuna dipendenza esterna: niente framework, niente librerie, niente CDN. Se pensi che una dipendenza sia inevitabile, dimmi quale problema risolve e quanto costerebbe farlo a mano: decido io.
  - HTML prima: la struttura deve avere senso a CSS spento, e il contenuto deve esserci a JavaScript spento. Se una parte può esistere solo con JS, dimmelo al punto 3.
  - Niente astrazioni per un caso solo: una funzione con un solo chiamante è una riga in più da leggere.
  - Non inventare contenuti di riempimento. Se ti serve un testo che non ti ho dato, lascia un segnaposto evidente come [TITOLO], mai lorem ipsum e mai una frase di marketing verosimile.
  - Se la cosa giusta è scrivere meno di quello che ti chiedo, o non scrivere niente, dillo e fermati lì: un elemento HTML nativo che fa già tutto (details, dialog, input con list), tre righe di CSS al posto di uno script. "Non serve scrivere niente" è una risposta valida, e migliore di un componente costruito per abitudine.
  - Non riempire i buchi indovinando: se la richiesta non basta, scrivi la parte chiara e metti il resto fra le domande al punto 4.
  
  OUTPUT
  1. Il codice, completo e pronto da incollare.
  2. Le scelte che ho il diritto di contestare, una riga ciascuna, col perché.
  3. Cosa non funziona senza JavaScript, e cosa vede chi lo ha disattivato.
  4. Le domande che ti restano, se ce ne sono.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. La pagina della raccolta sul sito precedente: otto prompt, filtri per categoria, copia negli appunti e link diretto a ognuno, senza framework, senza bundler e senza passaggio di build. Con JavaScript disattivato i prompt restavano tutti e otto col testo intero; sparivano solo i bottoni Copia.

  Prova consultabile: nessuna.

• RefactoringRefactor senza regressioniRipulire codice che già funziona, senza cambiarne il comportamento.

  Che cosa dare al modello

  Il file da rifattorizzare, per intero.

  Risposta attesa

  Il file riscritto, le modifiche una per riga, e ciò che avrebbe cambiato il comportamento.

  Modello

  Qualsiasi modello recente. Serve contesto lungo: il file entra intero.

  Testo del prompt

  Sei un ingegnere che rifattorizza codice già in produzione.
  
  CONTESTO
  Ti incollo un file che funziona. Non conosci il resto del sistema: quello che non vedi, per te non esiste. Considera pubblico, e quindi intoccabile, ogni nome che il file espone verso l'esterno: funzioni e costanti esportate, nomi di classe e id, attributi data-, chiavi di configurazione, rotte.
  
  COMPITO
  Proponi un refactor che migliori leggibilità e manutenibilità SENZA cambiare il comportamento osservabile.
  
  VINCOLI
  - Nessuna dipendenza nuova.
  - Nessun cambio ai nomi pubblici come definiti sopra, se non te lo chiedo.
  - Se una modifica altera il comportamento, anche di poco, NON farla: elencala al punto 3.
  - Se il file è già in buono stato, dillo e non riscriverlo. "Non c'è niente di utile da fare" è una risposta valida, e migliore di un refactor cosmetico.
  - Se ti manca il contesto per decidere su un punto, lascialo com'è, fai il resto e metti la domanda al punto 5. Non bloccarti e non indovinare.
  
  OUTPUT
  1. Il file rifattorizzato, completo.
  2. Le modifiche, una riga ciascuna, con il perché.
  3. Cosa avrebbe cambiato il comportamento, e che quindi non hai toccato.
  4. Come faccio a verificare che il comportamento sia rimasto identico.
  5. Le domande che ti restano, se ce ne sono.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. Le anteprime dei progetti erano immagini di sfondo in CSS. Un fondo non si può caricare pigramente, e il preload scanner del browser non lo vede mentre scorre l'HTML. Dopo il refactor erano un elemento picture con dentro una img: per chi guardava non cambiava niente, ma la prima anteprima del portfolio si precaricava e le altre tre aspettavano di servire.

  Prova consultabile: nessuna a questo indirizzo; stava in il sorgente del portfolio (/portfolio.html), sul sito precedente.

• DebugDal sintomo alla causaTrovare perché qualcosa non funziona, invece di provare rimedi finché uno passa.

  Che cosa dare al modello

  Il sintomo, come si riproduce, il codice che sospetti e i log che hai.

  Risposta attesa

  Il meccanismo del difetto, come confermarlo, la correzione minima e le ipotesi di riserva.

  Modello

  Qualsiasi modello recente. Serve contesto lungo: il codice sospetto entra intero.

  Testo del prompt

  Sei un ingegnere che cerca la causa di un difetto, non uno che prova rimedi finché uno funziona.
  
  CONTESTO
  Ti do il sintomo, come si riproduce, il codice che sospetto e i log che ho. Non hai accesso all'ambiente: non puoi eseguire niente, non vedi i log che non ti ho incollato, e non puoi provare una modifica per vedere se cambia qualcosa.
  
  COMPITO
  Trova la causa del difetto e dimostrala.
  
  VINCOLI
  - Prima di qualunque rimedio, spiega il MECCANISMO: cosa accade, in che ordine, e perché produce proprio questo sintomo e non un altro. Un rimedio senza meccanismo è una scommessa.
  - Una causa alla volta, in ordine di probabilità. Per ognuna dimmi COME LA CONFERMO con quello che ho a disposizione: un valore da stampare, una riga di log da aggiungere, un caso da provare.
  - Niente rimedi a tappeto: non elencare cinque modifiche sperando che una funzioni. Se non sai quale sia la causa, dillo.
  - Non riscrivere parti che non c'entrano con il difetto, nemmeno se le miglioreresti.
  - Se il sintomo che ti ho descritto non può essere prodotto dal codice che ti ho dato, dillo: vuol dire che la causa sta altrove. "Con questi elementi non si può stabilire" è una risposta valida, e vale più di una causa scelta per non lasciarmi a mani vuote.
  
  OUTPUT
  1. Il meccanismo: cosa succede davvero, passo per passo.
  2. La causa più probabile, e quanto ci credi.
  3. Come la confermo in pochi minuti, senza cambiare il comportamento.
  4. La correzione, la più piccola che risolve.
  5. Cosa altro produrrebbe lo stesso sintomo, se la prima ipotesi cade.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. Il CLS era bimodale: zero in quattro misure su cinque, 0,244 nella quinta. Il sintomo diceva soltanto «a volte», ed è il tipo di difetto su cui si prova un rimedio dopo l'altro. La causa stava nelle icone: ognuna era una legatura tipografica, e finché il font non arrivava il riquadro era largo quanto il nome scritto a lettere, che per arrow_forward sono tredici caratteri. Non serviva un rimedio al CLS, serviva riservare la larghezza.

  Fonte: Lighthouse, cinque esecuzioni sulla home, agosto 2026. La diagnosi per esteso stava nel commento della regola .ms.

  Prova consultabile: nessuna a questo indirizzo; stava in il commento nel CSS (/assets/css/base.css), sul sito precedente.

• ContenutiTesti senza fuffaTogliere numeri senza fonte e promesse non dimostrabili da un testo.

  Che cosa dare al modello

  Il testo da rivedere, così com'è.

  Risposta attesa

  Il testo riscritto, cosa è stato tolto, e le affermazioni su cui devi decidere tu.

  Modello

  Qualsiasi modello recente.

  Testo del prompt

  Sei un editor e togli la fuffa dai testi di un sito professionale.
  
  CONTESTO
  Ti incollo un testo scritto per un sito: una pagina, una sezione o la descrizione di un progetto. Dell'attività di chi lo ha scritto non sai niente oltre a quello che c'è nel testo.
  
  COMPITO
  Riscrivilo perché dica cose vere, concrete e verificabili.
  
  VINCOLI
  - Togli ogni numero che non abbia una fonte e una data. Meglio una frase senza numeri che un numero senza provenienza.
  - Togli superlativi e promesse non dimostrabili: leader, innovativo, soluzioni all'avanguardia.
  - Ogni affermazione deve rispondere alla domanda "come lo so?". Se la risposta nel testo non c'è, va tagliata, oppure riformulata come intenzione dichiarata invece che come fatto.
  - Non aggiungere fatti che nel testo di partenza non ci sono, e non inventare dettagli per riempire.
  - Il testo può accorciarsi, anche di parecchio: è il risultato normale di questo lavoro. Non allungare con giri di parole per tenere la lunghezza originale, perché quella è esattamente la fuffa che stiamo togliendo.
  - Se il testo è già asciutto e verificabile, dillo invece di riscriverlo per forza.
  
  OUTPUT
  1. Il testo riscritto.
  2. Cosa hai tolto, e perché.
  3. Le affermazioni che suonano come fatti ma di cui nel testo non c'è la fonte. Su quelle decido io: elencamele senza tagliarle di tua iniziativa.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. Il titolo della pagina della raccolta prometteva «i prompt che uso» mentre ognuna delle card portava il badge «esempio», che per definizione marca i prompt di partenza, non ancora sostituiti con i propri. Le due cose non potevano essere vere insieme. Non c'era un testo da riscrivere meglio: c'era da decidere quale delle due fosse falsa.

  Prova consultabile: nessuna.

• SEOPerché questa pagina non si indicizzaSeparare ciò che impedisce l'indicizzazione da ciò che la peggiora, con la prova nel codice.

  Che cosa dare al modello

  L'HTML della pagina e, se ce li hai, robots.txt, la sitemap e le direttive del server.

  Risposta attesa

  Cosa impedisce l'indicizzazione, cosa la peggiora, e cosa resta da verificare altrove.

  Modello

  Qualsiasi modello recente. Serve contesto lungo: la pagina entra intera.

  Testo del prompt

  Sei un tecnico SEO e analizzi perché una pagina non viene indicizzata o non viene interpretata correttamente.
  
  CONTESTO
  Ti do l'HTML della pagina e, se ce li ho, robots.txt, la sitemap e le direttive del server. Quello che non ti do non lo puoi assumere: non sai cosa dice Search Console, non sai da quanto la pagina è online, non sai se ha link in entrata.
  
  COMPITO
  Trova cosa, nel codice che ti ho dato, impedisce o peggiora l'indicizzazione.
  
  VINCOLI
  - Segnala solo ciò che puoi dimostrare citando il punto preciso di uno dei file che ti ho dato. Un sospetto che dipende da dati che non hai va nell'elenco "da verificare", non fra i problemi.
  - Tieni separate due cose di natura diversa: ciò che IMPEDISCE l'indicizzazione (noindex, blocco in robots, canonical che punta altrove, redirect, contenuto che esiste solo dopo il JavaScript) e ciò che la PEGGIORA (title, description, gerarchia dei heading, dati strutturati, link interni).
  - Niente consigli generici: "aggiungi parole chiave", "scrivi più contenuto" e "migliora l'autorevolezza" non sono diagnosi e non li voglio.
  - Non inventare volumi di ricerca, posizioni o stime di traffico: sono dati che non hai.
  - Se la pagina è tecnicamente a posto, dillo e fermati. Un elenco vuoto è una risposta valida: il problema può stare fuori dal codice, e in quel caso il codice non è la risposta.
  
  OUTPUT
  1. Cosa impedisce l'indicizzazione, se qualcosa la impedisce: punto del file, effetto, correzione.
  2. Cosa la peggiora, in ordine di impatto.
  3. "Da verificare": cosa non puoi decidere con quello che ti ho dato, e quale dato ti serve.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. /index.html rispondeva 200 esattamente come la radice: due indirizzi per la stessa pagina, cioè un duplicato indicizzabile. Dopo la correzione faceva un 301 sulla radice. La correzione ovvia però innescava un ciclo di redirect, perché la condizione va messa sulla riga di richiesta grezza e non sul percorso: sul percorso colpisce anche la riscrittura interna che il server fa quando serve la pagina indice.

  Prova consultabile: nessuna a questo indirizzo; stava in il redirect di /index.html, sul sito precedente.

• AccessibilitàAudit di accessibilitàTrovare le barriere dimostrabili di una pagina, con il criterio WCAG che le governa.

  Che cosa dare al modello

  L'HTML della pagina e, se ce l'hai, il CSS.

  Risposta attesa

  Problemi ordinati per impatto, più un elenco separato di ciò che resta da verificare.

  Modello

  Qualsiasi modello recente. Serve contesto lungo: la pagina entra intera.

  Testo del prompt

  Sei un esperto di accessibilità web e analizzi una pagina rispetto a WCAG 2.2 livello AA.
  
  CONTESTO
  Ti incollo l'HTML di una pagina. Se ti do anche il CSS, tienine conto. Quello che non ti do non lo puoi assumere: niente JS, niente stati al passaggio del mouse, niente contenuti caricati dopo.
  
  COMPITO
  Trova i problemi di accessibilità dimostrabili dal codice che ti ho dato.
  
  VINCOLI
  - Segnala come problema solo ciò che puoi dimostrare citando il punto preciso del codice. Se una cosa ti insospettisce ma dipende da CSS, JS o contenuti che non hai visto, va nell'elenco "da verificare", non fra i problemi.
  - Cita sempre il criterio con numero e nome, per esempio 2.5.3 Label in Name.
  - Per ogni problema: dove sta, perché è un ostacolo per una persona reale, e come si corregge.
  - Ordina per impatto: prima ciò che impedisce l'uso, poi ciò che lo peggiora, infine le rifiniture.
  - Niente aria-label a tappeto: l'ARIA serve solo dove l'HTML nativo non basta. Se la correzione giusta è cambiare elemento invece di aggiungere ARIA, dillo.
  - Se la pagina è a posto, dillo e fermati. Un elenco vuoto è una risposta valida: non allungarlo con problemi marginali per sembrare utile.
  
  OUTPUT
  1. I problemi, ordinati per impatto: criterio, punto del codice, perché è un ostacolo, correzione.
  2. Il codice corretto, per intero, dei soli problemi che impediscono l'uso.
  3. "Da verificare": ciò che non puoi decidere senza vedere altro, e cosa ti serve per deciderlo.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. Il bordo dei campi e dei bottoni con solo contorno era #d1d7e2, cioè 1,37:1, sotto la soglia di 3:1 che vale per gli elementi di interfaccia. Dopo la correzione era #7c8dad, 3,01:1. Il contrasto va verificato sul fondo peggiore su cui quel bordo può capitare: misurato sul bianco sarebbe passato anche un colore che sul grigio della pagina scendeva a 2,87:1.

  Fonte: contrasto calcolato secondo WCAG 2.1 SC 1.4.11, agosto 2026. Le coppie prima e dopo erano elencate in cima al foglio dei colori.

  Prova consultabile: nessuna a questo indirizzo; stava in la tabella dei contrasti (/assets/css/tokens.css), sul sito precedente.

• PrestazioniCaccia al layout shiftRisalire alla causa di un CLS invece di tirare a indovinare.

  Che cosa dare al modello

  HTML, CSS e il JS che gira al caricamento. Se ce l'hai, l'elenco degli spostamenti dal pannello Performance.

  Risposta attesa

  La causa più probabile con quanto ci crede, come confermarla, la correzione e cosa rimisurare.

  Modello

  Qualsiasi modello recente. Serve contesto lungo: HTML, CSS e JS insieme.

  Testo del prompt

  Sei un ingegnere delle performance web e cerchi la causa di un Cumulative Layout Shift.
  
  CONTESTO
  Ti do il codice della pagina: HTML, CSS e il JS che gira al caricamento. Attenzione: il CLS è un fenomeno di runtime, e il codice da solo può non bastare. Se ho l'elenco degli spostamenti dal pannello Performance del browser, o da un PerformanceObserver su 'layout-shift' (che dice QUALE elemento si è spostato e di quanto), te lo do insieme al resto: quel dato vale più di qualunque ipotesi fatta leggendo il codice.
  
  COMPITO
  Trova cosa sposta il layout e perché, poi proponi la correzione.
  
  VINCOLI
  - Parti dai sospetti tipici: immagini, iframe e video senza dimensioni dichiarate; font che cambiano metrica quando arrivano; contenuto iniettato da JS sopra a contenuto già visibile; CSS che arriva dopo il primo paint; animazioni su proprietà che causano layout; comparsa di scrollbar, banner o barre sticky.
  - Quella lista non è esaustiva: se la causa sta fuori, dillo, invece di incastrarla per forza in una voce.
  - Per ogni sospetto dimmi COME verificarlo, non solo che esiste.
  - Le correzioni non devono cambiare l'aspetto finale della pagina.
  - Se quello che ti ho dato non basta per decidere, dimmi quale misura mi serve e come la ottengo, invece di eleggere una causa a caso. "Con questi dati non si può stabilire" è una risposta valida.
  
  OUTPUT
  1. La causa più probabile, il ragionamento che ti ci porta e quanto ci credi.
  2. Come confermarla in due minuti.
  3. La correzione, in codice.
  4. Cosa rimisurare dopo, e quale valore ti aspetti.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. I font di testo avevano un ripiego a metriche compensate: non scaricavano niente, prendevano un carattere già presente sul sistema e ne correggevano le proporzioni perché coincidessero con quelle del font vero. Lo spostamento allo scambio dei font scendeva da 100 a 24 px sull'altezza della home, e i 24 che restavano erano una voce sola: un titolo che col ripiego stava su una riga e col font vero su due.

  Fonte: misurato in Chromium sull'altezza della home, font bloccato contro font caricato, 18 agosto 2026

  Prova consultabile: nessuna a questo indirizzo; stava in le due famiglie di ripiego (/assets/css/base.css), sul sito precedente.

• AutomazioneAutomatizza un controllo ripetitivoTrasformare una verifica manuale in uno script che dice, senza ambiguità, se è passata.

  Che cosa dare al modello

  Il controllo che fai a mano, quante volte lo fai e cosa guardi per decidere se è andato bene.

  Risposta attesa

  Lo script, come lanciarlo, come farlo fallire apposta, e cosa resta scoperto.

  Modello

  Qualsiasi modello recente.

  Testo del prompt

  Sei uno che automatizza un controllo manuale ripetitivo, sapendo che poi l'automazione va mantenuta.
  
  CONTESTO
  Ti descrivo un controllo che oggi faccio a mano: cosa guardo, quante volte lo faccio, e come decido se è andato bene. Dell'ambiente in cui girerà lo script sai solo quello che ti dico.
  
  COMPITO
  Scrivi lo script che esegue quel controllo e dice senza ambiguità se è passato.
  
  VINCOLI
  - Dipendenze al minimo, e per ognuna dimmi perché la libreria standard non basta.
  - Lo script esce con codice 0 se il controllo passa e diverso da zero se fallisce, e stampa COSA è fallito, non solo che è fallito.
  - Nessun valore scritto dentro al codice che io debba cambiare a mano ogni volta: se un valore cambia, sta in cima al file o arriva da un argomento.
  - Il controllo osserva e riferisce: non modifica, non cancella, non crea niente. Se per verificare servisse davvero scrivere qualcosa, dimmelo prima invece di farlo.
  - Un controllo che passa sempre non serve a niente: dimmi come faccio a vederlo FALLIRE apposta, così so che è vivo.
  - Se quello che voglio è già coperto da uno strumento standard che non ho nominato, dimmelo invece di riscriverlo. "Esiste già, si chiama così" è una risposta valida.
  
  OUTPUT
  1. Lo script, completo.
  2. Come lo lancio, e cosa stampa nei due casi.
  3. Come lo faccio fallire apposta, per verificare che il controllo sia vivo.
  4. Cosa NON copre, e che quindi resta da guardare a mano.

  Documentazione del lavoro

  Risultato osservato sul sito precedente. Il controllo che decideva se il sito precedente si poteva caricare: un'invariante per sezione, nessuna dipendenza, usciva con codice diverso da zero e stampava cosa non tornava invece del solo fatto che qualcosa non tornava. Accanto ce n'era un secondo che rompeva il repository un pezzo per volta, per verificare che il primo fallisse davvero, più un caso che pretendeva il silenzio invece dell'allarme.

  Prova consultabile: nessuna a questo indirizzo; stava in il case study del controllo pre-deploy (/portfolio/verifica-pre-deploy.html), oggi raccontato in questa pagina, sul sito precedente.