Workflow Pro & Mosse da Esperto
- 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:
| Strumento | Chi decide cosa viene eseguito dopo | Dove vivono i risultati | Scala |
|---|---|---|---|
| Subagent | Claude, turno per turno | La finestra di contesto di Claude | Alcuni per turno |
| Skill | Claude, seguendo il prompt | La finestra di contesto di Claude | Come i subagent |
| Team di agenti | Un agente lead, turno per turno | Una lista di task condivisa | Una manciata di peer di lunga durata |
| Workflow dinamici | Lo script | Variabili dello script | Da 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.
- 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:
- 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.
- Un hook Stop esegue il tuo script di test/build e impedisce al turno di terminare finché non passa. È ciò che permette a un'esecuzione senza supervisione di concludersi correttamente invece di fermarsi quando il lavoro semplicemente 'sembra fatto'.
- Nega le scritture su un percorso protetto (migrazioni, file generati, segreti) prima che avvengano, indipendentemente da ciò che Claude intende fare.
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.
- 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,gcloudesentry-clisono 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")'
- 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:
- 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.'
- Chiedi un piano di implementazione dettagliato. Modificalo direttamente prima di approvarlo — un piano che hai corretto batte un piano che hai sfogliato.
- Esci dal plan mode. Claude scrive codice seguendo il piano ed esegue la verifica che hai specificato.
- Fai revisionare il diff rispetto al piano da un subagent con contesto fresco, colma le lacune, poi committa e apri una PR.
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:
/cleartra task non correlati; una sessione pulita con un prompt migliore batte una lunga e inquinata.- Dopo due correzioni fallite, smetti di correggere —
/cleare 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:
- 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.
- Aggiungi un hook PostToolUse di lint/format e un hook Stop che vincola ai test. Ora il ciclo si chiude da solo invece di aspettare te.
- Scegli un workflow che hai digitato due volte — fix-issue, write-tests, ship-pr — e mettilo in .claude/skills/ o .claude/commands/.
- Aggiungi solo i server che usi ogni settimana; preferisci le CLI gh/aws a MCP dove esistono. Elimina il resto.
- Usa il plan mode per qualsiasi modifica multi-file o non familiare, e concludi con un subagent di review a contesto fresco.
- Esegui claude -p in un hook pre-commit o in un piccolo batch job con --allowedTools, così sperimenti Claude come fase di pipeline e non solo come chat.
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.md | Tieni fuori |
|---|---|
| Comandi Bash che Claude non può indovinare | Tutto ciò che Claude trova leggendo il codice |
| Regole di code-style che differiscono dai default | Convenzioni standard che Claude già conosce |
| Test runner + come eseguire un singolo test | Documentazione API completa (metti un link) |
| Etiquette del repo (naming di branch/PR) | Informazioni che cambiano spesso |
| Trabocchetti non ovvi e quirk dell'ambiente | Banalità 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- 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
- Best practice per Claude Code — la guida ufficiale di Anthropic: il ciclo esplora→pianifica→esegui, le regole di CLAUDE.md, hook, subagent, distribuzione headless e verifica.
- Orchestrare subagent su larga scala con i workflow dinamici — documentazione ufficiale sui workflow dinamici, la keyword
ultracode,/deep-researche la tabella comparativa di chi-tiene-il-piano. - Context engineering efficace per gli agenti AI — Anthropic Engineering sul contesto come budget finito e sul recupero just-in-time.
- hesreallyhim/awesome-claude-code — ampia lista curata dalla community di skill, hook, slash-command, orchestratori di agenti e plugin.
- qdhenry/Claude-Command-Suite — una nota libreria di slash-command e agenti professionali (es.
/dev:code-review). - GWUDCAP/cc-sessions — un set di estensioni con una sua filosofia che dimostra hook per l'enforcement del workflow più gestione di task/git.
- VoltAgent/awesome-claude-code-subagents — un'ampia raccolta della community di definizioni di subagent specializzati.