> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Marketplace dei plugin

> Installa e rendi obbligatori pacchetti di skills per tutti gli utenti della tua org o del tuo account Enterprise dall'app web di Devin

<Note>
  I plugin sono in **beta chiusa**. Per richiedere l'accesso, contatta [support@cognition.ai](mailto:support@cognition.ai). Il comportamento e la configurazione potrebbero cambiare nelle prossime release.
</Note>

<div id="what-are-plugins">
  ## Cosa sono i plugin?
</div>

Un **plugin** è un insieme di [skills](/it/product-guides/skills) — e facoltativamente di regole, hooks e server MCP — riunite in un unico pacchetto, così da poter essere installato e riutilizzato come unità. Mentre una skill si trova in una singola repo, un plugin è una sorgente portabile (una repo GitHub, un git URL, una sottocartella di una repo o un file `.zip` caricato) che puoi richiedere in tutta la tua org o Enterprise.

I **plugin gestiti** consentono a un amministratore di installare i plugin centralmente dalla web app di Devin, in modo che si applichino a **tutti gli utenti dell'org o dell'Enterprise** — senza alcuna configurazione per utente. Questo include le sessioni cloud Devin **e** gli utenti di [Devin CLI](/it/cli/index) che hanno effettuato l'accesso all'account (la configurazione a livello di Enterprise/account si applica anche alla CLI — vedi [sessioni cloud vs. CLI](#cloud-sessions-vs-the-cli)). Quando un plugin viene installato, le sue skill diventano automaticamente disponibili in Devin come comandi `/<plugin>:<skill>`.

Questa pagina descrive il lato cloud (web app) dei plugin. Per il formato dei file dei plugin e il flusso di installazione per utente della CLI, consulta il [Riferimento ai plugin CLI](/it/cli/extensibility/plugins/overview).

<div id="where-to-configure-them">
  ## Dove configurarli
</div>

Vai a [**Settings → Marketplace**](https://app.devin.ai/settings/marketplace). La pagina ha due schede:

* **Marketplace** — esplora i plugin (il catalogo ufficiale di Devin più quelli aggiunti dalla tua org o dal tuo enterprise) e installali. L'installazione di un plugin **lo aggiunge al manifest dell'ambito selezionato come plugin obbligatorio**, quindi viene installato per tutti in quell'ambito.
* [**Configurazione**](https://app.devin.ai/settings/marketplace?tab=configuration) — modifica il **manifest** del plugin direttamente come JSON e carica il tuo plugin come cartella o file `.zip` (oppure creane uno nell'editor).

L'accesso è regolato dalle autorizzazioni:

* Gli **Org admins** (con accesso alle Settings dell'organizzazione) gestiscono il manifest della **org**.
* Gli **Enterprise admins** (con accesso alle impostazioni enterprise) gestiscono anche il manifest **enterprise** condiviso.

<div id="the-manifest">
  ## Il manifest
</div>

Il manifest è un unico documento JSON composto da tre elenchi:

```jsonc theme={null}
{
  "requiredPlugins": [
    // GitHub owner/repo
    "acme/review-tools",

    // qualsiasi git URL
    "https://gitlab.com/acme/secure-base.git",

    // forma oggetto
    { "source": "github", "repo": "acme/audit-logging" },

    // un plugin in una sottocartella
    {
      "source": "git-subdir",
      "url": "https://github.com/acme/vendor-plugins.git",
      "path": "plugins/stripe"
    }
  ],

  "optionalPlugins": [],

  "forbiddenPlugins": [
    "sketchy-org/bad-plugin",
    "acme/*"
  ]
}
```

* **`requiredPlugins`** — installati per tutti nel relativo ambito (in modo ricorsivo, inclusi eventuali plugin da cui dipendono).
* **`optionalPlugins`** — una allow-list che approva i plugin senza installarli automaticamente; usata per definire eccezioni a un elemento vietato.
* **`forbiddenPlugins`** — una deny-list di identificatori di plugin o pattern glob (ad es. `acme/*`, oppure `"*"` per un blocco completo).

Ogni voce in `requiredPlugins` / `optionalPlugins` è una **sorgente** — una stringa in forma abbreviata oppure un oggetto:

| Forma                                                              | Significato                                                       |
| ------------------------------------------------------------------ | ----------------------------------------------------------------- |
| `"owner/repo"`                                                     | repository GitHub                                                 |
| `"https://…"`, `"git@…"`, `"ssh://…"`                              | qualsiasi URL git                                                 |
| `{ "source": "github", "repo": "owner/repo" }`                     | GitHub, formato oggetto                                           |
| `{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }` | URL git, formato oggetto                                          |
| `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`        | un plugin che si trova in una sottocartella di una repo condivisa |

Tutte le forme GitHub per la stessa repo (`owner/repo`, l'URL HTTPS, l'URL `.git`, il formato SSH) si riferiscono alla stessa identità del plugin.

Il manifest viene memorizzato testualmente; l'agente verifica la sorgente completa al momento dell'installazione.

<div id="governance-rules">
  ### Regole di governance
</div>

Le voci di `forbiddenPlugins` vengono confrontate con le identità dei plugin:

* Un'**identità esatta**, scritta come `owner/repo` o come URL Git. Tutte le forme GitHub della stessa repo (`owner/repo`, l'URL HTTPS, l'URL `.git`, la forma SSH) si riferiscono alla stessa identità.
* Un **pattern glob** — qualsiasi voce che contenga `*`. `*` corrisponde a qualsiasi sequenza di caratteri, incluso `/`: `acme/*` corrisponde a tutte le repo GitHub di `acme`, `*/secrets` corrisponde a una repo chiamata `secrets` con qualsiasi owner e `https://gitlab.com/acme/*` corrisponde a qualsiasi repo in quel percorso.
* Il solo `"*"`, che corrisponde a tutto il resto (un blocco totale).

Le liste si combinano secondo il principio deny-wins:

* **Prevale `deny`.** Un plugin è bloccato se un qualsiasi manifest attivo o plugin installato lo vieta. Se nulla vieta nulla, non viene bloccato nulla.
* **Auto-override.** I `requiredPlugins` e `optionalPlugins` di un manifest (o di un plugin) — e, nel caso di un plugin, il plugin stesso — sono esenti dalla **propria** lista di elementi vietati, quindi `"forbiddenPlugins": ["*"]` più `"optionalPlugins": ["acme/approved"]` significa "consenti solo ciò che questo manifest elenca; vieta tutto il resto". L'eccezione copre solo quelle voci dirette, non le dipendenze transitive di un plugin richiesto: in caso di blocco totale, elencale esplicitamente.
* **Nessuna nuova autorizzazione tra ambiti diversi.** La allow-list di un manifest o plugin non può riabilitare ciò che **un altro** vieta. Un blocco totale con `"forbiddenPlugins": ["*"]` non può essere aggirato da un ambito inferiore.

L'applicazione avviene in due momenti:

* **Al momento dell'installazione** — l'installazione di un plugin bloccato (o di uno i cui plugin richiesti non possono essere soddisfatti, o il cui nome entra in conflitto con un plugin installato) viene rifiutata.
* **Al momento del caricamento** — un plugin bloccato dopo essere già stato installato resta sul disco, ma le sue skills vengono saltate all'avvio della sessione con un avviso che indica chi lo vieta.

Oltre a queste regole, i manifest gestiti sono **organizzati per livelli** — **enterprise/account** sopra **org**, che a sua volta è sopra la configurazione dei plugin a livello di repo e di utente. Prevale il livello di autorità più alto: un livello inferiore non può mai vietare un plugin richiesto da un livello superiore, né può mai riabilitarne uno vietato da un livello superiore. Quindi un divieto a livello di org non può bloccare un plugin richiesto a livello enterprise, ma un divieto a livello enterprise prevale su un requisito a livello di org.

<div id="adding-your-own-plugins">
  ## Aggiungere i propri plugin
</div>

Un plugin non è altro che una directory contenente un manifest `.devin-plugin/plugin.json` e una cartella `skills/` con normali [skills](/it/product-guides/skills):

```
my-plugin/
├── .devin-plugin/
│   └── plugin.json     # nome, versione e liste di dipendenze opzionali
├── AGENTS.md           # regola always-on opzionale
├── rules/              # regole con trigger opzionali
├── hooks.json          # hook del ciclo di vita opzionali
├── mcp_config.json     # server MCP opzionali
└── skills/
    └── review/
        └── SKILL.md    # una skill ordinaria
```

Oltre alle skill, un plugin può includere:

* **Regole** — un file `AGENTS.md` nella radice del plugin viene iniettato come regola always-on in ogni sessione — sia nelle sessioni cloud sia nella CLI. Anche i file Markdown in una cartella `rules/` vengono caricati, nel rispetto del loro frontmatter `trigger` — consulta il [Riferimento ai plugin CLI](/it/cli/extensibility/plugins/overview).
* **Hook** — un file `hooks.json` nella radice del plugin registra [Hook del ciclo di vita](/it/cli/extensibility/hooks/lifecycle-hooks) che vengono eseguiti nella sessione. Le sessioni cloud eseguono gli hook `command` per tutti gli eventi tranne `SessionStart` e `SessionEnd` — quindi `PreToolUse`, `PostToolUse`, `PermissionRequest`, `UserPromptSubmit`, `Stop` e `PostCompaction` funzionano tutti; gli hook di tipo `prompt` sono disponibili solo nella CLI/in locale.
* **server MCP** — un file `mcp_config.json` nella radice del plugin dichiara server [MCP](/it/work-with-devin/mcp) (`"mcpServers": { "<name>": { … } }`) che vengono caricati in ogni sessione in cui il plugin è installato. Non compaiono ancora nell'interfaccia Settings di MCP, ma i loro strumenti sono disponibili per Devin. La configurazione MCP di un plugin può impostare un Client ID OAuth e gli ambiti, ma mai un client secret OAuth — una configurazione del server che ne contiene uno viene rifiutata all'attivazione.
* **subagente personalizzato** — profili `agents/<name>.md` (o `agents/<name>/AGENT.md`). Attualmente vengono caricati solo negli agenti Devin locali — il [Devin CLI](/it/cli/extensibility/plugins/overview) e Devin Desktop — non nelle sessioni cloud.

Il **plugin è l'unità di installazione**: installandolo vengono installate tutte le sue skill (più tutto ciò che è incluso in `requiredPlugins`) — non puoi installare singole skill da un plugin. Per offrire le skill separatamente, suddividile in plugin distinti. Consulta il [Riferimento ai plugin CLI](/it/cli/extensibility/plugins/overview) per il formato completo di `plugin.json` e il flusso di creazione locale.

A seconda di dove si trova il plugin, aggiungilo in uno di questi modi:

| Dove si trova                                               | Come aggiungerlo                                                                                                                                  |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Repo git pubblico**                                       | Aggiungi `"owner/repo"` (o il git URL) al manifest, oppure installalo dalla scheda Marketplace se è nel catalogo                                  |
| **Repo git privato**                                        | Stessa voce nel manifest — consulta [usare un repo privato per le skills](#using-a-private-skills-repo) per capire come funziona l'autenticazione |
| **Sottocartella di un repo** (ad es. un monorepo di plugin) | `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }` — ogni sottocartella è un plugin a sé                                                 |
| **Non è in un repo**                                        | Caricalo come bundle (sotto)                                                                                                                      |

Un repo (o una sottocartella `git-subdir`) corrisponde a un plugin. Un singolo repo può ospitare molti plugin come sottocartelle, ciascuno referenziato con una propria voce `git-subdir`.

<div id="uploading-a-plugin-bundle">
  ### Caricamento di un bundle di plugin
</div>

Nella scheda [**Configurazione**](https://app.devin.ai/settings/marketplace?tab=configuration), la sezione **Plugin caricato** consente di caricare un plugin come cartella o file `.zip`, oppure di crearne uno direttamente nell'Editor. Quando lo salvi, viene aggiunto al manifest come plugin obbligatorio (installandolo per tutti nell'ambito); quando lo elimini, il riferimento viene rimosso. Questa è una buona opzione per un plugin che non vuoi (o non puoi) ospitare in una repo Git.

<div id="using-a-private-skills-repo">
  ### Utilizzare un repo privato per le skills
</div>

Punta il manifest direttamente al repo privato: in genere non è necessario includerlo nel tuo [snapshot dell'ambiente](/it/onboard-devin/environment/blueprints). Qualsiasi repo privato che Devin può già raggiungere tramite la tua integrazione Git viene installato automaticamente. Usa il formato git URL oppure `git-subdir` per installare un plugin da una sottocartella di un repo condiviso. (Gli utenti CLI che usano lo stesso manifest lo recuperano con le proprie credenziali Git locali, quindi avranno bisogno anche dell'accesso al repo.)

Se il repo non è raggiungibile tramite la tua integrazione Git, **caricalo come bundle** (sopra) oppure clonalo durante la configurazione dell'ambiente e fai riferimento a un percorso locale.

<div id="how-updates-roll-out">
  ## Come vengono distribuiti gli aggiornamenti
</div>

* Le **modifiche al manifest** (Settings → Marketplace) si applicano alla **sessione successiva**.
* Le **modifiche al plugin** — quando viene eseguito un merge nel branch seguito da un plugin, questo raggiunge automaticamente le nuove sessioni nel giro di poche ore. Blocca il plugin su un commit SHA per gestire tu stesso gli aggiornamenti; nella CLI, `devin plugins update` aggiorna immediatamente.
* Le sessioni già in esecuzione mantengono ciò che hanno caricato all'avvio: gli aggiornamenti non modificano mai una sessione mentre è in corso.

<div id="compatibility">
  ## Compatibilità
</div>

Anche i plugin di Claude funzionano: se non è presente `.devin-plugin/plugin.json`, Devin ripiega su `.claude-plugin/plugin.json`. Quando sono presenti entrambi i manifest, prevale quello di Devin.

<div id="scope-and-inheritance">
  ## Ambito ed ereditarietà
</div>

I manifest gestiti possono esistere su un massimo di due livelli:

* Gli **account** **standalone** hanno un unico manifest di **account** che si applica a tutti.
* Gli **account Enterprise** hanno un manifest **enterprise** condiviso che viene **ereditato da ogni org figlia**, più un manifest per-**org** posto a un livello inferiore. La vista Marketplace mostra entrambi, e gli amministratori enterprise possono scegliere di installare un plugin nell'ambito enterprise (si applica ovunque), oppure un amministratore di org può installarlo solo nella propria org.

Questi si trovano al vertice della gerarchia complessiva dei plugin, sopra qualsiasi configurazione dei plugin a livello di repo o di utente:

1. Manifest **Enterprise / account** (questa pagina)
2. Manifest **Org** (questa pagina)
3. Configurazione del plugin a livello di **repo** (il `.devin/config.json` di una repo)
4. Plugin a livello di **utente** — le installazioni [CLI](/it/cli/extensibility/plugins/overview) personali di un utente, che si applicano solo al suo agente Devin locale e non vengono mai caricati nelle sessioni cloud

Prevale il livello di autorità superiore: un livello inferiore non può mai consentire un plugin che un livello superiore vieta, né vietarne uno che un livello superiore richiede (vedi [regole di governance](#governance-rules)).

<div id="cloud-sessions-vs-the-cli">
  ### Sessioni cloud vs. CLI
</div>

Sia le sessioni cloud di Devin sia il [Devin CLI](/it/cli/index) applicano il manifest **enterprise/account**: i plugin richiesti vengono installati e i divieti vengono applicati anche agli utenti di Devin CLI che hanno effettuato l'accesso all'account.

Il manifest **org** si applica solo alle **sessioni cloud**. Devin CLI si autentica a livello di account e non ha un contesto org, quindi i requisiti e i divieti a livello di org non si applicano agli utenti di Devin CLI. Inserisci nel manifest enterprise/account tutto ciò che deve essere applicato in Devin CLI (o a livello di account) e usa il manifest org per le aggiunte specifiche dell'org nelle sessioni cloud.

<div id="learn-more">
  ## Scopri di più
</div>

* [Skills](/it/product-guides/skills) — le procedure `SKILL.md` incluse nei plugin
* [Riferimento ai plugin CLI](/it/cli/extensibility/plugins/overview) — formato dei file dei plugin, creazione e installazione per utente
* [Playbooks](/it/product-guides/creating-playbooks) — modelli di prompt riutilizzabili allegati alle sessioni