Claude Skills vs Copilot Instructions: confronto

GitHub Copilot ha più utenti di qualsiasi altro strumento di coding AI, quindi il suo formato di personalizzazione è probabilmente il pezzo di configurazione AI più diffuso in assoluto. Milioni di repo hanno ormai un .github/copilot-instructions.md. Le Claude skills sono arrivate dopo, si sono diffuse in fretta e risolvono un problema simile in un modo diverso. Se usi entrambi gli strumenti, o stai decidendo quale merita lo sforzo di configurazione del tuo team, le differenze contano più di quanto suggerisca il marketing.

Noi gestiamo SkillProof, dove installiamo Claude skills su macchine pulite e le testiamo su lavoro reale prima di elencarle, quindi il nostro bias è dalla parte delle skill e lo diciamo subito, senza girarci intorno. Abbiamo però osservato centinaia di file di istruzioni in entrambi i formati riuscire e fallire, e le modalità di fallimento risultano quasi identiche. Questo confronto cerca di essere equo con entrambi.

In breve

Le Copilot custom instructions sono context sempre attivo per il codice. Le Claude skills sono competenza on-demand per qualsiasi task. Le instructions vincono su distribuzione al team e integrazione con l'IDE; le skill vincono su logica di attivazione, risorse incluse e tutto ciò che non è codice.

	Claude skills	Copilot custom instructions
Meccanismo	SKILL.md con un campo description; Claude carica il body quando un task corrisponde	.github/copilot-instructions.md applicato a tutto il repo, più file *.instructions.md scoped tramite glob applyTo
Attivazione	Semantica: il modello fa il match tra la tua richiesta e la description	Sempre attivo (file di repo) o match su path (glob)
Scope	Qualsiasi task che Claude gestisce: codice, documenti, email, analisi	Codice e superfici Copilot: chat, code review, coding agent
Portabilità	Un formato unico su Claude Code, claude.ai, desktop, API	Legata a Copilot; supporto parziale che varia per IDE e superficie
Risorse incluse	Script, template, file di reference, caricati in modo lazy	Solo testo markdown
Comportamento sui token	~100 token idle per skill; il body completo si carica al trigger	L'intero file applicabile si allega a ogni richiesta
Ecosistema	Migliaia di skill della community, per lo più non testate	Perlopiù file privati per repo; stanno emergendo awesome-list, anch'esse non testate

Se devi ricordarti solo una riga: le instructions descrivono la tua codebase, le skill descrivono una capacità. Sono lavori diversi, e la maggior parte dei team alla fine vuole entrambi. Per un inquadramento sul fronte skill, la nostra guida completa alle Claude skills copre il formato in profondità. Entrambi i formati cambiano il comportamento di un modello; collegare un modello a dati esterni è un asse diverso, trattato in Claude skills vs MCP servers.

Cosa sono davvero le Copilot custom instructions

Il cuore del sistema è un unico file: .github/copilot-instructions.md, committato nel repository. Copilot Chat lo legge automaticamente e lo antepone alle richieste in quel repo, su VS Code, Visual Studio, IDE JetBrains e github.com. Il coding agent lo legge quando lavora su issue; Copilot code review lo legge quando revisiona le pull request. Un solo file markdown, e ogni superficie Copilot che tocca il repo si comporta di conseguenza.

Nel 2025 GitHub ha esteso il formato con file di istruzioni scoped: .github/instructions/*.instructions.md, ciascuno con un frontmatter che punta a percorsi di file specifici.

---
applyTo: "src/api/**/*.ts"
---

All API route handlers return the ApiResponse<T> envelope.
Never throw inside a handler; return err() with a typed error code.

Il glob fa esattamente quello che dice. Modifichi un file sotto src/api/, e queste instructions viaggiano insieme alla richiesta. Modifichi un README, e non lo fanno. Ci sono anche le personal instructions, impostate nelle tue impostazioni Copilot su github.com, e le organization instructions, che gli admin Business ed Enterprise possono spingere a ogni membro.

I punti di forza qui meritano una lettura onesta, perché sono reali.

Le instructions sono repo-native. Il file vive dove vive il codice, e le modifiche passano dalla review delle pull request come qualsiasi altra cosa. Quando qualcuno aggiorna la convenzione di error handling, il diff è visibile e tutto il team lo riceve al pull. Niente nell'ecosistema Claude distribuisce la configurazione di team in modo altrettanto pulito, tranne le skill a livello di progetto in .claude/skills/, che prendono in prestito lo stesso trucco.

