Passa al contenuto principale

Workflow Pro & Mosse da Esperto

Avanzato
What you'll learn
  • Orchestra subagent in parallelo — e sappi quando passare a un workflow dinamico guidato da script
  • Rendi gli hook la colla deterministica: lint al salvataggio, blocco dello stop, blocco delle scritture vietate
  • Trasforma i tuoi prompt ripetuti in slash-command personalizzati, skill e uno stile di output
  • Costruisci uno stack MCP e pipeline headless (claude -p) che girano senza supervisione in CI
  • Esegui il ciclo esplora → pianifica → esegui → revisiona con disciplina, e mantieni il contesto snello
  • Tratta CLAUDE.md come codice: breve, ripulito e ad alto segnale

Questa è la pagina in cui le primitive smettono di essere singole funzionalità e iniziano a diventare un workflow. Se già sai cos'è un subagent o un hook, la leva sta nel modo in cui li combini: uno slash-command che avvia un passaggio in plan mode, subagent che distribuiscono il lavoro, un hook che non lascia terminare il turno finché i test non passano, e un'invocazione headless che esegue il tutto in CI. Mettiamoli insieme.

Il modello mentale: chi tiene il piano?

Ogni mossa da esperto qui sotto è una risposta diversa a un'unica domanda — chi tiene il piano e i risultati intermedi? L'inquadramento di Anthropic per la nuova funzionalità dei workflow dinamici lo espone con chiarezza:

StrumentoChi decide cosa viene eseguito dopoDove vivono i risultatiScala
SubagentClaude, turno per turnoLa finestra di contesto di ClaudeAlcuni per turno
SkillClaude, seguendo il promptLa finestra di contesto di ClaudeCome i subagent
Team di agentiUn agente lead, turno per turnoUna lista di task condivisaUna manciata di peer di lunga durata
Workflow dinamiciLo scriptVariabili dello scriptDa decine a centinaia

La progressione è tutto il gioco: parti con un solo Claude, delega ai subagent per proteggere il contesto, e sposta il piano nel codice solo quando un task richiede più agenti di quanti una singola conversazione possa coordinare.

Mossa 1 — Subagent in parallelo, poi passa a un workflow

Un subagent è un Claude separato con la propria finestra di contesto e un toolset circoscritto; restituisce un risultato, non la sua trascrizione. L'abitudine da power-user è distribuire il lavoro indipendente:

Distribuisci una review tra i moduli

Review the changes in auth/, billing/, and api/ — use the code-reviewer
subagent on each, in parallel. Report only correctness bugs and missing tests.

Tre reviewer girano contemporaneamente, ognuno consumando il proprio contesto sui diff, e la tua sessione principale vede tre report ordinati invece di tre diff grezzi. L'inghippo: il parallelismo aiuta solo per i sottotask indipendenti. Se il passo B ha bisogno dell'output del passo A, eseguili in sequenza; se scrivono sugli stessi file, isolali in git worktree.

Quando il task supera le dimensioni di una singola conversazione — una migrazione di 500 file, una caccia ai bug su tutta la codebase, una ricerca da verificare incrociando molte fonti — passa a un workflow dinamico. Claude scrive uno script JavaScript di orchestrazione (distribuisci → riduci → sintetizza), un runtime lo esegue in background con fino a 16 agenti concorrenti, e solo la risposta finale arriva nel tuo contesto. Attivane uno con la keyword ultracode o chiedilo semplicemente a parole:

Avvia un workflow dinamico

ultracode: audit every API endpoint under src/routes/ for missing auth checks,
then cross-check each finding with a second agent before reporting

La funzionalità decisiva non è solo più agenti — è che uno script può applicare un pattern di qualità ripetibile, come far revisionare in modo avversariale a degli agenti indipendenti le scoperte degli altri prima che ne venga riportata una. Prova il comando incluso /deep-research <question> per vedere il pattern in azione: vota ogni affermazione e filtra quelle che non sopravvivono al controllo incrociato.

Pro tip
  • Salva una buona esecuzione di workflow come comando: apri /workflows, seleziona l'esecuzione, premi s. Diventa /il-tuo-nome in ogni sessione futura.
  • Stima il costo prima su una porzione — una directory, non l'intero repo. Un'esecuzione può generare molti più agenti (e token) di una singola conversazione.

Mossa 2 — Hook: la colla deterministica

Le istruzioni di CLAUDE.md sono consultive — Claude di solito le segue. Gli hook sono deterministici — eseguono uno script in un punto fisso del ciclo, garantito, ogni volta. Ricorri a un hook quando qualcosa deve accadere senza eccezioni.

I tre pattern di hook con la leva più alta:

