Claude Skills e SKILL.md per sviluppatori: VS Code, JetBrains, Cursor

La maggior parte dei team usa in modo improprio Claude Skills in uno di due modi. O trasformano SKILL.md in un contenitore di tutto, o non riescono a superare la fase dei grandi prompt copiati e incollati.

Entrambi gli approcci sono approssimativi. 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.

Claude Skills sono directory ancorate da SKILL.md, con script, riferimenti e asset opzionali. Funzionano grazie alla divulgazione progressiva. L’agente inizia caricando solo metadati compatti, come il nome e la descrizione della skill, e legge le istruzioni complete solo quando il compito corrisponde. Ciò consente a un agente di mantenere disponibili molte skills senza appesantire ogni sessione fin dall’inizio.

Se operi anche Hermes Agent, la stessa struttura su disco è in linea con lo stile di specifica agentskills che Hermes documenta: l’attivazione condizionale, la scansione dell’hub e la distinzione tra segreti e configurazione sono specificate in Hermes Agent Skill Authoring — SKILL.md Structure and Best Practices.

Le stesse linee guida di Anthropic rendono piuttosto chiara la divisione del lavoro prevista. CLAUDE.md è per il contesto di progetto durevole e sempre attivo. Le Skills sono per la conoscenza riutilizzabile, i playbook e i workflow attivabili che dovrebbero essere caricati su richiesta. Questo rende le Skills il luogo naturale per codificare un ciclo di sviluppo guidato da specifiche – specifica, pianificazione, implementazione, validazione – quando si desidera più struttura della “vibe coding” ma meno cerimoniale di un intero scaffold Spec Kit. Vedi GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows per confrontare le skill di Claude Code con alternative portatili e integrate nell’IDE. Se preferisci installare quel ciclo pre-costruito e applicato, anziché crearlo tu stesso, Superpowers confeziona esattamente questo tipo di pila di skills – brainstorming, pianificazione, revisione subagent, TDD – come plugin installabile.

Claude Code ha persino incorporato 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 guidato da IA.

Quando usare Claude Skills: CLAUDE.md vs Skills vs Hooks

Ha senso creare una Claude Skill quando continui a incollare la stessa checklist, lo stesso playbook di deployment, la stessa rubrica di revisione del codice o le stesse insidie delle API interne nella chat. Anthropic raccomanda esplicitamente di creare una skill quando si continua a riutilizzare la stessa procedura, o quando una sezione di CLAUDE.md è cresciuta fino a diventare un processo anziché 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 sul costo 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 la conoscenza di dominio o le procedure nelle Skills proprio perché il caricamento su richiesta mantiene l’agente focalizzato sul compito davanti a sé.

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

Un segnale pratico per ciascuno: se ti ritrovi a incollare le stesse istruzioni in ogni chat, è una Skill. Se una sezione di CLAUDE.md è cresciuta fino a diventare un processo passo-passo, estraila in una Skill. Se vuoi che qualcosa accada silenziosamente ogni volta che un file viene salvato, scrivi un hook. C’è anche un quarto livello che vale la pena conoscere: quando un compito genera molto output intermedio rumoroso che non si vuole che ingombri la sessione principale – esplorazione del codebase, un grande run di test – è un lavoro per un subagent, non per una Skill.

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

Claude Code funziona su CLI, Desktop, VS Code, JetBrains, web e flussi di controllo remoto correlati al mobile. Anthropic descrive la CLI come la superficie locale più completa, mentre le integrazioni IDE scambiano alcune capacità solo-CLI per revisione nativa dell’editor, contesto file ed ergonomiche di workflow più strette. Configurazione, memoria di progetto e server MCP sono condivisi tra le superfici locali, quindi la tua configurazione .claude ti segue anziché essere intrappolata in un solo editor.

Per VS Code, Anthropic dice 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. Lo stesso flusso di installazione espone anche un percorso diretto per Cursor. Per JetBrains, l’elenco attuale dei supporti include IntelliJ IDEA, PyCharm, Android Studio, WebStorm, PhpStorm e GoLand, con visualizzazione diff, condivisione di selezioni, scorciatoie per riferimenti di file e condivisione diagnostica integrate nel plugin.