Il targeting via glob è preciso in un modo che il triggering semantico non è. applyTo: "**/*.test.ts" scatta esattamente su quei file, ogni volta, senza ambiguità. Una Claude skill scatta quando il modello decide che la description corrisponde, il che è flessibile e occasionalmente sbagliato. Per regole che si mappano su percorsi di file, il deterministico batte l'intelligente.

E la portata è ampia. Lo stesso file governa la chat live nell'editor e le superfici asincrone dove nessun umano è al timone: code review e coding agent. Quell'integrazione con la review, in particolare, non ha un equivalente diretto tra le skill.

Cosa fanno le skill che le instructions non possono fare

La differenza strutturale è l'attivazione. Un file Copilot instructions è sempre nel prompt (o ci finisce via path-matching). Una skill sta su disco a un costo di circa 100 token di metadata finché un task non corrisponde davvero alla sua description, poi si carica il body completo. Questo è progressive disclosure, e cambia cosa ti puoi permettere di scrivere.

Un file di instructions deve restare corto perché ogni riga pesa su ogni richiesta; la guida ufficiale di GitHub dice di tenerlo breve, e i file gonfi si diluiscono da soli finché il modello inizia a ignorare la parte centrale. Il body di una skill può arrivare a migliaia di parole, più file di reference che si caricano solo quando servono, perché niente di tutto ciò costa nulla finché non è rilevante. La nostra Test-Driven Development skill testata porta con sé un'intera disciplina red-green-refactor che sarebbe assurdo iniettare in ogni richiesta; come skill, si attiva quando costruisci una feature e resta silenziosa quando chiedi cosa fa una regex.

Le skill inoltre includono anche cose che non sono prosa. Una cartella skill può portare script eseguibili, template di documenti, checklist ed esempi svolti; la skill DOCX include codice che manipola davvero l'XML di Word. Le Copilot instructions sono testo markdown, punto. Puoi descrivere una procedura; non puoi spedire lo strumento che la esegue.

Poi c'è il confine che conta di più per chi non è sviluppatore: le Copilot instructions finiscono dove finisce il codice. Configurano un assistente di coding. Le Claude skills configurano Claude, che le persone usano per contratti, fogli di calcolo, cold email, appunti di riunione e analisi dati. Una skill come Code Review Checklist si sovrappone al territorio di Copilot, ma metà del nostro catalogo non ha un equivalente Copilot nemmeno in teoria. Se il tuo uso dell'AI va oltre l'IDE, i file di instructions non erano mai destinati a coprirlo.

Una nota sul formato: le skill sono portabili su ogni superficie Claude. La stessa cartella funziona in Claude Code, si carica su claude.ai e si allega alle richieste API. Le Copilot instructions sono portabili sulle superfici Copilot, il che è più limitato, anche se la lenta convergenza del settore verso AGENTS.md (che ora anche Copilot legge) sta iniziando a sfumare i confini.

Cosa fanno le instructions che le skill non possono fare

L'equità va in entrambe le direzioni, e ci sono tre lavori in cui le Copilot instructions sono semplicemente lo strumento migliore.

Il contesto per la PR review è il più importante. Copilot code review gira sull'infrastruttura di GitHub contro le tue pull request, e legge il tuo file di instructions quando lo fa. Scrivi "segnala qualsiasi nuovo endpoint privo di rate limit" e il reviewer lo applica a ogni PR, di ogni contributor, che abbia configurato qualcosa in locale oppure no. Claude non ha un equivalente hosted che raccolga le tue skill automaticamente su ogni pull request; dovresti collegarlo tu stesso via CI.

La policy a livello di organizzazione è il secondo punto. Un admin Copilot Enterprise può impostare instructions che raggiungono ogni sviluppatore dell'org senza che nessuno di loro installi nulla. Le Claude skill si installano per macchina o per repo. Per un platform team che cerca di far rispettare "non suggerire mai il client di auth deprecato" su 400 ingegneri, il push dall'alto batte lo sperare che tutti clonino i dotfile giusti.

Terzo, il comportamento IDE-native. Le instructions modellano Copilot dentro l'editor in cui le persone già vivono, senza nessuno strumento separato da adottare. La questione dell'attivazione non si pone proprio perché non c'è attivazione: il context è semplicemente lì, a ogni richiesta. Per fatti sempre veri su una codebase, always-on è il comportamento corretto, ed è lo stesso motivo per cui Claude Code ha CLAUDE.md accanto alle skill. Abbiamo fatto lo stesso ragionamento in Claude skills vs Cursor rules: ogni strumento finisce per aver bisogno sia di un livello sempre caricato sia di uno on-demand, e gli strumenti differiscono soprattutto per quale dei due livelli hanno costruito bene.

