Cosa c’entra Claude Code e il comando “/goal”?
Hai presente quei lavori piccoli che restano aperti per settimane? Non perché siano difficili, ma perché sono noiosi.
Apri un file, leggi, controlli, sistemi due righe, salvi e passi al successivo; e dopo il quinto file hai già perso il filo.
Il caso di partenza era così: circa 60 post già pubblicati, da sistemare con almeno due link interni verso altri articoli del blog. Una cosa utile per la SEO, perché i link interni aiutano Google e i lettori a capire meglio la struttura dei contenuti. Però farlo a mano è una piccola tortura.
Claude Code poteva fare ogni singolo passaggio. Il punto era un altro: serviva continuità. Qualcuno doveva continuare a dirgli “ok, ora vai avanti con il prossimo”.
Poi entra in scena “/goal”.
Anthropic (l’azienda che ha creato il modello di intelligenza artificiale Claude e Claude Code), ha introdotto il comando “/goal” in Claude Code v2.1.139.
Nel caso riportato sopra, è stato usato per sistemare i link interni di tutti i 60 post. Tempo totale: 6 minuti. Senza toccare la tastiera mentre il processo girava.
La parte interessante non è solo tecnica. Anzi, fammi dire una cosa: il vero cambio è mentale.
In questo articolo trovi: cos’è “/goal”, perché cambia il modo di lavorare con Claude Code, l’esempio dei link interni, tre casi d’uso pratici, i limiti veri e una checklist per usarlo senza bruciare token a caso.Se qualche parola non la conosci, in fondo all’articolo troverai un piccolo glossario, clicca sulla freccia vicino la parola.
/goal è un comando di Claude Code che serve a definire una condizione di completamento. In parole semplici: tu dici a Claude cosa deve essere vero perché il lavoro possa considerarsi chiuso.
Claude inizia a lavorare. Dopo ogni turno, un modello più piccolo e veloce legge la conversazione fino a quel punto e valuta se la condizione è stata rispettata. Se la risposta è no, Claude continua. Se la risposta è sì, il /goal viene chiuso e Claude si ferma.
Quel modello più piccolo viene usato come “evaluator”, cioè come valutatore. Non sta scrivendo il lavoro principale. Sta controllando se il criterio che hai scritto è stato raggiunto.
Questo dettaglio conta, perché /goal non serve a dire “continua finché mi sembra bello”. Serve quando puoi osservare il completamento: un numero, un file creato, un test passato, una lista finita, uno stato verificabile.
Prima di usare /goal, il problema tipico era questo: Claude fa bene il primo pezzo, poi si ferma, tu gli dici di continuare, lui fa il secondo pezzo, poi si ferma di nuovo. A un certo punto ti distrai, cambi scheda, torni dopo un’ora e non ricordi più quali file erano già stati controllati.
Succede perché stai usando Claude Code come un assistente da guidare passo passo. Con /goal il lavoro cambia: prima definisci lo stato finale, poi lasci che il sistema prosegua finché quello stato non è stato dimostrato.
La domanda giusta diventa: “Come faccio a sapere, senza interpretazioni, che questo lavoro è finito?”.
Sembra una finezza. In realtà è la differenza tra un prompt vago e un processo controllabile.
Qui è facile fare confusione, quindi mettiamo ordine.
/loop esegue un prompt a intervalli regolari, per esempio ogni cinque minuti, e va avanti finché non lo fermi.
Gli stop hook sono istruzioni inserite nel file di configurazione. Valgono per le sessioni che rientrano nel loro campo di applicazione.
Auto mode approva le chiamate agli strumenti dentro un turno. Per esempio, se Claude deve usare Bash, Edit o Write, auto mode può evitare che tu debba approvare ogni singola azione.
Bash è la shell dei comandi. Edit e Write sono strumenti usati da Claude Code per modificare o creare file.
/goal fa un’altra cosa: mantiene attivo il lavoro finché la condizione scritta da te non risulta soddisfatta. Inoltre, è legato alla sessione. Questo significa che non te lo porti dietro ovunque in automatico.
Il lavoro era concreto: ogni post dentro src/content/blog/ doveva avere almeno due link interni verso altri post pubblicati. Non link messi a caso. Link sensati, dentro il contenuto, senza riscrivere tutto il blog.
Nel codice e nei file Markdown, un link interno può avere una forma riconoscibile. In questo caso, la verifica cercava link Markdown che puntavano a /blog/. Questo è il comando usato:
/goal Every post in src/content/blog/ has at least 2 internal links to other published posts on the site (markdown links matching `](/blog/`). Verify the count for each file. If a post genuinely has no relevant linking opportunities, add a `<!-- linking-skipped: <reason> -->` comment after the frontmatter explaining why. Stop after 60 turns. Don't modify any content beyond inserting links or the skip comment.
Qui dentro ci sono tre scelte molto intelligenti. Copiale, perché fanno la differenza tra un /goal utile e un /goal che si perde.
1. Uno stato finale misurabile
“Almeno 2 link interni per post”. Questo è misurabile. Claude può contare. L’evaluator può leggere il conteggio. Tu puoi verificare dopo.
La definizione è ancora più precisa perché dice anche cosa conta come link interno: un link Markdown che corrisponde a `](/blog/`. Quindi non ci si affida a una frase tipo “aggiungi qualche link utile”. Troppo vaga.
2. Una verifica esplicita
Il comando dice: “Verify the count for each file”. Tradotto: verifica il conteggio per ogni file.
Questo passaggio serve perché l’evaluator legge quello che Claude ha portato nella conversazione. Se Claude non mostra la prova, il controllo diventa debole. Se invece produce un conteggio file per file, la valutazione ha qualcosa di concreto da leggere.
Piccola regola pratica: non chiedere solo il risultato. Chiedi anche l’evidenza.
3. Vincoli chiari su cosa non toccare
Il comando dice anche: “Don’t modify any content beyond inserting links or the skip comment”. Quindi, Claude può inserire link o, se davvero non trova occasioni sensate, un commento di skip. Stop.
Questo evita il classico effetto collaterale: Claude entra in un file, vede una frase migliorabile, sistema anche quella, poi cambia il tono del paragrafo, poi ritocca il titolo. E tu volevi solo due link.
Il commento `<!– linking-skipped: <reason> –>` è un commento HTML. In genere, non viene mostrato al lettore finale, ma resta nel file come nota tecnica.
Il frontmatter, invece, è il blocco di metadati all’inizio di molti file Markdown: titolo, data, slug, categoria e dati simili.
Nel comando c’è anche un limite: “Stop after 60 turns”. Un turno è un passaggio operativo nella sessione. Il punto è semplice: mai lasciare un goal senza limite.
Un goal scritto male può consumare token senza produrre valore. Il limite non è sfiducia verso Claude. È buon senso operativo.
Nel caso riportato, Claude ha controllato i 60 post, ha aggiunto i link mancanti e ha chiuso in circa 6 minuti. Il valutatore ha fatto una sola iterazione, perché Claude ha completato tutto in un flusso continuo e poi l’evaluator ha confermato che nessun file era rimasto sotto i due link interni.
Questo chiarisce una cosa importante: /goal non è un babysitter che blocca Claude dopo ogni microazione. Claude può fare l’intero lavoro in una volta, se riesce. L’evaluator interviene per controllare se, quando Claude dice “ho finito”, la condizione è davvero rispettata.
La forma ideale è sempre la stessa: hai una lista, uno stato finale, un modo per contare e un limite. Quando questi quattro pezzi ci sono, /goal diventa molto utile.
1. Ricerca competitor
Mettiamo che tu abbia un file competitors.csv con le aziende da monitorare e una cartella research/competitors/ dove vuoi salvare una scheda per ciascuna azienda. Il lavoro è noioso: prezzi, posizionamento, ICP.
Prompt da utilizzare:
/goal: Don’t stop until every company in competitors.csv has a corresponding doc in research/competitors/ with sections for pricing, positioning, and ICP filled in from publicly available sources. Cite sources at the bottom of each doc. Stop after 40 turns or once each doc has all three sections.
Qui la prova è semplice: per ogni azienda deve esistere un documento, e ogni documento deve avere tre sezioni compilate con fonti pubbliche citate in fondo.
2. Bozze per post LinkedIn
Altro caso: hai una lista di temi e vuoi 10 bozze, una per tema, salvate come file separati. Prompt da utilizzare:
/goal: Don’t stop until 10 LinkedIn post drafts are saved to drafts/linkedin/ , each in a separate file named 01-theme-name.md through 10-theme-name.md , each tied to a different theme from themes.md . Stop after 20 turns.
Attenzione però: qui /goal può verificare che ci siano 10 file e che siano legati a temi diversi. Non può garantire da solo che ogni post sia brillante, centrato o pronto per essere pubblicato. Quella parte richiede un giudizio umano.
3. Riconciliare un backlog contenuti
Questo lo utilizzi se vuoi controllare che quello che risulta “pubblicato” nel file di backlog esista davvero nella cartella del blog, e viceversa.
Prompt da utilizzare:
/goal: Don’t stop until every post in the Published section of CONTENT_BACKLOG.md exists as a file in src/content/blog/ , and every file in src/content/blog/ (excluding drafts) is listed in the Published section. Stop after 20 turns.
Qui il lavoro è quasi perfetto per /goal: esistono file, nomi, cartelle, una sezione Published e un controllo chiaro. Poco gusto personale. Tanta verifica.
Il pattern si ripete in tutti e tre i casi: una lista, uno stato target, un modo per contare, una clausola di stop
/goal è comodo, ma non va usato per tutto. E questa è la parte che ti evita problemi:
Ci sono alcuni comandi e comportamenti laterali che vale la pena conoscere.
claude -p "/goal <condition>"
Prima di lanciare il comando, scrivi quattro cose. Se una manca, fermati un minuto.
E poi aggiungi i vincoli:
Cosa non deve modificare?
Cosa deve lasciare intatto?
Dove deve scrivere?
Cosa deve citare?
Sembra burocrazia, ma in realtà è pulizia mentale. Perché se tu non sai descrivere il “finito”, Claude Code non può indovinarlo con precisione.
Se /goal è nuovo per te, il primo test dovrebbe essere piccolo e fastidioso. Non scegliere il progetto più delicato. Scegli una cosa che rimandi da giorni perché ogni passaggio è banale, ma l’elenco completo ti annoia.
Esempio:
Scrivi il criterio. Aggiungi la prova. Metti un limite. Attiva auto mode se vuoi allontanarti. Poi controlla il risultato finale con calma.
Il punto non è far lavorare Claude “di più”. Il punto è farlo lavorare fino a un criterio chiaro, controllabile e deciso prima.
Fa continuare Claude Code finché una condizione di completamento non viene valutata come soddisfatta. La condizione deve essere scritta in linguaggio naturale, ma deve essere verificabile.
/loop ripete un prompt a intervalli.
/goal lavora finché uno stato finale non è raggiunto.
Quindi /loop riguarda la ripetizione nel tempo, mentre /goal riguarda il completamento di un lavoro.
Puoi usarlo per produrre un numero definito di bozze, salvarle in una cartella e controllare che rispettino requisiti formali. Non usarlo come giudice finale della qualità. La qualità richiede lettura, contesto e scelta umana.
Serve se vuoi che il lavoro proceda senza fermarsi sulle autorizzazioni degli strumenti.
/goal gestisce il “continua finché non hai finito”.
Auto mode gestisce l’approvazione delle azioni dentro il turno.
Un lavoro su file o cartelle con criteri numerici.
Per esempio: ogni post deve avere due link interni, ogni documento deve avere tre sezioni, ogni file pubblicato deve essere presente nel backlog.
Se usi Claude Code per contenuti, SEO o marketing operativo, parti da questo schema:
È la differenza tra “dammi una mano” e “porta questo lavoro fino a un punto controllabile”.
Salva la checklist e usala la prossima volta che hai un’attività ripetitiva che continui a rimandare.
Hai bisogno di aiuto?
Compila il form che trovi qui: FORM
oppure
Chiamaci: CONTATTI
è uno strumento di Anthropic pensato per lavorare su codice, file e cartelle tramite comandi in linguaggio naturale. /goal è uno di questi comandi.
indica le unità di testo che i modelli AI leggono e producono: incidono su costo e consumo.
è un formato leggero per scrivere testi strutturati con titoli, link, liste e codice.
il profilo del cliente ideale, non basato su “uomo 35-55” ma su bisogni, problemi, criteri di acquisto e contesto reale.
è un sistema per controllare le versioni del codice.
controlli automatici usati spesso nei progetti software per verificare che tutto resti coerente.
significa area di lavoro: cartelle, file e configurazioni su cui Claude Code può operare.
significa area di lavoro: cartelle, file e configurazioni su cui Claude Code può operare.
Guarda anche gli altri articoli:
Condividi l’articolo su i tuoi social.
Ottimo articolo
Grazie, ci fa piacere che le piaccia.