Quando lavori con GitHub Copilot su un progetto reale, la qualità delle risposte dipende molto da quanto contesto il modello ha e da quali convenzioni deve rispettare. Due meccanismi distinti governano questo aspetto: le custom instructions, che stabiliscono regole persistenti, e le context variables, che iniettano contesto puntuale in una singola richiesta. Confonderle è uno degli errori più comuni all’esame.

Custom instructions: convenzioni persistenti

Le custom instructions sono istruzioni scritte una volta e applicate automaticamente a ogni richiesta di Copilot Chat, senza doverle ripetere nel prompt. Servono a codificare preferenze stabili: stile di codice, linguaggi e framework, convenzioni di naming, requisiti di sicurezza, formato dei test.

Il caso più tipico è il file di repository:

.github/copilot-instructions.md

Contiene testo in linguaggio naturale (non un formato rigido) e vale per tutti gli sviluppatori che usano Copilot in quel repository. È il posto giusto per frasi come “Usa TypeScript strict mode”, “I test vanno scritti con Vitest”, “Non introdurre dipendenze senza motivarle”.

La portata (scope) è il concetto chiave da padroneggiare:

  • Repository — il file .github/copilot-instructions.md versionato nel repo; condiviso col team.
  • Path-specific — file *.instructions.md in .github/instructions/ con un campo applyTo (glob) che li limita a determinati percorsi, es. applicare regole diverse a src/api/** rispetto a tests/**.
  • Personali — impostate nel proprio profilo/editor, valgono per il singolo utente su tutti i progetti.
  • Organization — disponibili con Copilot Business/Enterprise, applicate a livello di tutta l’organizzazione dagli amministratori.

Quando più livelli sono attivi, le istruzioni si combinano: quelle di organizzazione, repository e personali concorrono tutte al contesto. Vanno quindi tenute coerenti per evitare conflitti.

Context variables: contesto ad-hoc

Le context variables (chat variables) inseriscono informazioni specifiche in quel momento, dentro un singolo messaggio di chat. Sono ideali quando la domanda riguarda un pezzo preciso di codice e non vuoi che il modello “indovini” a cosa ti riferisci.

Le più usate:

  • #file — allega un file specifico come contesto (#file:src/auth.ts).
  • #selection — passa il codice attualmente selezionato nell’editor.
  • #editor — il contenuto visibile del file aperto.
  • #codebase — chiede a Copilot di cercare nell’intero workspace i file rilevanti.
  • #changes, #terminalLastCommand, #terminalSelection — diff, ultimo comando eseguito, output del terminale.

Si affiancano ai chat participants (@workspace, @terminal, @vscode) e agli slash command (/explain, /fix, /tests), che orientano l’intento della richiesta. La differenza operativa: la variabile fornisce dati, il participant fornisce un dominio di competenza.

Quando usare cosa

  • Regola che vale sempre e per tutti → custom instruction (persistente, versionata).
  • Riferimento a un file o a una selezione per una domanda one-shot → context variable (effimera, non lascia traccia).
  • Convenzioni diverse per aree diverse del repo → path-specific instructions con applyTo.

Un buon prompt efficace combina i tre livelli: le istruzioni impongono lo stile, la variabile mette a fuoco il codice giusto, il participant/slash command dichiara l’obiettivo (spiegare, correggere, testare).

Il limite da ricordare

Custom instructions e context variables guidano il modello ma non ne garantiscono l’output. Copilot resta un assistente probabilistico: può ignorare parte delle istruzioni, allucinare API o proporre codice non conforme nonostante le regole. Le istruzioni riducono la varianza, non sostituiscono la revisione umana, i test e i controlli di sicurezza. All’esame, ogni scenario che implica “quindi non serve più verificare” è una trappola.

Trappole tipiche d’esame

  • Scenario: vuoi che una convenzione valga per tutto il team, versionata nel progetto → Risposta: aggiungila a .github/copilot-instructions.md nel repository, non come istruzione personale.
  • Scenario: ti serve che Copilot consideri un file specifico solo per questa domanda → Risposta: usa la context variable #file, non una custom instruction (che sarebbe persistente e sovradimensionata).
  • Scenario: “le custom instructions garantiscono che Copilot rispetti sempre le regole di sicurezza” → Risposta: falso; guidano ma non sostituiscono la verifica manuale e i controlli automatici.
  • Scenario: regole diverse per frontend/** e backend/** nello stesso repo → Risposta: file *.instructions.md con applyTo, non un unico file monolitico.
  • Scenario: una policy deve valere per tutti i repository dell’azienda → Risposta: organization custom instructions (Copilot Business/Enterprise), non il file di repository.