Il supporto JetBrains è migliore di quanto molti sviluppatori si rendano conto. Se esegui claude dal terminale integrato dell’IDE, le funzionalità di integrazione sono attive automaticamente. Se avvii da un terminale esterno, Anthropic documenta il comando /ide per riconnettere Claude Code alla sessione JetBrains, e raccomanda esplicitamente di avviare dalla stessa radice del progetto in modo che Claude veda gli stessi file che vede il tuo IDE. Se usi modalità di editing automatico in JetBrains, Anthropic avverte 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ù grande. Claude Skills non sono solo una cosa di Claude Code. Agent Skills è uno standard aperto. Il quickstart ufficiale di Agent Skills dice 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 dice che le Skills sono disponibili nella CLI di Codex, nell’estensione IDE e nell’app. La guida di implementazione di Agent Skills aggiunge un dettaglio importante di portabilità: .agents/skills è emerso come la convenzione cross-client, mentre alcuni client scansionano anche .claude/skills per compatibilità pragmatica.

Quindi ecco la regola pratica di compatibilità che raccomando. Se stai costruendo per Claude Code prima di tutto e solo per quello, crea in .claude/skills. Se vuoi genuinamente portabilità cross-client, punta alla 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 di compatibilità:

Struttura, Layout delle Cartelle e Posizioni di Archiviazione del File SKILL.md

Una Skill appropriata è una cartella, non un file markdown casuale che sta 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 di ambiente reali, e allowed-tools è esplicitamente sperimentale tra le implementazioni.

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

Parti 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 conta più 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 dirette. Le skill di progetto vivono in .claude/skills/<skill-name>/SKILL.md. Le skill personali vivono in ~/.claude/skills/<skill-name>/SKILL.md. Le skill distribuite tramite plugin vivono sotto <plugin>/skills/<skill-name>/SKILL.md. Anthropic documenta la precedenza tra gli scope integrati come aziendale su personale su progetto, mentre le skill di plugin evitano collisioni usando una forma namespaced come plugin-name:skill-name. Su Windows, ~/.claude si risolve in %USERPROFILE%\.claude, e CLAUDE_CONFIG_DIR può spostare l’intera directory di base.

La scelta tra scope di progetto e personale è diretta. Usa .claude/skills/ all’interno del repository quando la Skill è strettamente accoppiata a quel codebase – ad esempio, un playbook di deployment che conosce i nomi specifici dei tuoi cluster o una rubrica di revisione calibrata sulle convenzioni del tuo team. Usa ~/.claude/skills/ per Skills che viaggiano con te tra i progetti: checklist personali, generatori di changelog generici, workflow di debugging preferiti. Qualsiasi cosa che metteresti in un repository dotfiles appartiene allo scope personale.

Alcuni bordi taglienti valgono la memorizzazione. SKILL.md deve essere nominato esattamente con quella capitalizzazione. La guida PDF di Anthropic raccomanda nomi di cartella kebab-case e dice esplicitamente di non posizionare un README.md all’interno della cartella della skill, perché la documentazione operativa dovrebbe vivere in SKILL.md o references/. La stessa guida sottolinea anche che la nomenclatura di SKILL.md è sensibile alle maiuscole e minuscole. Questi sono vincoli noiosi, ma sono i vincoli noiosi che rendono gli strumenti affidabili.

Claude Code fa anche la cosa giusta per i monorepo. Scopre automaticamente le directory annidate .claude/skills/ quando si lavora all’interno di sottodirectory, il che è ideale per skill a livello di pacchetto o di servizio. Monitora anche le directory delle skill esistenti per modifiche live durante la sessione corrente. L’unica trappola di riavvio è creare una directory skills di livello superiore che non esisteva all’avvio della sessione. Anthropic documenta questo come il caso in cui è necessario riavviare in modo che la nuova directory possa essere monitorata.

Migliori Pratiche per Claude Skills: Descrizioni, Script e Ambito

Il modo più veloce per creare una Skill inutile è chiedere a un LLM di inventarne una da conoscenza di training generica. La guida alle migliori pratiche di Anthropic avverte contro esattamente questo. I pezzi preziosi sono le correzioni specifiche del dominio, i casi limite, le scelte di strumenti e le convenzioni che il modello non inventerebbe affidabilmente da solo. Il workflow corretto è risolvere il compito una volta con l’agente, correggerlo finché 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 stretta, e costringi a impilare più skill per un singolo compito. Troppo ampia, e l’agente non può attivarle con precisione. La guida alle migliori pratiche è schietta nel dire che le skill eccessivamente comprehensive possono danneggiare più che aiutare perché il modello insegue istruzioni irrilevanti e perde il segnale.