Convertire tra i due formati

I formati sono abbastanza vicini da rendere la migrazione soprattutto una questione di riorganizzazione. Ecco un blocco realistico da un copilot-instructions.md:

## Error handling

- All service functions return Result<T, AppError>, never throw.
- Map external errors to AppError codes in the adapter layer only.
- Log with the request ID from context; never log raw error objects
  from third-party SDKs, they can contain tokens.
- New AppError codes go in errors/codes.ts with a doc comment.

Come skill, la stessa conoscenza guadagna una condizione di trigger e spazio per crescere:

---
name: error-handling-conventions
description: Applies our Result-based error handling conventions when
  writing or reviewing service code, adding error paths, or creating
  new AppError codes. Use when the user works on error handling,
  exceptions, or failure cases in the services layer.
---

# Error handling conventions

When writing or modifying service-layer code:

1. Service functions return Result<T, AppError>. Never throw from
   a service function. If you find existing code that throws,
   flag it, do not silently rewrite it.
2. Map external errors to AppError codes in the adapter layer only.
   If a service needs a new mapping, it belongs in the adapter.
3. Log with the request ID from context. Never log raw error
   objects from third-party SDKs; they can contain tokens.
4. New AppError codes go in errors/codes.ts with a doc comment
   explaining when the code fires.

For retry and timeout conventions, see [resilience.md](resilience.md).

Nota cosa è cambiato. La description ora porta con sé frasi trigger, la parte che gli autori sbagliano più spesso; description vaghe non scattano mai. Il body ha guadagnato vincoli negativi ("segnalalo, non riscriverlo silenziosamente") che un file always-on non può permettersi in termini di token. E l'ultima riga punta a un file di reference che si carica solo quando si parla di retry.

La direzione inversa è un esercizio di compressione. Prendi il body di una skill, tieni le regole che si applicano a ogni richiesta nei path di destinazione, taglia le procedure e i casi limite, e riversa il risultato in un file scoped:

---
applyTo: "src/services/**/*.ts"
---

Service functions return Result<T, AppError> and never throw.
Error mapping lives in the adapter layer. Log with the request ID;
never log raw third-party error objects.

Cosa perdi facendo così: il caricamento condizionale e il materiale di reference incluso. Cosa guadagni: le regole ora governano anche Copilot code review su ogni PR che tocca src/services/. Nessuno dei due scambi è sbagliato. Sono solo posizionamenti diversi della stessa conoscenza.

Far girare Claude Code e Copilot insieme

Molti team non scelgono affatto, e la divisione del lavoro che emerge è abbastanza coerente da poter essere descritta.

Copilot gestisce il livello dentro l'editor più la PR review, configurato da file di instructions che descrivono la codebase. Claude Code gestisce il livello di sessione: feature multi-file, refactor, investigazioni di debugging, e il lavoro di contorno come changelog e documenti di migrazione, configurato tramite CLAUDE.md per i fatti sul repo e le skill per le capacità. La sovrapposizione è più piccola di quanto sembri, perché gli strumenti stanno su altitudini diverse. L'autocompletamento vuole regole brevi e sempre vere; un agente che porta avanti un task di 40 minuti vuole procedure.

Il setup pratico che vediamo funzionare: tenere .github/copilot-instructions.md e CLAUDE.md come fratelli che dicono le stesse cose nel dialetto di ciascuno strumento (alcuni team generano entrambi da un unico file sorgente), usare glob applyTo per regole di codice scoped su path, e usare le skill per tutto ciò che è procedurale. Una Git Workflow skill che gestisce la tua disciplina di branching e commit non ha un'espressione utile come Copilot instruction, e una regola "usiamo pnpm, non npm" non ha motivo di esistere come skill. Se stai costruendo da zero la parte Claude di tutto questo, la nostra classifica delle migliori skill di coding è ordinata per punteggio testato.

Anche il confine non è fisso. I team che partono con Copilot per il completamento tendono nel tempo ad affidare sempre più lavoro agentico a Claude Code, non perché le instructions falliscano, ma perché uno strumento di sessione con le skill ripaga di più sui task lunghi. Succede anche il contrario: team profondamente dentro Claude Code tengono comunque Copilot perché l'integrazione con la PR review è così comoda. Trattate la divisione come un default, non come un dogma.