Guided walkthrough1 of 3
  1. Dopo che Claude modifica un file, esegui automaticamente il tuo formatter o linter così la codebase non va mai alla deriva. Il feedback torna anche a Claude, che si autocorregge.

Non devi scrivere il JSON a mano. Chiedi a Claude di redigere l'hook per te:

Fai scrivere un hook a Claude

Write a hook that runs eslint --fix after every file edit, and a second hook
that blocks any Write or Edit to the db/migrations/ folder. Add them to
.claude/settings.json and show me the config.
Watch out
  • Un hook Stop che continua a bloccare verrà ignorato dopo diversi blocchi consecutivi, così la sessione non può andare in deadlock — il tuo gate è una barriera di sicurezza, non un loop infinito.
  • Gli hook girano con i permessi della tua shell. Esamina ogni script di hook prima di committarlo, esattamente come faresti con la config della CI.

Mossa 3 — Slash-command personalizzati, skill e stili di output

Tutto ciò che prompti due volte dovrebbe diventare una primitiva. La decisione è semplice: le skill sono conoscenza, gli hook sono garanzie, MCP è azione, gli slash-command sono punti d'ingresso.

Uno slash-command (o una skill con disable-model-invocation: true) impacchetta un workflow ripetibile che attivi a mano. $ARGUMENTS lo rende parametrizzato:

.claude/skills/fix-issue/SKILL.md

---
name: fix-issue
description: Triage and fix a GitHub issue end-to-end
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS:
1. gh issue view to read the issue
2. Search the codebase for the relevant files
3. Write a failing test that reproduces the bug
4. Implement the fix, then run tests and lint until green
5. Commit with a descriptive message and open a PR

Eseguilo con /fix-issue 1234. Usa disable-model-invocation: true per qualsiasi cosa con effetti collaterali che vuoi attivare deliberatamente, invece di lasciare che Claude ci ricorra da solo.

Gli stili di output cambiano come Claude comunica nell'intera sessione — conciso per un esperto, prolisso con spiegazioni per insegnare, o un formato strutturato che il tuo tooling può interpretare. Abbina uno slash-command personalizzato (il cosa) a uno stile di output (il come) e avrai plasmato entrambi i lati dell'interazione.

La mossa più sottoutilizzata dalla documentazione ufficiale: lascia che Claude ti intervisti prima di una grande feature, poi avvia una sessione nuova per costruire a partire dalla specifica scritta.

Specifica tramite intervista, poi costruisci in un contesto pulito

I want to build [brief description]. Interview me in detail using the
AskUserQuestion tool — technical implementation, UI/UX, edge cases, tradeoffs.
Dig into the hard parts I might not have considered. When we've covered
everything, write a complete, self-contained spec to SPEC.md.

Mossa 4 — Costruisci uno stack MCP

I server MCP sono processi eseguibili che Claude chiama via JSON-RPC per fare davvero le cose — interrogare il tuo database, leggere Sentry, recuperare un design Figma, aprire una issue su Linear. Uno "stack" da power-user è un insieme piccolo e deliberato, non tutto ciò che riesci a trovare:

Aggiungi server al tuo stack

claude mcp add --transport stdio sentry -- npx -y @sentry/mcp-server
claude mcp add --transport http linear https://mcp.linear.app/sse

Due principi mantengono veloce uno stack MCP:

  • Preferisci una CLI quando ne esiste una. gh, aws, gcloud e sentry-cli sono il modo più efficiente in termini di contesto per dialogare con un servizio — Claude già le conosce, e non caricano uno schema di strumenti a ogni turno. Riserva MCP ai servizi senza una buona CLI, o dove vuoi un accesso strutturato e tipizzato.
  • Mantieni snella la lista dei server. Le definizioni degli strumenti di ogni server connesso consumano contesto fin dall'inizio. Elimina i server che non stai usando attivamente; liste di strumenti gonfie soffocano le tue istruzioni vere e proprie.

Per il perché più profondo, vedi Context Engineering — la stessa logica del budget di attenzione che governa CLAUDE.md governa la tua lista di strumenti.

Mossa 5 — Pipeline headless & Agent SDK

claude -p "prompt" esegue Claude in modo non interattivo — nessuna sessione, output interpretabile — il che è la porta verso CI, hook pre-commit e batch job. Questa è la superficie headless / Agent SDK.

Il classico pattern di distribuzione tra file dalla guida ufficiale alle best practice:

Migrazione batch headless

# 1. Have Claude generate the work list first, then loop:
for file in $(cat files.txt); do
claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
  --allowedTools "Edit,Bash(git commit *)"
done

