Prompt di avvio progetto per Cursor e ChatGPT: regole e vincoli che ti danno già un vantaggio
Un prompt di avvio per Cursor e ChatGPT con regole e vincoli base su cartelle, segreti e sicurezza. Copialo, compilalo e parti con un vantaggio concreto.
Apri Cursor o ChatGPT: cursore lampeggiante, idea chiara a grandi linee. Il primo messaggio può orientare qualità e sicurezza di tutto ciò che segue.
Il riflesso tipico è: «Crea un’app in Python che faccia X e Y». Lasciata a sé, l’IA può prendere la scorciatoia: mescolare core e UI, inventare pacchetti, mettere chiavi in chiaro nei sorgenti. Ne abbiamo parlato nei rischi del vibe coding.
Qui un approccio diverso: un prompt di avvio (kickoff) da incollare prima di chiedere la prima riga di codice. Non rende l’app impenetrabile. Fissa paletti misurabili: stack, segreti, moduli uno alla volta.
Perché il mega-prompt fallisce
Nel vibe coding gira l’idea che un prompt enorme al minuto zero produca un’app «completa e sicura». Nella mia esperienza i mega-prompt spesso falliscono: vincoli dimenticati a metà, contesto perso, blocchi enormi difficili da verificare.
Il kickoff è l’opposto dell’implementazione. Non costruisce l’app: istruisce l’assistente su come comportarsi dopo.
| Approccio | Esito tipico | Perché |
|---|---|---|
| Mega-prompt «Crea tutta l’app con UI e DB» | Caos | Attenzione diluita: sicurezza e confini **possono** sparire; responsabilità mescolate. |
| Prompt di avvio Regole e stack prima del codice | Controllo | Accetta le regole d’ingaggio e attende il primo task mirato. |
Allineato all’architettura vibe-coded: cartelle e moduli prima del monolite.
Il prompt di avvio: copia, compila, incolla
Modello che uso come primo messaggio. Sostituisci i [...] e incollalo prima di qualsiasi feature.
Sei un Senior Software Engineer rigoroso. Il tuo compito è assistermi
nello sviluppo di questo progetto, rispettando tassativamente queste regole.
# 1. STACK TECNOLOGICO
- Linguaggio/Framework: [es. Python 3.12, FastAPI, SQLite]
- Frontend: [es. HTML/CSS vanilla, niente framework JS]
Non suggerire, installare o usare librerie fuori da questo stack
senza mia autorizzazione esplicita. Privilegia la libreria standard.
# 2. CONFINI E SICUREZZA (Fail-Fast)
- Segreti: non scrivere MAI chiavi API, password o token in chiaro.
Usa variabili d'ambiente. Crea sempre un `.env.example` con valori fittizi.
- Isolamento: logica core separata dal framework web / UI.
# 3. METODO DI LAVORO (DoD)
- UN modulo per volta. Non generare l'intera app in una sola risposta.
- Prima di codice complesso: piano in 3 punti.
- Se lavoro in una cartella (es. src/core/), non toccare fuori da lì
a meno che non te lo chieda.
# AZIONE RICHIESTA ORA
Conferma di aver letto queste regole. Se ti ho allegato SPEC.md
(o un documento di contesto), conferma di averlo analizzato.
NON generare feature o codice funzionale ora.
Rispondi solo: "Regole acquisite. In attesa del primo task."Anatomia: perché questi vincoli
1. Stack bloccato
Senza stack, un LLM può risolvere tutto con pip/npm extra: più superficie e rischio supply-chain. Privilegio alla libreria standard = meno dipendenze da verificare (vedi anche npm audit se sei in JS).
2. Segreti e .env.example
Errore tipico: credenziali in config.py o nel main. Obbligare .env.example con valori finti (sk-ESEMPIO-NON-REALE) crea il pattern giusto dal giorno zero. Mai valori reali nel prompt.
3. Isolamento core vs UI
Se il bottone parla direttamente al DB, il debito tecnico esplode. L’isolamento forza strati. Approfondimento: disaccoppiare business logic e UI.
Come usarlo con SPEC.md
Il kickoff dà il meglio con un documento di contesto. Su ai riparo il pezzo dedicato è il manifest / SPEC.md e i confini architetturali.
Flusso tipico:
- Cartella progetto (es.
Documenti/mia-app/). docs/SPEC.mdcon obiettivo, stack, divieti.- Apri Cursor (o la chat).
- Allega lo SPEC (
@docs/SPEC.mdin Cursor). - Incolla il prompt di avvio.
Così separi il cosa (SPEC) dal come comportarsi (kickoff).
Il secondo messaggio: il vero inizio
Se rispetta il kickoff, la risposta è: «Regole acquisite. In attesa del primo task.»
Se invece ti scarica già un monolite da 400 righe, il kickoff è stato ignorato: non continuare su quella chat come se niente fosse. Nuova sessione, di nuovo SPEC + kickoff, oppure rimprovero esplicito e stop al codice.
Non chiedere l’app intera. Chiedi lo scheletro o un modulo:
💡 Consiglio pratico — Primo task
«Crea solo la struttura cartelle e il file di connessione SQLite insrc/core/. Niente UI. Mostrami il codice e aspetta conferma.»
Un passo alla volta = puoi leggere il diff prima della valanga. Checklist sulle scorciatoie tipiche: 7 falle nel codice IA.
Cosa controllare nella prima risposta «utile»
Dopo il primo task, prima di Accept:
- Path coerenti con lo stack dichiarato (niente cartelle inventate).
- Nessuna chiave/token in chiaro; solo
os.getenv/ config da env. - Nessun
importdi framework UI dentrocore/(se hai imposto l’isolamento). - Nessuna dipendenza non autorizzata nel testo («installiamo X…»).
Su Windows, nei prompt preferisci path relativi (src/core/…) invece di C:\Users\…: meno leakage di contesto personale e meno errori di copia-incolla tra macchine.
Errori tipici
⚠️ Attenzione — Illusione di sicurezza
Il kickoff alza le probabilità di codice più pulito. Non garantisce assenza di bug o falle logiche. Gli LLM sono probabilistici: possono violare una regola. Verifica sempre.
- «Tanto l’ho messo nelle regole» — se compare una chiave in chiaro, non «migliora»: rifiuta, cita la regola violata, rifai il modulo.
- Kickoff + «ora fai tutta l’app» — annulli il vantaggio. Resta sul modulo singolo.
- SPEC vuoto — senza perimetro, le regole restano astratte.
Domande Frequenti (FAQ)
A cosa serve questo prompt?
A impedire che l’IA parta generando codice e framework casuali prima che tu fissi architettura e sicurezza di base.
Differenza con SPEC.md?
SPEC descrive l’app (obiettivi, dati, confini di prodotto). Il kickoff fissa regole di sessione: stack, segreti, ritmo.
Funziona su ChatGPT o Claude senza Cursor?
Sì. Cursor aiuta con i file locali; le regole d’ingaggio valgono per qualsiasi chat di coding.
L’IA ignora i vincoli a metà progetto?
Fermala. Segnala la violazione («Hai messo un segreto in chiaro: regola 2») e rifai il pezzo. Non accettare e «aggiusta dopo».
Sostituisce .cursorrules?
No. .cursorrules = regole di workspace permanenti. Il kickoff = ritmo e obiettivo di quella sessione. Meglio usarli insieme.
Questo basta per la sicurezza?
No. È un freno iniziale. Restano review, test, checklist falle e igiene dei secret.
