Il problema che Agent Plugins 1.0 prova a risolvere

Chi lavora quotidianamente con GitHub Copilot conosce bene la frammentazione degli ultimi due anni: skill scritte per VS Code che non funzionano su Copilot CLI, configurazioni MCP duplicate tra client diversi, agenti custom da ricostruire da zero ogni volta che si cambia strumento. Con Agent Plugins 1.0, annunciato a metà agosto 2026, GitHub prova a chiudere questa frammentazione introducendo uno standard aperto — non un formato proprietario — per pacchettizzare skill e server MCP in un plugin installabile una sola volta e utilizzabile su più superfici: VS Code, Copilot CLI, Copilot SDK, l’app Copilot e il coding agent cloud.

È un cambio di prospettiva interessante anche per chi non usa Copilot come strumento principale: la specifica Agent Plugins non è un’invenzione isolata, ma converge con formati simili già visti in altri ecosistemi (Claude, OpenPlugin), e questo la rende rilevante per chiunque costruisca strumenti per agenti AI, non solo per i team Microsoft/GitHub.

Anatomia di un Agent Plugin

Un plugin conforme allo standard 1.0 è una directory con una struttura riconoscibile. Il file centrale è plugin.json, che dichiara esplicitamente lo schema a cui aderisce:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-dev-tools",
  "description": "Utility per lo sviluppo React",
  "version": "1.2.0"
}

I soli campi obbligatori sono $schema e name; tutto il resto (version, description, author, homepage, repository, license, keywords) è opzionale ma consigliato per la pubblicazione su un marketplace.

Attorno al manifest, la struttura tipica di un plugin più completo è questa:

my-testing-plugin/
  plugin.json              # Metadati del plugin
  skills/
    test-runner/
      SKILL.md              # Istruzioni della skill
      run-tests.sh           # Script di supporto
  agents/
    test-reviewer.agent.md   # Agente custom (client-specific)
  hooks/
    hooks.json                # Configurazione hook (client-specific)
  scripts/
    validate-tests.sh
  .mcp.json                   # Definizione dei server MCP

La distinzione più importante per chi progetta un plugin è tra componenti portabili e componenti client-specific:

• Portabili (parte dello standard 1.0): server MCP (integrazioni con tool esterni) e skill, cioè istruzioni, script e risorse caricate on-demand dall’agente.
• Client-specific (solo VS Code, ad esempio): agenti custom con personalità e configurazione tool dedicata, hook che eseguono comandi shell in punti precisi del ciclo di vita dell’agente, e slash command richiamabili in chat con /.

Questa separazione è la vera innovazione pratica: uno stesso plugin può portare le sue skill e i suoi server MCP ovunque, mentre le personalizzazioni specifiche di un client restano lì dove hanno senso, senza rompere la compatibilità altrove.

Configurare i server MCP dentro un plugin

I server MCP si dichiarano in .mcp.json (o mcp.json), con variabili d’ambiente che il runtime dell’agente risolve automaticamente al momento del caricamento:

{
  "mcpServers": {
    "plugin-database": {
      "command": "${PLUGIN_ROOT}/servers/db-server",
      "args": ["--config", "${PLUGIN_ROOT}/config.json"],
      "env": {
        "DB_PATH": "${PLUGIN_ROOT}/data"
      }
    }
  }
}

La variabile ${PLUGIN_ROOT} punta sempre alla directory del plugin installato, indipendentemente da dove l’utente finale lo abbia scaricato — un dettaglio che elimina un’intera classe di bug legati a percorsi assoluti hardcoded nei plugin distribuiti da terze parti.

Hook: automazioni sul ciclo di vita dell’agente

Per i client che supportano questa estensione (il formato è compatibile con la sintassi già nota da Claude), gli hook permettono di agganciare comandi shell a eventi specifici, ad esempio dopo l’uso di un tool:

{
  "hooks": {
    "PostToolUse": [
      {
        "type": "command",
        "command": "${PLUGIN_ROOT}/scripts/format.sh"
      }
    ]
  }
}

Un caso d’uso concreto: formattare automaticamente il codice generato dall’agente subito dopo ogni modifica a un file, senza dover ricordare di lanciare il linter manualmente.

Migrare un plugin Copilot esistente

Chi ha già plugin Copilot “vecchio formato” non deve riscrivere nulla da zero. GitHub descrive un percorso di migrazione minimo:

1. Aggiungere il campo $schema al plugin.json esistente, puntandolo allo schema Agent Plugins 1.0.
2. Mantenere le skill dove sono già, sotto skills/.
3. Spostare i file specifici di Copilot (agenti, comandi, regole, hook, canvas) dentro una directory dedicata com.github.copilot/, così da separarli chiaramente dalla parte portabile.

I plugin GitHub Copilot esistenti restano comunque supportati senza obbligo di migrazione: è un aggiornamento incrementale, non un breaking change forzato.

Governance aziendale: managed-settings.json

Per i team enterprise, probabilmente l’aspetto più rilevante non è la portabilità in sé ma il controllo centralizzato che ne deriva. Il file managed-settings.json permette di definire una baseline aziendale su cosa è installabile:

{
  "extraKnownMarketplaces": {
    "company-tools": {
      "source": { "source": "github", "repo": "vostra-org/plugin-marketplace" }
    }
  },
  "enabledPlugins": {
    "code-formatter@company-tools": true
  }
}

Tre leve principali:

• enabledPlugins — installa automaticamente o blocca esplicitamente plugin specifici per tutti gli utenti gestiti.
• extraKnownMarketplaces — aggiunge marketplace interni oltre a quelli pubblici di default.
• strictKnownMarketplaces — se attivato, limita l’installazione ai soli marketplace esplicitamente autorizzati, impedendo l’uso di sorgenti non gestite.

Le impostazioni enterprise agiscono come baseline additiva: i team possono comunque aggiungere plugin approvati sopra la configurazione centrale, senza però poter aggirare i blocchi imposti a livello organizzativo. Per chi gestisce flotte di sviluppatori con policy di sicurezza stringenti, è la differenza tra “confidare che ognuno installi solo cose sicure” e avere un controllo verificabile.

Dove si installano i plugin

Il canale di scoperta di default è l’Awesome Copilot marketplace, disponibile fin da subito in VS Code, Copilot CLI e nell’app Copilot. Per plugin locali o in sviluppo, VS Code offre una registrazione esplicita via impostazioni:

"chat.pluginLocations": {
    "/percorso/al/mio-plugin": true,
    "/percorso/a/un-altro-plugin": false
}

Un dettaglio utile in fase di debug: se un plugin non viene rilevato, vale la pena controllare che chat.plugins.enabled sia attivo, che il nome nel manifest sia in kebab-case (obbligatorio per lo standard 1.0), e — per problemi di installazione persistenti — ripulire la cache locale in ~/.config/Code/agentPlugins/ su Linux.

Conclusione

Agent Plugins 1.0 non introduce funzionalità radicalmente nuove rispetto a quello che skill e server MCP già facevano singolarmente: il suo valore è nella standardizzazione del confezionamento e nella governance che ne deriva. Per un team che sviluppa strumenti interni per i propri agenti AI — che siano skill per il debug, integrazioni con sistemi proprietari via MCP, o automazioni sul ciclo di vita dell’agente — poter scrivere il plugin una sola volta e vederlo funzionare su CLI, editor e SDK senza riscritture è un risparmio di manutenzione concreto, non solo un dettaglio architetturale. Vale la pena tenerlo d’occhio anche per chi non usa Copilot: essendo uno standard aperto, è probabile che altri agent tool ne adottino la compatibilità nei prossimi mesi.

Fonte: Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app — GitHub Changelog