Il comando /goal in Claude Code e Codex

Che problema risolve /goal

Un coding agent può già lavorare per molti passaggi dentro un singolo prompt, ma sui lavori lunghi il problema non è solo iniziare: è ricordare quando fermarsi. /goal rende esplicita la definizione di done. Invece di chiedere ogni volta il prossimo passo, dai all'agente un obiettivo persistente e lo costringi a misurarsi contro un risultato verificabile.

• Riduce il rischio di sessioni che si fermano dopo una patch parziale.
• Aiuta l'agente a scegliere il prossimo passo dopo test, errori o review.
• Rende più chiaro cosa deve comparire nel transcript per dichiarare completato il lavoro.
• Funziona meglio quando abbini /goal a permessi, sandbox e comandi di verifica adatti.

Claude Code: condizione di completamento

Nella documentazione di Claude Code, /goal imposta una condizione di completamento per la sessione. Dopo ogni turno, un modello piccolo e veloce controlla la conversazione e decide se la condizione è soddisfatta. Se la risposta è no, Claude avvia un altro turno con il motivo del mancato completamento come guida.

• Richiede Claude Code v2.1.139 o successivo.
• Accetta una sola goal attiva per sessione, sostituibile con una nuova condizione.
• Il comando /goal senza argomenti mostra stato, turni, tempo, token e ultimo motivo del valutatore.
• La condizione può arrivare a 4.000 caratteri, ma deve restare giudicabile dal transcript.

Codex: goal persistente nel thread

Nei documenti Codex, Goal mode assegna al thread un obiettivo persistente. Il testo del goal serve sia come prompt iniziale sia come criterio di completamento. Nell'app Codex puoi vedere l'avanzamento sopra il composer e usare controlli per mettere in pausa, riprendere, modificare o cancellare il goal. In CLI sono documentati /goal, /goal pause, /goal resume e /goal clear.

• Se /goal non appare, la documentazione indica di abilitare features.goals in config.toml.
• Codex consiglia di usare /plan prima quando il goal non è ancora ben definito.
• Puoi continuare a guidare Codex con messaggi successivi mentre il goal resta attivo.
• Per istruzioni molto lunghe, conviene metterle in un file e far puntare il goal a quel file.

Come scrivere un goal efficace

Un buon goal non è una descrizione aspirazionale. È un contratto operativo: che cosa deve cambiare, come si verifica, quali vincoli non vanno violati e quando fermarsi. Prima di attivarlo, conviene usare l'LLM come sparring partner: gli spieghi il task, gli chiedi di farti domande se manca contesto e approvi solo alla fine il comando /goal definitivo.

• Fai generare all'LLM una bozza di goal prima di avviare Goal mode.
• Chiedigli di separare target, success criteria, exit condition, scope, constraints e verification.
• Risultato: cosa deve essere vero alla fine.
• Verifica: quale comando, test, build o controllo dimostra che è vero.
• Vincoli: cosa non deve cambiare, quali file evitare, quale stile seguire.
• Limite: quando fermarsi se il goal non converge, per esempio dopo un numero di turni.
• Esempio: /goal il checkout usa la nuova API pagamenti, npm test esce 0 e nessun file fuori src/payments viene modificato.

Aiutami a formulare un buon /goal prima di avviare l'agente.

Contesto:
- Devo migrare il checkout alla nuova API pagamenti.
- Il modulo principale è src/payments.
- Non voglio modifiche fuori da src/payments e src/app/checkout.

Prima fammi domande se manca contesto.
Poi proponi:
1. target
2. success criteria
3. exit condition
4. scope
5. constraints
6. verification command

Alla fine scrivi una sola riga pronta da incollare come /goal.

Quando non usarlo

/goal è potente proprio perché continua a tenere l'agente in movimento. Questo lo rende inadatto ai casi in cui vuoi ancora ragionare, esplorare trade-off o decidere la direzione. Se non sai ancora quale risultato vuoi, usa /plan, chiedi alternative, poi trasforma la scelta in goal.

• Non usarlo per brainstorming aperto o decisioni di prodotto non risolte.
• Non usarlo se mancano test o segnali verificabili.
• Non usarlo su repository grandi senza perimetro di file, moduli o issue.
• Non usarlo come sostituto della review umana su sicurezza, pagamenti o dati sensibili.

Domande frequenti