Le competenze di Claude e SKILL.md per gli sviluppatori: VS Code, JetBrains, Cursor

La maggior parte dei team utilizza erroneamente le Claude Skills in uno di due modi: o trasforma SKILL.md in un deposito di contenuti, o non si allontana mai da prompt giganti copiati e incollati.

Entrambi gli approcci sono poco curati. Se vuoi che le Skills funzionino in un flusso di lavoro di sviluppo reale, devi trattarle come codice e logica operativa, non come poesia di prompt.

Le Claude Skills sono directory ancorate da SKILL.md, con script, riferimenti e risorse opzionali. Funzionano grazie alla rivelazione progressiva. L’agente inizia caricando solo metadati compatti come il nome e la descrizione della skill, per poi leggere le istruzioni complete solo quando il task corrisponde. Questo permette a un agente di tenere molte skills disponibili senza gonfiare ogni sessione fin dall’inizio.

Le linee guida stesse di Anthropic rendono abbastanza chiara la divisione del lavoro prevista. CLAUDE.md è per il contesto del progetto durevole e sempre attivo. Le Skills sono per conoscenze riutilizzabili, playbook e flussi di lavoro invocabili che dovrebbero caricarsi on demand. Claude Code ha persino integrato i vecchi comandi personalizzati nello stesso meccanismo, quindi i file legacy .claude/commands/*.md funzionano ancora, ma le Skills sono ora la forma migliore a lungo termine e il blocco di costruzione più riutilizzabile in qualsiasi flusso di lavoro di sviluppo alimentato dall’IA.

Quando utilizzare le Claude Skills: CLAUDE.md vs Skills vs Hooks

Una Claude Skill vale la pena di essere creata quando continui a incollare lo stesso checklist, lo stesso playbook di deployment, lo stesso criterio di code review o gli stessi problemi noti dell’API interna nella chat. Anthropic raccomanda esplicitamente di creare una skill quando riutilizzi spesso la stessa procedura, o quando una sezione di CLAUDE.md si è evoluta in un processo piuttosto che in un fatto. Questa è la risposta pratica alla domanda frequente “Cos’è una Claude Skill e quando si dovrebbe usarne una”. Usa una Skill per procedure ripetibili, non per gusti generali o regole ampie del repository.

Il vero vantaggio è il controllo sui costi del contesto e sul comportamento. Una buona Skill viene caricata solo quando è rilevante, mentre un CLAUDE.md gonfio viene caricato in ogni sessione. Anthropic raccomanda di mantenere CLAUDE.md breve e di spostare le conoscenze di dominio o le procedure nelle Skills proprio perché il caricamento on demand mantiene l’agente focalizzato sul task davanti a sé.

La mia regola opinabile è semplice. Se un’istruzione dovrebbe applicarsi in ogni singola sessione, appartiene a CLAUDE.md. Se l’istruzione è un metodo, checklist o flusso di lavoro riutilizzabile che conta solo a volte, appartiene a una Skill. Se un’azione deve accadere automaticamente a ogni evento corrispondente, probabilmente appartiene a un hook, non a una Skill. L’overview delle funzionalità di Anthropic inquadra questi strumenti in un modello di stratificazione quasi identico.

Un segnale pratico per ciascuno: se ti trovi a incollare le stesse istruzioni in ogni chat, quella è una Skill. Se una sezione di CLAUDE.md si è trasformata in un processo passo-passo, estraila in una Skill. Se vuoi che qualcosa si attivi silenziosamente ogni volta che un file viene salvato, scrivi invece un hook.

Supporto IDE per le Claude Skills: VS Code, JetBrains, Cursor e Codex

Claude Code funziona su CLI, Desktop, VS Code, JetBrains, web e flussi di controllo remoto correlati ai dispositivi mobili. Anthropic descrive la CLI come la superficie locale più completa, mentre le integrazioni IDE scambiano alcune capacità disponibili solo su CLI per una revisione nativa dell’editor, il contesto del file ed ergonomia del flusso di lavoro più stretta. La configurazione, la memoria del progetto e i server MCP sono condivisi tra le superfici locali, quindi la tua configurazione .claude ti segue piuttosto che rimanere intrappolata in un editor.

Per VS Code, Anthropic afferma che l’estensione è l’interfaccia raccomandata all’interno dell’editor. Fornisce revisione del piano, diff inline, supporto per menzioni di file e accesso integrato alla CLI. La stessa procedura di installazione espone anche un percorso diretto per Cursor. Per JetBrains, l’elenco attualmente supportato include IntelliJ IDEA, PyCharm, Android Studio, WebStorm, PhpStorm e GoLand, con visualizzazione dei diff, condivisione della selezione, scorciatoie di riferimento file e condivisione delle diagnostiche integrate nel plugin.

Il supporto per JetBrains è migliore di quanto molti sviluppatori si rendano conto. Se esegui claude dal terminale integrato dell’IDE, le funzioni di integrazione sono attive automaticamente. Se inizi da un terminale esterno, la documentazione di Anthropic descrive il comando /ide per riconnettere Claude Code alla sessione di JetBrains, e raccomanda esplicitamente di lanciare dal root del progetto affinché Claude veda gli stessi file che vedi nel tuo IDE. Se usi le modalità di modifica automatica in JetBrains, Anthropic avvisa anche che i file di configurazione dell’IDE possono diventare parte della superficie modificabile, quindi le approvazioni manuali sono il predefinito più sicuro in quell’ambiente.

Ora il punto più importante. Le Claude Skills non sono solo una cosa di Claude Code. Agent Skills è uno standard aperto. Il quickstart ufficiale di Agent Skills afferma che la stessa skill può funzionare in VS Code con GitHub Copilot, Claude Code e OpenAI Codex, e la documentazione stessa di Codex di OpenAI afferma che le Skills sono disponibili nel CLI di Codex, nell’estensione IDE e nell’app. La guida all’implementazione di Agent Skills aggiunge un dettaglio importante sulla portabilità: .agents/skills si è affermato come convenzione cross-client, mentre alcuni client scansionano anche .claude/skills per compatibilità pragmatica.

Ecco quindi la regola di compatibilità pratica che raccomando. Se stai costruendo principalmente per Claude Code, scrivi in .claude/skills. Se desideri genuinamente la portabilità cross-client, punta sulla forma aperta di Agent Skills e usa .agents/skills come percorso canonico. Non fingere che questi due obiettivi siano identici. Sono correlati, non identici.

Riferimento rapido sulla compatibilità:

Struttura del file SKILL.md, layout delle cartelle e posizioni di archiviazione

Una Skill corretta è una cartella, non un file markdown casuale posizionato alla radice del repository. La specifica di base richiede una directory con un file SKILL.md e consente directory opzionali scripts/, references/ e assets/. SKILL.md deve contenere frontmatter YAML seguito da istruzioni in markdown. Nella specifica, name e description sono obbligatori, name è limitato a 64 caratteri usando lettere minuscole, numeri e trattini, compatibility è solo per requisiti ambientali reali, e allowed-tools è esplicitamente sperimentale tra le implementazioni.

Claude Code è un po’ più flessibile rispetto alla specifica portabile perché può derivare un nome dalla directory e fare affidamento sul primo paragrafo quando description manca. Non dovresti affidarti a questo se ti importa della portabilità o della prevedibilità. Claude.ai richiede che il nome della directory corrisponda al campo name, e il suo percorso di caricamento skill personalizzato limita le descrizioni a 200 caratteri anche se la specifica più ampia ne permette molti di più. La scelta portabile è impostare un name esplicito, mantenere la directory identica e scrivere una descrizione precisa che si adatti ai limiti stretti. Questo risponde all’argomento delle domande frequenti “Cosa dovrebbe contenere un file SKILL.md” senza giri di parole.

Inizia da una struttura noiosa come questa:

repo/
  .claude/
    skills/
      review-pr/
        SKILL.md
        scripts/
          review.sh
        references/
          checklist.md
        assets/
          comment-template.md

Se la portabilità tra client compatibili con Skills è più importante della comodità di Claude Code, mantieni la stessa forma interna e sostituisci .claude/skills/ con .agents/skills/. La struttura delle cartelle è la stessa idea in entrambi i casi.

Per Claude Code, le posizioni di archiviazione sono semplici. Le skills del progetto risiedono in .claude/skills/<nome-skill>/SKILL.md. Le skills personali risiedono in ~/.claude/skills/<nome-skill>/SKILL.md. Le skills distribuite tramite plugin risiedono sotto <plugin>/skills/<nome-skill>/SKILL.md. La documentazione di Anthropic descrive la precedenza tra gli ambiti built-in come enterprise su personale su progetto, mentre le skills dei plugin evitano collisioni usando una forma con namespace come plugin-name:skill-name. Su Windows, ~/.claude si risolve in %USERPROFILE%\.claude, e CLAUDE_CONFIG_DIR può spostare l’intera directory base.

La scelta tra ambito di progetto e personale è semplice. Usa .claude/skills/ all’interno del repository quando la Skill è strettamente accoppiata a quella codebase — ad esempio, un playbook di deployment che conosce i nomi specifici del tuo cluster o un criterio di review tarato sulle convenzioni del tuo team. Usa ~/.claude/skills/ per Skills che viaggiano con te tra i progetti: checklist personali, generatori di changelog generici, flussi di lavoro di debug preferiti. Tutto ciò che metteresti in un repository dotfiles appartiene all’ambito personale.

Alcuni dettagli acuti meritano di essere memorizzati. SKILL.md deve essere nominato esattamente con quella casse. La guida PDF di Anthropic raccomanda nomi di cartelle kebab-case e dice esplicitamente di non inserire un README.md all’interno della cartella della skill, perché la documentazione operativa dovrebbe risiedere in SKILL.md o in references/. La stessa guida sottolinea anche che la nomenclatura di SKILL.md è case-sensitive. Questi sono vincoli noiosi, ma i vincoli noiosi sono ciò che rende gli strumenti affidabili.

Claude Code fa anche la cosa giusta per i monorepo. Scopre automaticamente le directory nidificate .claude/skills/ quando lavori all’interno di sottodirectory, il che è ideale per skills a livello di pacchetto o servizio. Monitora anche le directory delle skill esistenti per le modifiche in vivo durante la sessione corrente. L’unica trappola di riavvio è creare una directory delle skill a livello superiore che non esisteva quando la sessione è iniziata. Anthropic documenta questo come il caso in cui hai davvero bisogno di riavviare affinché la nuova directory possa essere monitorata.

Best Practice per le Claude Skills: Descrizioni, Script e Ambito

Il modo più veloce per creare una Skill inutile è chiedere a un LLM di inventarne una a partire da conoscenze di formazione generiche. La guida alle best practice di Anthropic avverte esattamente contro questo. I pezzi preziosi sono le correzioni specifiche del dominio, i casi limite, le scelte degli strumenti e le convenzioni che il modello non inventerebbe in modo affidabile da solo. Il flusso di lavoro corretto è risolvere il task una volta con l’agente, correggere finché non funziona, poi estrarre il metodo in una Skill.

Definisci l’ambito della Skill come una buona funzione, non come una wiki. Anthropic dice che le Skills dovrebbero incapsulare un’unità di lavoro coerente. Troppo strette, e costringi più skills a impilarsi per un singolo task. Troppo ampie, e l’agente non può attivarle con precisione. La guida alle best practice è diretta: le skills eccessivamente complete possono fare più danni che aiuto perché il modello insegue istruzioni irrilevanti e perde il segnale.

La qualità della descrizione non è una preoccupazione cosmetica. È il livello di instradamento. Sia Anthropic che i documenti di Agent Skills dicono che il campo description è il meccanismo primario che il modello usa per decidere se caricare una Skill o meno. Le buone descrizioni dicono cosa fa la Skill, quando usarla e le frasi di attivazione o i tipi di file che un utente menzionerebbe realmente. Le cattive descrizioni sono vaghe, eccessivamente tecniche o abbastanza ampie da abbinare il nonsenso. Questa è la risposta reale alla domanda frequente “Perché una Claude Skill non si attiva”. Di solito il router è cattivo, non il modello.

Il contrasto è chiaro a fianco:

Descrizioni cattive — troppo vaghe per instradare in modo affidabile:

• Aiuta con le code review — corrisponde a tutto, non disambigua nulla
• Utile per task di sviluppo — più ampio di una query di ricerca
• Assiste nella scrittura — non è un router, solo un’etichetta di categoria

Descrizioni buone — linguaggio di attivazione specifico:

• Review delle pull request per problemi di sicurezza, rischio di migrazione e test mancanti. Usa quando recensioni una PR, un git diff o una modifica critica per il rilascio.
• Genera un changelog dall'output di git log. Usa quando prepari un rilascio, scrivi note di rilascio o riassumi commit dall'ultimo tag.
• Scaffold di un nuovo gestore HTTP Go con validazione della richiesta e middleware di errore. Usa quando aggiungi un nuovo endpoint o route a un servizio Go.

Il pattern è lo stesso ogni volta: dichiara cosa fa la Skill, nomina le frasi esatte dell’utente che dovrebbero attivarla e, opzionalmente, nomina i tipi di file o gli strumenti che sono rilevanti. Se la tua descrizione corrisponderebbe a una query generica di Google, non è abbastanza specifica.

Se un flusso di lavoro ha effetti collaterali, rendilo manuale. Claude Code espone questo direttamente. disable-model-invocation: true rende una Skill invocabile solo dall’utente, cosa che Anthropic raccomanda per azioni come deployment, commit o messaggi in uscita. user-invocable: false va nella direzione opposta e nasconde la Skill dal menu slash permettendo ancora a Claude di usarla come conoscenza di background. Questo risponde all’argomento delle FAQ “Quando una skill dovrebbe essere manuale invece che automatica” in una frase: manuale per il rischio, automatico per guida ripetibile sicura.

Mantieni SKILL.md abbastanza piccolo da rimanere intelligibile. Anthropic raccomanda di mantenerlo sotto 500 righe e intorno ai 5.000 token, spostando poi il materiale dettagliato in references/ o file simili con istruzioni di caricamento esplicite. “Leggi references/api-errors.md se l’API restituisce un non-200” è un buon pattern. “Vedi references/” è pigro. Claude Code inietta anche la Skill renderizzata nella conversazione come messaggio e non continua a rileggere il file nei turni successivi. Dopo la compattazione del contesto, solo i contenuti recenti della Skill vengono portati avanti entro i budget dei token. Le Skills enormi sono quindi non solo brutte. Sono fragili nelle sessioni lunghe.

Una buona SKILL.md può rimanere molto semplice:

---
name: review-pr
description: Review delle pull request per problemi di sicurezza, rischio di migrazione e test mancanti. Usa quando recensioni una PR, un git diff o una modifica critica per il rilascio.
compatibility: Progettato per Claude Code. Richiede git e gh.
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(gh pr diff *) Read Grep Glob
---
# Review PR

Leggi references/checklist.md prima di eseguire qualsiasi comando.

1. Raccogli il diff e i file modificati.
2. Segnala problemi di correttezza, sicurezza e copertura dei test.
3. Restituisci i risultati raggruppati per gravità con riferimenti ai file.
4. Suggerisci prima la correzione più piccola e sicura.

Usa gli script quando il determinismo conta più dell’eloquenza. La guida sugli script delle Skills è eccellente qui. Dice che gli script rivolti all’agente devono evitare prompt interattivi, documentare l’uso tramite --help, emettere messaggi di errore utili, preferire output strutturati come JSON o CSV su stdout, inviare diagnostiche su stderr e supportare l’uso retry-safe. Raccomanda anche di fissare versioni di strumenti one-off e descrivere i requisiti di runtime esplicitamente in SKILL.md o nel campo compatibility piuttosto che presumere che l’ambiente abbia i pacchetti giusti.

Uno script rivolto all’agente minimo ma corretto è simile a questo:

#!/usr/bin/env bash
# scripts/collect-diff.sh — chiamato dalla skill review-pr
# Usage: collect-diff.sh <base-ref> [<head-ref>]
set -euo pipefail

BASE="${1:?Usage: collect-diff.sh <base-ref> [<head-ref>]}"
HEAD="${2:-HEAD}"

# Output strutturato su stdout affinché l'agente possa analizzarlo
git diff "${BASE}...${HEAD}" --stat --name-only \
  | jq -Rs '{
      "changed_files": split("\n") | map(select(length > 0))
    }' \
  || { printf '{"error":"git diff failed"}\n' >&2; exit 1; }

Tre cose rendono questo sicuro per l’agente. set -euo pipefail assicura che lo script esca rumorosamente a qualsiasi fallimento invece di procedere silenziosamente. JSON su stdout dà all’agente un formato che può analizzare senza indovinare. Le diagnostiche vanno su stderr affinché lo stream stdout dell’agente rimanga pulito. Niente di tutto questo è astuto. Tutto è necessario.

Una trappola sottile è allowed-tools. Nella specifica è sperimentale e il supporto varia. In Claude Code pre-approva strumenti specifici mentre la Skill è attiva, ma non restringe l’universo degli strumenti richiamabili, e le regole di negazione appartengono ancora ai permessi di Claude Code. Nel SDK di Claude Agent, Anthropic dice esplicitamente che il frontmatter allowed-tools in SKILL.md non si applica, quindi le app SDK devono far rispettare l’accesso agli strumenti nella configurazione principale allowed_tools o allowedTools. Se ignori questa differenza, la tua Skill si comporterà diversamente nella CLI e nell’automazione alimentata dal SDK.

Un pattern avanzato merita di essere rubato. Quando un flusso di lavoro inonderebbe il tuo thread principale con log, ricerche di file o output di ricerca lunghi, Claude Code permette a una Skill di eseguire in un subagente forcellato usando context: fork e un agent come Explore. Anthropic mostra questo per i flussi di lavoro di ricerca, dove il lavoro pesante avviene in un contesto isolato e la conversazione principale riceve il riassunto. Per l’esplorazione profonda della codebase, questo è un design molto migliore rispetto a una Skill inline gigante che inquina la sessione principale.

Una Skill forcellata appare così nel frontmatter:

---
name: explore-codebase
description: Esplorazione profonda di una codebase sconosciuta. Usa quando ti onboarding a un nuovo repository, auditi l'architettura o mappi le dipendenze dei moduli.
context: fork
agent: Explore
compatibility: Richiede Claude Code CLI.
---
# Esplora Codebase

1. Percorri l'albero delle directory e riassumi i moduli di livello superiore.
2. Identifica i punti di ingresso principali e le loro responsabilità.
3. Mappa il grafo delle dipendenze tra i pacchetti.
4. Restituisci un riassunto strutturato alla sessione principale — non l'elenco grezzo dei file.

La riga chiave è context: fork. Senza di essa, l’output dell’esplorazione atterra inline nella tua conversazione. Con essa, il subagente esegue nel proprio contesto finestra e restituisce un riassunto. La differenza conta nei repository grandi dove la sola esplorazione può consumare migliaia di token.

Testing delle Claude Skills: Trigger, Correttezza e Confronti Baseline

Una Skill non è testata solo perché un demo con percorso felice ha funzionato una volta. La guida di Anthropic divide il testing in tre livelli: testing manuale in Claude.ai, testing scriptato in Claude Code e testing programmatico tramite l’API Skills. Le aree di valutazione raccomandate sono il trigger, la correttezza funzionale e le prestazioni rispetto a una baseline senza la Skill. Questa è anche la migliore risposta alla domanda frequente “Come si testa se una skill è affidabile”. Si testa la selezione del percorso, la qualità dell’output e l’efficienza, non solo se il modello sembrava sicuro.

La guida ufficiale per le valutazioni offre una struttura pulita per i casi di test. Ogni caso dovrebbe includere un prompt utente realistico, una descrizione leggibile dall’humano dell’output atteso e file di input opzionali. I documenti memorizzano quelli in evals/evals.json all’interno della directory della Skill, che è una convenzione sensata anche se crei il tuo proprio telaio.

Usa un file di fixture e un layout di valutazione senza fronzoli come questo:

{
  "skill_name": "review-pr",
  "evals": [
    {
      "id": 1,
      "prompt": "Review questa PR per problemi di sicurezza e test mancanti",
      "expected_output": "Risultati raggruppati per gravità con riferimenti ai file e almeno una raccomandazione di test.",
      "files": ["evals/files/pr-diff.patch"]
    },
    {
      "id": 2,
      "prompt": "Riassumi i commit della scorsa settimana",
      "expected_output": "La skill non dovrebbe attivarsi.",
      "files": []
    }
  ]
}

La mia regola di testing è più severa di quella che la maggior parte dei team usa, ma si allinea con la guida ufficiale. Ogni Skill seria dovrebbe avere query che dovrebbero scatenare, query che non dovrebbero scatenare, almeno un test per caso limite e un confronto baseline senza la Skill. Gli esempi di Anthropic confrontano le chiamate agli strumenti, le chiamate API fallite, i loop di chiarimento e l’uso dei token con e senza la Skill perché “funziona” non è lo stesso di “migliora il flusso di lavoro”.

Se testi tramite il Claude Agent SDK, ricorda la tubatura. Le Skills sono artefatti del filesystem lì, non registrazioni programmatiche. Anthropic dice che devi abilitare lo strumento "Skill" e caricare le impostazioni del filesystem rilevanti tramite settingSources o setting_sources. Se ometti user o project, o punti cwd nel posto sbagliato, il SDK non scoprirà la Skill. Anthropic raccomanda persino di chiedere “Quali Skills sono disponibili?” come controllo di scoperta diretto.

Testa anche sul modello e sul client che intendi realmente rilasciare. Il quickstart di Agent Skills aperto avvisa esplicitamente che l’affidabilità dell’uso degli strumenti varia tra i modelli, e alcuni modelli potrebbero rispondere direttamente invece di eseguire il comando che la Skill intende. Questo non è sempre un problema di design della Skill. A volte è un problema di selezione del modello, e la tua matrice di test dovrebbe esporlo.

Risoluzione dei problemi delle Claude Skills: Fallimenti comuni e correzioni

Quando una Skill si comporta male, assumi il packaging prima dell’intelligenza. I fallimenti più comuni sono ancora quelli noiosi.

• Se la Skill non viene trovata affatto, verifica che il file sia nominato esattamente SKILL.md, con il caso corretto, all’interno della directory corretta. La guida alla risoluzione dei problemi di Anthropic evidenzia esplicitamente il caso del nome del file, e i suoi documenti Claude Code e SDK ti indirizzano direttamente a .claude/skills/*/SKILL.md e ~/.claude/skills/*/SKILL.md come primi controlli.
• Se il frontmatter è invalido, controlla prima i delimitatori YAML e le virgolette. Gli esempi di Anthropic mostrano i classici errori: --- mancante, virgolette non chiuse o nomi invalidi con spazi e maiuscole. I nomi delle skill dovrebbero essere minuscoli e con trattini.
• Se la Skill esiste ma non si attiva, la descrizione è solitamente troppo vaga. La risoluzione dei problemi di Claude Code stessa dice di includere parole chiave che gli utenti direbbero naturalmente, verificare che la Skill appaia quando chiedi “Quali skills sono disponibili?”, e provare a riformulare più vicino alla descrizione. La guida PDF di Anthropic aggiunge un grande trucco diagnostico: chiedi a Claude quando userebbe la Skill e ascolta come parafrasa la descrizione per te.
• Se la Skill si attiva troppo spesso, restringi l’ambito. Anthropic raccomanda di rendere la descrizione più specifica, aggiungere trigger negativi e usare disable-model-invocation: true per i flussi di lavoro che vuoi solo tramite comando esplicito. Il trigger eccessivo è solitamente solo linguaggio di instradamento sottospecificato.
• Se la Skill sembra perdere influenza in sessioni lunghe, ricorda che le descrizioni possono essere accorciate nel catalogo di Claude Code quando sono presenti molte skills, e le Skills invocate vengono portate avanti nei budget dei token dopo la compattazione. Anthropic raccomanda di caricare all’inizio parole chiave nella descrizione, tagliare il testo in eccesso e, specificamente per Claude Code, regolare SLASH_COMMAND_TOOL_CHAR_BUDGET se gli elenchi di descrizione vengono compressi troppo aggressivamente.
• Se uno script incluso si blocca o si comporta erraticamente, controlla se si aspetta input interattivo. La guida sugli script dice che gli agenti eseguono in shell non interattive, quindi i prompt TTY, le finestre di password e i menu di conferma sono bug di design. Accetta input tramite flag, variabili d’ambiente o stdin e rendi i fallimenti espliciti.
• Se il SDK non vede la tua Skill, conferma che allowed_tools includa "Skill", che settingSources o setting_sources contengano user e/o project, e che cwd punti alla directory che contiene effettivamente .claude/skills/. Senza quella configurazione, il sistema Skills non è abilitato non importa quanto corretto sembri il tuo markdown.
• Se una Skill supportata da MCP si carica ma le chiamate agli strumenti falliscono, la checklist di risoluzione dei problemi di Anthropic è sensata: verifica che il server MCP sia connesso, conferma autenticazione e scope, testa lo strumento MCP direttamente senza la Skill, poi controlla i nomi esatti degli strumenti perché sono case-sensitive.

La verità noiosa è che le buone Claude Skills sembrano un buon ingegneria operativa. Nomi chiari. File piccoli. Trigger espliciti. Script deterministici dove necessario. Test reali. Se la tua Skill si legge come un runbook preciso, l’agente ha una possibilità di combattere. Se si legge come un brainstorming, hai semplicemente nascosto il caos in una cartella.