Due flag fanno il lavoro pesante: --output-format json (oppure stream-json --verbose) rende i risultati leggibili dalla macchina, e --allowedTools delimita esattamente cosa Claude può toccare quando nessun umano sta guardando. Mettilo in pipe dove vuoi:

Claude come fase di pipeline

cat error.log | claude -p "Cluster these errors by root cause, output JSON" \
--output-format json | jq '.[] | select(.severity=="high")'
Watch out
  • Testa sempre il prompt su 2–3 elementi prima di scatenare il loop su 2.000. Affina, poi scala.
  • Le esecuzioni senza supervisione richiedono una verifica integrata — un hook Stop o un passo di test nel prompt — altrimenti hai solo automatizzato la produzione su larga scala di output plausibili ma sbagliati.

Mossa 6 — Disciplina del plan mode & context engineering

La leva di qualità più affidabile in assoluto è separare la ricerca dall'esecuzione. Il ciclo in quattro fasi dalla guida alle best practice di Anthropic:

Guided walkthrough1 of 4
  1. Entra in plan mode. Claude legge i file e risponde alle domande ma non fa modifiche. Indirizzalo alle directory esatte: 'read /src/auth and explain how sessions work.'

Vedi Plan Mode per la disciplina, e salta questa fase quando il diff sta in una frase — pianificare ha un costo. Il motivo per cui funziona è l'economia del contesto: le prestazioni degradano man mano che la finestra si riempie, quindi un'istruzione da 50 token in un contesto da 2.000 token incide molto più forte della stessa istruzione sepolta in 50.000 token. Abitudini pratiche:

  • /clear tra task non correlati; una sessione pulita con un prompt migliore batte una lunga e inquinata.
  • Dopo due correzioni fallite, smetti di correggere — /clear e riscrivi il prompt con ciò che hai imparato.
  • Delega la ricerca ai subagent così la lettura dei file avviene nel loro contesto, non nel tuo.

Il percorso "potenzia il tuo setup"

Se non fai nient'altro, fai questo nell'ordine:

Guided walkthrough1 of 6
  1. Esegui /init per uno scheletro, poi taglia ogni riga che non supera il test: 'rimuoverla farebbe sbagliare Claude?' Un file gonfio fa ignorare a Claude le regole che contano.

Padronanza di CLAUDE.md

CLAUDE.md viene caricato all'inizio di ogni conversazione, quindi è il contesto a più alta frequenza che controlli — e perciò il più facile da rovinare riempiendolo troppo.

Metti in CLAUDE.mdTieni fuori
Comandi Bash che Claude non può indovinareTutto ciò che Claude trova leggendo il codice
Regole di code-style che differiscono dai defaultConvenzioni standard che Claude già conosce
Test runner + come eseguire un singolo testDocumentazione API completa (metti un link)
Etiquette del repo (naming di branch/PR)Informazioni che cambiano spesso
Trabocchetti non ovvi e quirk dell'ambienteBanalità tipo "scrivi codice pulito"

Trattalo come codice: rivedilo quando il comportamento va storto, ripuliscilo regolarmente, e usa import @path/to/file più file CLAUDE.md per directory così ogni parte di un monorepo riceve solo ciò che è rilevante. Sposta la conoscenza talvolta rilevante nelle skill così si carica su richiesta invece di gravare su ogni turno.

Mettiti alla prova

0/4
  1. Devi coordinare una migrazione di 500 file con controllo incrociato avversariale. Quale strumento è il più adatto?
  2. Qual è la differenza chiave tra un hook e un'istruzione di CLAUDE.md?
  3. Quale flag delimita cosa Claude può fare durante un'esecuzione batch `claude -p` senza supervisione?
  4. Perché ridurre CLAUDE.md migliora l'aderenza?
Richiamo delle mosse — gira ogni carta
Term shown.
1 / 5
Key takeaways
  • La progressione è l'abilità: un solo Claude → subagent in parallelo → workflow dinamici guidati da script, scelti in base a chi deve tenere il piano.
  • Gli hook sono la colla deterministica — lint al salvataggio, blocco dello stop, blocco delle scritture vietate — per ciò che deve accadere ogni volta.
  • Impacchetta i prompt ripetuti in slash-command/skill, plasma la consegna con uno stile di output, e mantieni snello uno stack MCP (preferisci le CLI).
  • claude -p headless con --allowedTools trasforma Claude in una fase di CI/pipeline; integra sempre la verifica per le esecuzioni senza supervisione.
  • La disciplina del plan mode più un'economia del contesto aggressiva (/clear, ricerca via subagent, un CLAUDE.md ripulito) è la leva di affidabilità più alta che hai.

Fonti & approfondimenti