Far rivedere il codice di Claude Code ad altre AI
Far scrivere codice a un agente è ormai facile: il punto è chi lo rivede. L'idea di questo articolo — uno spunto, non un prodotto pronto — è un plugin che, a fine sessione di Claude Code, prende il diff e lo manda in review ad altre AI da terminale: Junie, Copilot, Gemini e Codex. Con una regola che tiene tutto robusto: prima controlla quali CLI sono installate sul PC, e usa solo quelle.

💡 L'idea in una riga
Quando una sessione di Claude Code finisce, di solito succede una cosa sola: chiudo il terminale. Il codice appena generato resta lì, senza un secondo paio d'occhi. L'idea è togliere quel vuoto in automatico: a fine sessione il diff parte verso altri assistenti AI che lo leggono e mi dicono cosa non va.
Non è un prodotto da scaricare: è uno spunto costruito su strumenti che ho già — quattro CLI di review diverse — orchestrate da un hook. Il valore non è un tool nuovo, ma il fatto che la review diventi il default, non una cosa che mi ricordo di fare.
# la sessione di Claude Code finisce
stop → git diff → review da altre AI
# nessun comando manuale: parte da sola🔍 Prima regola: controlla cosa c'è sul PC
Il cuore dell'idea è qui. Non do per scontato che Junie, Copilot, Gemini e Codex siano installati: ogni macchina è diversa. Il plugin rileva quali CLI rispondono e manda il diff solo a quelle. Una command -v prima di ogni chiamata, e basta.
Così il plugin è robusto ovunque: sul portatile con tutte e quattro le CLI fa una review a quattro voci; sul PC dove c'è solo Gemini ne fa una sola. Quello che manca viene saltato, non fa fallire la sessione.
# review solo se la CLI esiste sul PC
for cli in junie copilot gemini codex; do
command -v "$cli" >/dev/null 2>&1 \
&& review_with "$cli" \
|| echo "skip · $cli non installata"
done🚀 Lo Stop hook che fa partire tutto
Il pezzo che trasforma l'idea in automatismo è un hook di tipo Stop: Claude Code lo esegue quando la sessione termina. Lo registro una volta nel settings.json e da lì in poi non ci penso più — a ogni fine sessione parte il mio script orchestratore.
La review gira in sola lettura: legge il diff, non tocca i file e non fa commit. Se voglio che applichi le correzioni è un secondo passo, separato e volontario — l'automatismo di default osserva, non modifica.
{
"hooks": {
"Stop": [
{ "command": "review-dispatch.sh" }
]
}
}Doc ufficiale · Claude Code hooks ↗
🏗️ Il dispatcher e la struttura del plugin
Lo script orchestratore — il dispatcher — fa una cosa semplice: per ogni CLI presente lancia la sua review in parallelo, raccoglie gli output e li mette uno sotto l'altro. Quattro modelli diversi leggono lo stesso diff da angoli diversi: dove uno non nota niente, un altro trova il bug.
Impacchettare tutto come plugin vuol dire installarlo su qualsiasi macchina con un comando, invece di copiare script a mano. La struttura è minima: un descrittore e la cartella degli hook.
code-review-team/ ├─ .claude-plugin/ │ └─ plugin.json └─ hooks/ ├─ review-dispatch.sh # orchestratore ├─ junie.sh ├─ gemini.sh └─ copilot.sh └─ codex.sh
🔐 Il gate: niente fatto senza review
C'è un'estensione utile dell'idea: un gate. Se a fine sessione dichiaro «completato» ma il diff non è vuoto e nessuna review è passata, l'hook blocca la chiusura. È il modo per non dire «fatto» a vuoto: la prova viene prima dell'affermazione.
Il gate si dosa: severo sui progetti importanti, morbido sugli esperimenti. L'importante è che la decisione sia esplicita, non lasciata alla memoria di fine giornata.
- 01Stop hookla sessione finisce
- 02Rileva le CLIcommand -v: chi c'è sul PC
- 03Review parallelasolo i tool presenti
- 04Gate sul donediff non rivisto → stop
Quattro passi: innesco, rilevamento, review, gate.
⚖️ Reviewer presente o assente
Vale la pena fissare il comportamento nei due casi, perché è ciò che rende l'idea usabile da chiunque, con qualunque set di strumenti installati.
La stessa sessione, su due macchine diverse, produce review diverse senza nessuna modifica al setup: il plugin si adatta a quello che trova.
CLI installata
- Riceve il diff
- Gira in sola lettura
- Restituisce i suoi rilievi
CLI assente
- Viene saltata in silenzio
- Nessun errore bloccante
- Gli altri proseguono
Stesso plugin, comportamento diverso a seconda di cosa trova sul PC.
🗺️ Da dove partire
Se l'idea ti gira in testa, non serve costruire tutto subito. Parti da un reviewer — quello che hai già installato — e da un hook Stop minimale. Aggiungi il command -v davanti alla chiamata, così non si rompe quando cambi macchina. Poi, quando funziona, aggiungi gli altri.
È uno spunto: l'ossatura — hook di fine sessione, rilevamento delle CLI, review parallela in sola lettura — è quella che uso ogni giorno. Il resto si adatta ai tuoi strumenti. Il punto non è il tool, è rendere la review automatica.
1. un hook Stop minimale 2. una CLI che hai già (es. gemini) 3. command -v prima di lanciarla 4. poi aggiungi junie, copilot, codex
Domande frequenti su code review multi-AI per Claude Code
Devo installare tutte e quattro le CLI?
No. Il plugin rileva con command -v quali sono presenti e manda il diff solo a quelle; le altre vengono saltate senza errori. Anche con una sola CLI il flusso ha senso.
La review modifica il mio codice?
No: gira in sola lettura e produce solo rilievi, non commit. Se vuoi che applichi le correzioni, lo prevedi come passo separato e volontario.
Serve un servizio a pagamento o la connessione?
Dipende dalle singole CLI: il plugin non aggira i loro requisiti, si limita a verificare se rispondono sul tuo PC e a usarle quando ci sono.
È un plugin pronto da installare?
È uno spunto, non un prodotto: l'ossatura (hook di fine sessione, rilevamento delle CLI, review parallela) è reale, ma va adattata ai tuoi strumenti.
Parliamone
Se questo tema ti riguarda, scrivimi: confrontarsi su codice e AI è sempre tempo speso bene.