Scegli il template, compila il caso, controlla il risultato
Sei richieste per pianificare, correggere e revisionare codice con un agente. Ogni template include un esempio e il controllo che ti aiuta a giudicare la risposta.
vibe coding
Nuova app da zero
Per trasformare un’idea vaga in un task iniziale ordinato.
Come compilarlo: Un inventario di libri: titolo, autore e stato letto/non letto. Prima versione in memoria, senza account, ricerca per titolo e messaggio quando la lista è vuota.
Come giudicare il risultato: Devi poter aggiungere un libro, cercarlo e cambiare lo stato. Se il piano introduce pagamenti o login, ha superato il perimetro.
Goal:
Voglio costruire una piccola web app. Aiutami a trasformare l'idea in un piano implementabile.
Idea:
[descrivi cosa deve fare l'app in parole semplici]
Target user:
[chi la userà e perché]
Core features:
- [feature 1]
- [feature 2]
- [feature 3]
Constraints:
- Mantieni la prima versione semplice.
- Non aggiungere parti non necessarie.
- Usa componenti e pattern già presenti nel progetto.
- Prima di scrivere codice, fammi un piano con file da toccare e rischi.
Acceptance criteria:
- L'app ha una prima schermata funzionante.
- Il flusso principale è chiaro.
- La build passa.
- Non vengono introdotti segreti nel frontend.
debug
Fix di un bug
Per dare a Codex o Claude contesto, errore e vincoli.
Come compilarlo: Nel confronto offerte, 85 euro × 12 mesi + 300 euro iniziali venivano indicati come 1.620 euro. Il risultato corretto è 1.320 euro.
Come giudicare il risultato: Ripeti quei dati e almeno un caso con una durata diversa. Una build verde non verifica il risultato del calcolo.
Goal:
Aiutami a risolvere questo bug senza cambiare parti non collegate.
Bug:
[descrivi cosa succede]
Expected behavior:
[descrivi cosa dovrebbe succedere]
Actual behavior:
[descrivi cosa succede davvero]
Error logs:
[incolla errore, stack trace o output del terminale]
Files likely involved:
[se li conosci, elencali]
Constraints:
- Prima leggi il codice collegato.
- Spiega la causa probabile.
- Fai una modifica minima.
- Aggiungi o aggiorna un test solo se il rischio lo giustifica.
- Non fare refactor non richiesti.
Verification:
Dimmi quali comandi devo eseguire per verificare il fix.
feature
Aggiungere una feature
Per chiedere una nuova funzione senza far esplodere lo scope.
Come compilarlo: Aggiungi il filtro “non letti” all’inventario. Il filtro deve nascondere i letti, aggiornarsi dopo un cambio di stato e mostrare un messaggio se non resta nessun libro.
Come giudicare il risultato: Prova una lista mista, una lista tutta letta e il cambio di stato mentre il filtro è attivo.
Goal:
Aggiungi questa feature al progetto esistente.
Feature:
[descrivi la nuova funzione]
User flow:
1. L'utente arriva da [pagina/stato].
2. Compie [azione].
3. Vede [risultato].
Non-goals:
- Non cambiare il design globale.
- Non aggiungere autenticazione.
- Non introdurre servizi esterni.
Acceptance criteria:
- La feature è visibile e usabile.
- Gli stati vuoto, errore e loading sono gestiti se servono.
- Il testo non esce dai contenitori su mobile.
- La build di produzione passa.
Before coding:
Controlla componenti, routing e stili già esistenti.
qualità
Refactor controllato
Per migliorare codice senza cambiare comportamento.
Come compilarlo: Estrai il calcolo canone × mesi + avvio in una funzione pura. Mantieni uguali input, arrotondamento, messaggi e risultato visibile.
Come giudicare il risultato: Confronta prima e dopo su dodici e trentasei mesi, su importi con centesimi e su campi vuoti. Il comportamento richiesto resta il riferimento.
Goal:
Fai un refactor limitato per rendere questo codice più chiaro e mantenibile.
Area:
[file, componente o funzione]
Behavior to preserve:
- [comportamento 1]
- [comportamento 2]
- [comportamento 3]
Constraints:
- Non cambiare API pubbliche se non serve.
- Non cambiare copy o UI senza motivo.
- Non introdurre nuove librerie.
- Mantieni il diff piccolo.
Output:
- Spiega cosa hai cambiato.
- Spiega cosa hai lasciato invariato.
- Indica come verificare che il comportamento sia rimasto uguale.
build
Errore da terminale
Per farsi aiutare dopo una build fallita.
Come compilarlo: Comando: npm run build. Il terminale dichiara che Node 20 non è supportato e richiede una versione successiva. Aggiungi la versione restituita da node --version e il requisito scritto nel README.
Come giudicare il risultato: Allinea il runtime al requisito del progetto e riesegui lo stesso comando. Non modificare il codice applicativo per tentativi prima di capire l’errore.
Goal:
Aiutami a capire e correggere questo errore del terminale.
Command run:
[comando eseguito]
Output:
[incolla output completo, non solo l'ultima riga]
What changed recently:
- [modifica 1]
- [modifica 2]
Constraints:
- Non indovinare: collega l'errore a file e righe.
- Prima proponi la causa più probabile.
- Poi applica il fix minimo.
- Se mancano informazioni, indicami esattamente cosa leggere.
Verification:
Riesegui il comando o spiegami perché non puoi farlo.
github
Descrizione PR
Per trasformare modifiche locali in una descrizione chiara.
Come compilarlo: Il diff modifica la formula del confronto e aggiunge un test. La descrizione deve dire quali dati erano sbagliati, quale risultato cambia e quali comandi sono stati eseguiti.
Come giudicare il risultato: Distingui controlli eseguiti, falliti e non disponibili. Una verifica soltanto proposta non va elencata tra i risultati.
Goal:
Prepara una descrizione PR chiara partendo dalle modifiche locali.
Please include:
- Summary breve.
- Cosa cambia per l'utente.
- File o aree principali toccate.
- Test eseguiti.
- Rischi residui.
Tone:
Tecnico, diretto, niente marketing.
Constraints:
- Non inventare test non eseguiti.
- Se trovi modifiche non collegate, segnalale separatamente.
- Mantieni la descrizione pronta da incollare su GitHub.