Un avvertimento dai nostri test: la duplicazione va alla deriva. Quando il file Copilot dice che i service non lanciano mai eccezioni e la skill dice che i service possono lanciarle nel layer adapter, ottieni due assistenti che applicano con sicurezza regole diverse. Chiunque possieda la convenzione dovrebbe possedere entrambi i file nella stessa PR.

Nessuno testa i file di instructions nemmeno lì

Ecco la simmetria scomoda. Abbiamo costruito SkillProof perché circa metà delle skill Claude della community che installiamo fallisce al primo tentativo, un pattern che abbiamo documentato in perché metà delle Claude skill non funzionano. Le due modalità di fallimento dominanti sono installazioni che non funzionano nemmeno seguendo le istruzioni del README e description troppo vaghe per scattare mai.

Le Copilot instructions hanno la stessa malattia con sintomi diversi. Le liste awesome-copilot e le raccolte di file di istruzioni che si diffondono su GitHub sono lo stesso markdown non testato: file copiati da un post di blog dentro .github/, mai verificati contro il comportamento reale del modello. Le modalità di fallimento si mappano quasi una a uno. Una description vaga per una skill significa che la skill non scatta mai; un file di instructions gonfio significa che le regole si diluiscono finché il modello le ignora. Un body di skill che ripete il comportamento di default del modello non aggiunge nulla; un file di instructions pieno di "scrivi codice pulito e ben documentato" non aggiunge nulla. In entrambi gli ecosistemi, l'esistenza del file viene scambiata per la sua funzione.

La differenza è che il fallimento di un file di instructions è più silenzioso. Una skill che non scatta mai è almeno rilevabilmente inerte. Un file di instructions è sempre tecnicamente "applicato", quindi i team danno per scontato che funzioni, e nessuno fa il confronto con-e-senza che mostrerebbe se cambia davvero l'output. Quel confronto è esattamente il nostro criterio di output per le skill, ed è il test che suggeriremmo anche per il tuo file Copilot: prendi tre task reali, eseguili con il file di instructions presente e assente, e confronta i risultati. Se non riesci a distinguerli, hai pagato token per un placebo.

FAQ

GitHub Copilot può usare le Claude skills?

No. Le skill sono un formato lato Claude letto da Claude Code, claude.ai e l'API. Copilot non può caricare un SKILL.md, anche se Copilot offre i modelli Claude come backend; il modello è intercambiabile, il livello di configurazione no. La conoscenza dentro una skill di solito si converte in un file di instructions, meno il caricamento condizionale e qualsiasi script incluso.

Le Claude skills funzionano insieme alle instructions di repository come copilot-instructions.md?

Coesistono senza conflitti perché ogni strumento legge solo i propri file. Claude Code ignora .github/copilot-instructions.md, e Copilot ignora .claude/skills/. Il rischio non è una collisione, è la deriva: due file che codificano la stessa convenzione finiranno per essere in disaccordo a meno che non vengano mantenuti insieme.

Cosa è meglio per far rispettare gli standard di coding del team?

Per regole che si mappano su percorsi di file e devono raggiungere ogni contributor, le Copilot instructions con glob applyTo, perché si applicano anche a Copilot code review sulle PR. Per gli standard procedurali, tipo come eseguire una migrazione, le skill, perché possono contenere procedure lunghe e caricarle solo quando rilevanti. La maggior parte dei documenti di standard contiene entrambi i tipi e conviene dividerli di conseguenza.

Le Copilot instructions costano meno token delle skill?

Di solito è il contrario. Un file di instructions applicabile si allega a ogni richiesta, quindi un file da 1.500 token costa 1.500 token per ogni interazione, che sia rilevante oppure no. Una skill costa circa 100 token da idle e carica il proprio body solo su un match. L'always-on vale la pena pagarlo quando le regole si applicano davvero a ogni richiesta, ed è per questo che i file di instructions brevi battono quelli lunghi.

Dovrei convertire il mio copilot-instructions.md in skill se passo a Claude Code?

Dividilo invece di convertirlo. I fatti sempre veri sul repo, i suoi comandi di build e le sue convenzioni, appartengono a CLAUDE.md, che è l'analogo più vicino. Le sezioni procedurali, tutto ciò che si legge come "quando fai X, segui questi passaggi," appartengono alle skill così che si carichino on-demand. Una conversione diretta di solito produce o un CLAUDE.md gonfio o skill che scattano su tutto.