La qualità della descrizione non è una questione estetica. È il layer di instradamento. Sia Anthropic che i documenti di Agent Skills dicono che il campo description è il meccanismo principale 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 effettivamente. Le cattive descrizioni sono vaghe, eccessivamente tecniche o ampie abbastanza da corrispondere a sciocchezze. Questa è la vera risposta alla domanda FAQ “Perché una Claude Skill non si attiva”. Di solito è il router che è cattivo, non il modello.

Il contrasto è chiaro affiancato:

Descrizioni cattive – troppo vaghe per instradare affidabilmente:

• Helps with code review – corrisponde a tutto, non disambigua nulla
• Useful for development tasks – più ampia di una query di ricerca
• Assists with writing – non un router, solo un’etichetta di categoria

Descrizioni buone – linguaggio di attivazione specifico:

• Review pull requests for security issues, migration risk, and missing tests. Use when reviewing a PR, git diff, or release critical change.
• Generate a changelog from git log output. Use when preparing a release, writing release notes, or summarising commits since last tag.
• Scaffold a new Go HTTP handler with request validation and error middleware. Use when adding a new endpoint or route to a Go service.

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

Se un workflow ha effetti collaterali, rendilo manuale. Claude Code lo espone direttamente. disable-model-invocation: true rende una Skill solo attivabile 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 lasciando comunque Claude usarla come conoscenza di sfondo. Questo risponde all’argomento FAQ “Quando una skill dovrebbe essere manuale invece che automatica” in una frase: manuale per rischio, automatico per guida ripetibile sicura.

Mantieni SKILL.md abbastanza piccolo da restare intelligibile. Anthropic raccomanda di mantenerlo sotto le 500 righe e circa 5.000 token, poi spostare 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 modello. “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 il contenuto recente della Skill viene portato avanti entro i budget di token. Le Skill enormi non sono quindi solo brutte. Sono fragili in sessioni lunghe.

Una buona SKILL.md può restare molto piana:

---
name: review-pr
description: Review pull requests for security issues, migration risk, and missing tests. Use when reviewing a PR, git diff, or release critical change.
compatibility: Designed for Claude Code. Requires git and gh.
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(gh pr diff *) Read Grep Glob
---
# Review PR

Read references/checklist.md before running any commands.

1. Collect the diff and changed files.
2. Flag correctness, security, and test coverage issues.
3. Return findings grouped by severity with file references.
4. Suggest the smallest safe fix first.

Usa script quando la determinatezza conta più dell’eloquenza. La guida agli script per 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 strutturato come JSON o CSV su stdout, inviare diagnostica su stderr e supportare uso sicuro per retry. Raccomanda anche di fissare versioni di strumenti one-off e descrivere i requisiti di runtime esplicitamente in SKILL.md o nel campo compatibility anziché assumere che l’ambiente abbia i pacchetti giusti.

Uno script minimale ma corretto rivolto all’agente sembra così:

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

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

# Structured output to stdout so the agent can parse it
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 anziché procedere silenziosamente. JSON su stdout dà all’agente un formato che può analizzare senza indovinare. La diagnostica va su stderr in modo che il flusso stdout dell’agente resti pulito. Nessuna di queste cose è furba. Tutte sono necessarie.

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 di strumenti chiamabili, e le regole di diniego appartengono ancora alle permessi di Claude Code. Nel Claude Agent SDK, Anthropic dice esplicitamente che il frontmatter allowed-tools in SKILL.md non si applica, quindi le app SDK devono applicare l’accesso agli strumenti nella configurazione principale allowed_tools o allowedTools invece. Se ignori quella differenza, la tua Skill si comporterà diversamente nella CLI e nell’automazione guidata da SDK.

