Claude: Skill vs Slash Command vs Subagent

Indice dei contenuti

Aggiornato ad agosto 2026.

TL;DR: Gli slash command sono scorciatoie per un prompt che digiti spesso — li invochi per nome. I subagent sono lavoratori paralleli con una propria finestra di contesto — li fai partire (tu o Claude) per un compito delimitato e ottieni un risultato. Le skill sono competenza confezionata che Claude decide di caricare da solo, in base a cosa stai chiedendo, senza che tu nomini nulla. La maggior parte delle persone ricorre a un agente personalizzato quando basterebbe uno slash command, e ricorre a uno slash command quando in realtà serviva una skill che Claude potesse attivare da sé.

[Lettura dell’operatore] Gestisco 30+ agenti in produzione su due aziende, e questa esatta confusione — command, subagent o skill — è la prima domanda di design su quasi ognuno di essi. Sbagliarla significa costruire dieci command di cui nessuno ricorda i nomi, oppure una skill così generica da non attivarsi mai in modo affidabile. La soluzione non è una regola empirica, è chiedersi cosa cambia davvero da un’esecuzione all’altra.

I tre primitivi risolvono problemi diversi

Tutti e tre ti permettono di impacchettare istruzioni una volta e riusarle. È qui che finisce la somiglianza, ed è esattamente per questo che la gente li confonde — dall’esterno, “digitare qualcosa di breve e ottenere un risultato utile” sembra identico, indipendentemente da quale dei tre stia facendo il lavoro sotto il cofano.

La vera differenza sta in chi decide di invocarlo, e in quale contesto viene eseguito:

• Uno slash command viene invocato da te, per nome. Digiti /deploy o /review, Claude lo espande in un’istruzione più completa, e viene eseguito nella tua conversazione attuale.
• Un subagent viene invocato da te o da Claude, per un compito con un confine chiaro. Ottiene una propria finestra di contesto, fa il lavoro e riporta un risultato — non vede l’intera tua conversazione, e tu non vedi i suoi passaggi intermedi a meno che tu non lo chieda.
• Una skill viene invocata da Claude, automaticamente, quando la tua richiesta corrisponde a ciò che la descrizione della skill dichiara di coprire. Non digiti mai il suo nome. Se non chiedi qualcosa che la skill gestisce, non si carica mai.

Quella terza proprietà — nessuna invocazione esplicita — è quella che le persone sottoutilizzano di più. Ed è anche quella con la leva maggiore una volta che hai più di un pugno di flussi di lavoro confezionati, perché smetti di dover ricordare come hai chiamato le cose.

Slash command: scorciatoie per un prompt che digiti spesso

Costruisci uno slash command quando il trigger è “continuo a digitare sostanzialmente la stessa istruzione.” Un command che si risolve sempre nello stesso prompt sottostante, espanso da un nome breve che hai scelto, nella conversazione che stai già avendo. Nessun contesto separato, nessuna invocazione autonoma — decidi tu quando viene eseguito, ogni volta.

Casi adatti: una checklist di rilascio fissa, un passaggio di code review con le tue regole della casa incorporate, una scorciatoia “riassumi questa PR.” Il command non ha bisogno di giudizio su se eseguirsi — sei tu a fare quella scelta digitandolo.

Il modo in cui si sbaglia è costruire un command per qualcosa che in realtà richiede al modello di decidere se si applica. Se metà del tuo utilizzo è “aspetta, questa situazione conta?” — quella è una domanda da skill, non da command, perché un command non ha modo di attivarsi da solo.

Subagent: lavoratori paralleli con una propria finestra di contesto

Costruisci un subagent quando il compito è delimitato, delegabile e altrimenti inquinerebbe la tua conversazione principale con passaggi che non ti servono vedere. Un subagent esegue il proprio contesto — le proprie chiamate di strumenti, il proprio andirivieni — e restituisce un risultato. È lo stesso principio di cui ho scritto sul context engineering: ogni chiamata di strumento e passaggio intermedio in più è contesto che il tuo thread principale non deve portarsi dietro, e un subagent è come tieni fuori quel rumore.

Casi adatti: “fai questa ricerca e riportami i risultati,” “esegui questi cinque controlli indipendenti in parallelo,” “vai a sistemare questo singolo file in isolamento.” Il compito ha un inizio, una fine e un deliverable — la stessa forma che l’eval harness che uso per spedire agenti tratta come una singola unità valutabile.

Il modo in cui si sbaglia è far partire un subagent per qualcosa che doveva restare nel tuo contesto principale perché il passaggio successivo dipende da dettagli che il riassunto del subagent ha perso. Se continui a dover richiedere al subagent “aspetta, cosa hai trovato esattamente,” il confine è stato tracciato male — o lo reintegri nel thread principale, oppure rendi il report del subagent abbastanza strutturato da non perdere nulla nella traduzione.

Skill: competenza confezionata che Claude carica da solo

Costruisci una skill quando la condizione di attivazione è qualcosa che Claude dovrebbe riconoscere da ciò che stai chiedendo, non qualcosa che devi ricordarti di nominare. Una skill è una descrizione più un pacchetto di istruzioni e script; Claude legge la descrizione, decide se la tua richiesta corrisponde, e carica le istruzioni complete solo se è così. Non digiti mai /nome-skill.

L’esempio più chiaro che posso indicare è quello che fa girare la pipeline dietro questo blog. Alejandrorioja.com pubblica in 13 lingue, e l’intero flusso genera → traduci → renderizza → rivedi vive in un’unica skill: un file SKILL.md che descrive quando usarla (“genera un nuovo post,” “traduci in tutte le lingue,” “abbozza una promo”), più gli script che fanno il lavoro vero e proprio. Non eseguo quattro command separati ricordandomi il loro ordine. Dico cosa voglio in linguaggio naturale, e la descrizione della skill è abbastanza specifica che Claude la coglie ed esegue i passaggi giusti — allo stesso modo in cui la skill per le mie inserzioni Facebook si attiva su “controlla le mie inserzioni” senza che io digiti un nome di command.

