Quattro prompt per pubblicare su GitHub senza rimpianti

Ho iniziato a pubblicare su GitHub da poco. Qualche script Python, esperimenti con l’AI — niente di rivoluzionario. Ma abbastanza per rendermi conto che pubblicare non è solo caricare file e sperare per il meglio.

Non è che non ci pensassi, alla qualità di quello che producevo. L’importanza di scrivere roba sicura, leggibile, manutenibile — quella ce l’ho sempre avuta chiara. Il problema è che mi ero fermato ai prompt generici: “scrivi una funzione che fa X”, e via. Funzionava, ma senza nessuna struttura intorno.

Ho letto un post di Nicola Spada sul vibe coding che mi ha fatto riflettere su una cosa che davo per scontata. Il punto non era solo tecnico. Era una questione di rispetto — verso chi clona il tuo repository, verso chi prova a capire cosa hai fatto, verso chi magari vuole contribuire. E, diciamolo, verso te stesso tra sei mesi quando non ricordi più perché hai scritto quella funzione in quel modo.

Nicola lo diceva chiaramente: l’AI ottimizza per “far funzionare” le cose nel modo più breve possibile. Se non le dai regole, produce roba che funziona ma che nessuno — te compreso — riuscirà a gestire. Il codice aperto senza struttura non è open source. È solo codice abbandonato su un server.

Partendo dai prompt che proponeva ho costruito la mia versione, un po’ più strutturata e adatta al mio modo di lavorare. Ne ho tenuti quattro — quelli che uso davvero.

I quattro prompt — pronti da copiare

Una premessa veloce sul prompt della code review: troverai il riferimento a una PR open source. PR sta per Pull Request — quando qualcuno vuole modificare un progetto su GitHub non lo tocca direttamente, ma manda una richiesta con le sue modifiche che il proprietario può accettare o rifiutare. Citarla nel prompt serve come metro di paragone: vuoi che l’AI sia critica come lo sarebbe un revisore esperto, non un amico che non vuole offenderti.

Refactoring

Refactora questa funzione per renderla più manutenibile.
Regole:
- NON cambiare il comportamento esterno
- Aggiungi type hints se mancano
- Migliora i nomi di variabili e funzioni se sono poco chiari
- Spezza in sotto-funzioni se supera 30 righe
- Aggiungi docstring Google style se mancante
- Mantieni o aggiorna i test esistenti
- Spiega ogni modifica che fai e perché

Code review

Fai una code review di questo progetto come se fossi un
senior developer che revisiona una PR per un progetto
open source importante.
Valuta: leggibilità, sicurezza, testabilità, gestione
errori, performance, convenzioni.
Per ogni categoria:
- dai un voto da 1 a 10
- elenca i problemi trovati
- suggerisci la correzione concreta
Alla fine dammi una lista ordinata per priorità:
cosa sistemare prima di tutto.

README

Genera un README.md professionale per questo progetto
open source Python.
Deve includere:
- Badge CI status e licenza
- Descrizione chiara in 3 righe massimo
- Requisiti di sistema
- Installazione passo passo
- Quickstart con un esempio reale e funzionante
- Struttura delle cartelle commentata
- Come contribuire (fork, branch, PR)
- Licenza
Il quickstart deve funzionare in meno di 5 minuti
per qualcuno che non ha mai visto il progetto.

Audit di sicurezza

Analizza questo progetto come un security auditor.
Cerca: injection vulnerabilities, segreti nel codice,
input non validato, dipendenze vulnerabili,
rischi di privilege escalation, dati sensibili nei log.
Per ogni problema: severità (Critical/High/Medium/Low),
posizione nel file, perché è un rischio, come correggerlo.
Alla fine un riepilogo con i problemi critici da sistemare subito.

Una cosa che ho imparato

Pubblicare su GitHub non significa solo caricare file. Significa rendere il progetto comprensibile, sicuro e manutenibile — anche per chi non sa niente di quello che hai fatto, anche per te tra qualche mese.

Questi prompt non risolvono tutto. Ma sono un punto di partenza concreto per chi, come me, sta iniziando a giocarci sul serio.