Un altro modello avanzato vale la pena rubare. Quando un workflow 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 subagent forcatato usando context: fork e un agent come Explore. Anthropic mostra questo per i workflow di ricerca, dove il lavoro pesante accade in contesto isolato e la conversazione principale riceve il riepilogo. Per l’esplorazione profonda del codebase, è un design molto migliore di una Skill inline gigante che inquina la sessione principale.

Una Skill forcatata sembra così nel frontmatter:

---
name: explore-codebase
description: Deep exploration of an unfamiliar codebase. Use when onboarding to a new repo, auditing architecture, or mapping module dependencies.
context: fork
agent: Explore
compatibility: Requires Claude Code CLI.
---
# Explore Codebase

1. Walk the directory tree and summarise the top-level modules.
2. Identify the main entry points and their responsibilities.
3. Map the dependency graph between packages.
4. Return a structured summary to the main session — not the raw file list.

La riga chiave è context: fork. Senza di essa, l’output di esplorazione atterra inline nella tua conversazione. Con essa, il subagent esegue nella sua finestra di contesto e restituisce un riepilogo. La differenza conta in repository grandi dove l’esplorazione da sola può consumare migliaia di token.

Test di Claude Skills: Trigger, Correttezza e Confronti Baseline

Una Skill non è testata perché una demo di happy-path ha funzionato una volta. La guida di Anthropic spezza il testing in tre layer: test manuale in Claude.ai, test scriptato in Claude Code e test programmatico via Skills API. Le aree di valutazione raccomandate sono attivazione, correttezza funzionale e prestazioni contro una baseline senza la Skill. Questa è anche la migliore risposta alla domanda FAQ “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 alle valutazioni dà una struttura pulita per i casi di test. Ogni caso dovrebbe includere un prompt utente realistico, una descrizione leggibile dall’uomo dell’output atteso e file di input opzionali. I documenti li archiviano in evals/evals.json all’interno della directory della Skill, il che è una convenzione sensata anche se crei il tuo harness.

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

{
  "skill_name": "review-pr",
  "evals": [
    {
      "id": 1,
      "prompt": "Review this PR for security issues and missing tests",
      "expected_output": "Findings grouped by severity with file references and at least one test recommendation.",
      "files": ["evals/files/pr-diff.patch"]
    },
    {
      "id": 2,
      "prompt": "Summarise last week's commits",
      "expected_output": "The skill should not activate.",
      "files": []
    }
  ]
}

La mia regola di test è 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 attivare, query che non dovrebbero attivare, almeno un test di caso limite e un confronto baseline senza la Skill. Gli esempi di Anthropic confrontano chiamate di strumenti, chiamate API fallite, loop di chiarimento e uso di token con e senza la Skill perché “funziona” non è la stessa cosa di “migliora il workflow”.

Se testi tramite il Claude Agent SDK, ricorda il cablaggio. 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 effettivamente rilasciare. Il quickstart aperto di Agent Skills avverte 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 per Claude Skills: Fallimenti Comuni e Correzioni

Quando una Skill si comporta male, assumi imballaggio prima che 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 la capitalizzazione giusta, all’interno della directory corretta. La guida alla risoluzione dei problemi di Anthropic cita esplicitamente la capitalizzazione del nome del file, e i suoi documenti Claude Code e SDK ti puntano dritti su .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 gli errori classici: --- mancanti, 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 è di solito 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 indietro a 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 workflow che vuoi solo per comando esplicito. L’attivazione eccessiva è di solito solo linguaggio di instradamento sotto-specificato.
• 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 attivate sono poi portate entro i budget di token dopo la compattazione. Anthropic raccomanda di caricare le parole chiave nella descrizione, tagliare il testo in eccesso e, per Claude Code specificamente, regolare SLASH_COMMAND_TOOL_CHAR_BUDGET se gli elenchi di descrizioni stanno essendo compressi troppo aggressivamente.
• Se uno script incluso si blocca o si comporta in modo erratico, controlla se si aspetta input interattivo. La guida agli script dice che gli agenti eseguono in shell non interattivi, quindi prompt TTY, dialoghi di password e 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 contenga user e/o project, e che cwd punti alla directory che contiene effettivamente .claude/skills/. Senza quella configurazione, il sistema di Skill non è abilitato non importa quanto sia corretto il tuo markdown.
• Se una Skill basata su MCP si carica ma le chiamate di strumento 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 sensibili alle maiuscole e minuscole.

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