Quella scelta di design — una skill che decide da sola quando si applica — è anche il motivo per cui qui il default di sicurezza conta più che con command o subagent. Uno slash command si esegue solo quando lo digiti; una skill si esegue quando il modello pensa che dovrebbe. La mia skill per i contenuti scrive bozze per default e richiede un passaggio di approvazione esplicito e separato prima che qualsiasi cosa venga pubblicata o inviata — lo stesso pattern human-in-the-loop che uso ovunque una skill possa auto-attivarsi in un’azione con conseguenze reali.

Casi adatti: qualsiasi cosa con una frase trigger riconoscibile e una procedura ripetibile dietro — “genera un report,” “valuta questo elaborato,” “abbozza un riassunto per Slack.” Il modo in cui si sbaglia è una descrizione di skill così ampia da scattare quando non volevi, o così ristretta da non scattare mai quando volevi. Scrivi la descrizione come la spiegheresti a un nuovo assunto, non come nomineresti una funzione.

Il framework decisionale

Chiediti questo	Se sì →	Perché
Voglio sempre digitare un nome per attivarlo?	Slash command	Il trigger sei tu, non il modello
Il compito è delimitato, delegabile e meglio tenuto fuori dal mio contesto principale?	Subagent	Finestra di contesto propria, restituisce un risultato
Claude dovrebbe riconoscere il bisogno senza che io nomini nulla?	Skill	Attivazione automatica basata sulla descrizione
Tocca soldi, pubblicazione o qualcosa di difficile da annullare?	Uno qualsiasi dei tre, più un gate di approvazione esplicito	L’auto-invocazione non è la stessa cosa dell’auto-esecuzione

La maggior parte dei flussi di lavoro reali è uno stack di questi, non una scelta singola. La mia pipeline di contenuti è una skill (auto-attivata su “scrivi un post”) che internamente chiama subagent (uno per lingua, eseguiti in parallelo) ed espone uno slash command (/publish) per l’unico passaggio — andare live — che non deve mai succedere senza che io lo dica esplicitamente.

L’errore che vedo più spesso

Costruire un agente personalizzato completo — con la propria pianificazione, il proprio stato, il proprio deploy — per qualcosa che in realtà era uno slash command travestito. Se il compito è “esegui questa procedura esatta quando te lo dico,” non ti servono autonomia, memoria o una condizione di trigger. Ti serve un nome e un prompt. Riserva il macchinario di subagent e skill per i compiti in cui il confine (subagent) o il trigger (skill) sta davvero facendo un lavoro, non solo aggiungendo infrastruttura a qualcosa che era già semplice.

Il bilancio finale dell’operatore

Chiediti chi decide di invocarlo prima di chiederti come costruirlo. Decidi tu, per nome, ogni volta → slash command. Un compito delimitato che vuoi fuori dal tuo contesto principale → subagent. Claude che riconosce il bisogno da solo → skill, con un gate di approvazione su qualsiasi cosa non si possa annullare. Prendi bene quella singola domanda e il resto — cosa mettere nel file, quanta istruzione impacchettare — per lo più viene da sé.

FAQ

Qual è la differenza tra una skill di Claude e uno slash command?

Uno slash command viene invocato esplicitamente, per nome, ogni volta che vuoi che venga eseguito. Una skill viene invocata automaticamente — Claude confronta la tua richiesta con la descrizione della skill e la carica senza che tu nomini nulla. Usa un command quando sei sempre tu a decidere di attivarlo; usa una skill quando la condizione di attivazione è qualcosa che il modello dovrebbe riconoscere da solo.

Quando dovrei usare un subagent invece di una skill?

Quando il compito è delimitato e delegabile e vuoi che venga eseguito nella sua propria finestra di contesto, separata dalla tua conversazione principale — non per come viene attivato, ma per dove avviene il lavoro. Skill e subagent non si escludono a vicenda: una skill può far partire subagent internamente, come una skill di traduzione che smista un post a un subagent per lingua.

È sicuro lasciare che una skill auto-invochi azioni come pubblicare o spendere denaro?

Solo con un gate di approvazione esplicito sul passaggio con conseguenze. L’auto-invocazione della skill stessa va bene — significa solo che Claude ha riconosciuto cosa stai chiedendo. Il rischio è l’auto-esecuzione di qualsiasi cosa difficile da annullare. Mantieni la scrittura di bozze, la lettura e il reporting dentro la skill auto-attivata; richiedi una conferma separata ed esplicita per pubblicare, pagare o eliminare.

Devo costruire tutti e tre prima o poi?

Solo se i tuoi flussi di lavoro hanno davvero tutte e tre le forme. Un operatore solitario con un pugno di compiti ripetibili potrebbe vivere interamente di slash command per molto tempo. Il bisogno di skill e subagent emerge una volta che hai abbastanza condizioni di trigger distinte da non riuscire più a ricordare i nomi dei command, o abbastanza sotto-compiti delimitati che tenerli nel tuo contesto principale inizia a danneggiare la qualità.

---

Correlati: La skill di Claude che gestisce le mie inserzioni Facebook · Context engineering: cosa va nella finestra di contesto · Agenti IA human-in-the-loop: quando costruire un gate di approvazione · Lo stack di agenti che uso per gestire 30+ agenti in produzione

Serve aiuto a decidere cosa automatizzare e come? Mettiti in contatto — progetto sistemi di agenti in produzione per team di operatori.