Plugins

Les plugins sont en bêta fermée. Pour demander l’accès, contactez support@cognition.ai. Leur comportement et leur configuration peuvent changer dans de futures versions.

Un plugin est un ensemble de skills que vous pouvez installer depuis un dépôt GitHub, une URL git ou un dossier local, puis réutiliser d’un projet à l’autre. L’installation d’un plugin rend ses skills disponibles sous forme de commandes slash /<plugin>:<skill>, et il peut importer automatiquement d’autres plugins dont il dépend. Un plugin est simplement une source qui contient :

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # Le manifeste du plugin
├── AGENTS.md           # Règle always-on optionnelle
├── rules/              # Règles déclenchées optionnelles
├── agents/
│   └── reviewer.md     # Sous-agent personnalisé optionnel (reviewer/AGENT.md fonctionne également)
├── hooks.json          # Hooks de cycle de vie optionnels
├── mcp_config.json     # Serveurs MCP optionnels
└── skills/
    └── review/
        └── SKILL.md    # Une skill ordinaire

Le répertoire skills/ contient des skills ordinaires — les plugins n’introduisent aucun nouveau format de skill. Voir Créer des skills pour le format SKILL.md. Au-delà des skills, un plugin peut également inclure :

Règles — un fichier AGENTS.md à la racine du plugin est injecté en tant que règle toujours active dans chaque session, aux côtés des règles de votre projet. Les fichiers Markdown du dossier rules/ sont également chargés, avec le même frontmatter trigger et les mêmes types d’activation que les règles Windsurf.
Sous-agents personnalisés — des profils agents/<name>.md ou agents/<name>/AGENT.md (le même format de sous-agent personnalisé que les sous-agents de projet), disponibles sous la forme <plugin>:<name>. Les sous-agents de plugin se chargent actuellement uniquement dans les agents Devin locaux — le CLI et Devin Desktop — et non dans les cloud Devin sessions.
Hooks — un fichier hooks.json à la racine du plugin enregistre des hooks de cycle de vie qui s’exécutent dans chaque session où le plugin est installé.
Serveurs MCP — un fichier mcp_config.json à la racine du plugin déclare des serveurs MCP ("mcpServers": { "<name>": { … } }) qui démarrent avec la session. Le fichier racine .mcp.json des plugins Claude et le champ mcpServers du manifeste sont également pris en charge.

Installation d’un plugin

La source d’un plugin peut être un owner/repo GitHub, une URL git ou un chemin local :

# Depuis GitHub
devin plugins install acme/review-tools

# Depuis n'importe quel hôte git
devin plugins install https://gitlab.com/acme/review-tools.git

# Depuis un dossier local (idéal pour la création)
devin plugins install ./my-plugin

Avant l’installation, Devin affiche ce que le plugin ajoute — les skills qu’il fournit, les plugins requis qui seront installés automatiquement, ainsi que toute politique qu’il introduit (par exemple, s’il interdit d’autres plugins). Passez -y / --yes pour ignorer le prompt. Les plugins sont installés au niveau de l’utilisateur et sont disponibles dans tous vos projets.

Gérer les plugins

# Lister les plugins installés, leurs versions, et indiquer si certains sont bloqués par une politique
devin plugins list

# Afficher les skills d'un plugin et ses listes required/optional/forbidden
devin plugins info review-tools

# Récupérer à nouveau un plugin (ou tous les plugins) à la dernière version
devin plugins update review-tools
devin plugins update

# Supprimer un plugin (les plugins required installés automatiquement sont conservés)
devin plugins remove review-tools

Les plugins locaux sont liés directement à leur dossier source, donc les modifications sont prises en compte immédiatement : devin plugins install ./my-plugin → modifiez skills/<name>/SKILL.md → les modifications s’appliquent dès la session suivante, sans update.

Le manifeste

.devin-plugin/plugin.json décrit le plugin. Seul name est obligatoire, et il doit être unique parmi les plugins installés (il s’agit de l’espace de noms /<name>:…).

{
  "name": "review-tools",
  "version": "1.0.0",
  "description": "Code-review skills for our team",
  "requiredPlugins": [
    "acme/secure-base",
    { "source": "github", "repo": "acme/audit-logging" }
  ],
  "optionalPlugins": [
    "acme/deploy-tools",
    { "source": "url", "url": "https://gitlab.com/acme/extra.git" }
  ],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"]
}

Champs de métadonnées pris en charge : name, version, description, author ({ name, email }), homepage, repository, license et keywords. Deux autres champs facultatifs déterminent d’où les ressources sont chargées : skills — un chemin ou un tableau de chemins vers des répertoires de skills, qui remplace skills/ par défaut — et mcpServers — des chemins de fichiers de déclaration MCP ou une table de serveurs inline, lus en plus des conventions à la racine. Une entrée de dépendance est une source — soit une forme abrégée sous forme de chaîne, soit un objet :

Forme	Signification
`"owner/repo"`	dépôt GitHub
`"https://…"`, `"git@…"`, `"ssh://…"`	n’importe quelle URL git
`{ "source": "github", "repo": "owner/repo" }`	GitHub, format objet
`{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }`	URL git, format objet
`{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`	un plugin situé dans un sous-dossier d’un repo partagé

Toutes les formes GitHub pour un même repo (owner/repo, l’URL HTTPS, l’URL .git, la forme SSH) correspondent à la même identité de plugin.

Dépendances et gouvernance

Un plugin peut déclarer trois listes, ce qui permet à un seul plugin de servir de collection organisée et encadrée d’autres plugins.

`requiredPlugins`

Installés automatiquement (de façon récursive) lors de l’installation du plugin. Si un plugin requis est bloqué par une politique, l’installation échoue dans son ensemble — il n’existe pas d’installation partielle.

`optionalPlugins`

Une liste des plugins autorisés par ce plugin. Ils ne sont pas installés automatiquement ; cette liste ne sert qu’à définir une exception pour une entrée interdite (voir ci-dessous).

`forbiddenPlugins`

Une liste de refus d’identités de plugin et de motifs glob. Les entrées forbiddenPlugins sont mises en correspondance avec les identités de plugin :

Une identité exacte, écrite sous la forme owner/repo ou d’une URL Git. Toutes les formes GitHub d’un même repo (owner/repo, l’URL HTTPS, l’URL .git, la forme SSH) renvoient à la même identité.
Un motif glob — toute entrée contenant *. Le * correspond à n’importe quelle séquence de caractères, y compris / : acme/* correspond à tous les repos GitHub de acme, */secrets correspond à un repo nommé secrets chez n’importe quel propriétaire, et https://gitlab.com/acme/* correspond à n’importe quel repo sous ce chemin.
Le simple "*", qui correspond à tout le reste (verrouillage complet).

Les listes se combinent selon une logique où l’interdiction l’emporte :

L’interdiction l’emporte. Un plugin est bloqué si un manifest actif ou un plugin installé l’interdit. Si rien n’interdit quoi que ce soit, rien n’est bloqué.
Dérogation pour soi-même. Les requiredPlugins et optionalPlugins d’un manifest (ou d’un plugin) — et, pour un plugin, le plugin lui-même — sont exemptés de leur propre liste d’interdictions. Ainsi, "forbiddenPlugins": ["*"] plus "optionalPlugins": ["acme/approved"] signifie « n’autoriser que ce que ce manifest liste ; interdire tout le reste. » Cette exception ne couvre que ces entrées directes, pas les dépendances transitives d’un plugin requis — listez-les explicitement dans le cadre d’un verrouillage.
Aucune réautorisation inter-périmètres. La liste des autorisations d’un manifest ou d’un plugin ne peut pas réautoriser ce qu’un autre interdit. Un verrouillage "forbiddenPlugins": ["*"] ne peut pas être contourné depuis un périmètre inférieur.

L’application des règles se fait à deux moments :

À l’installation — l’installation d’un plugin bloqué (ou d’un plugin dont les plugins requis ne peuvent pas être satisfaits, ou dont le nom entre en conflit avec un plugin installé) est refusée.
Au chargement — un plugin bloqué après avoir déjà été installé reste sur le disque, mais ses skills sont ignorées au démarrage de la session, avec un avertissement indiquant l’élément qui l’interdit.

Une identité interdite peut aussi prendre la forme d’un chemin local (pour les plugins installés à partir d’un dossier local), en plus des formes owner/repo et URL git ci-dessus.

Héritage et niveaux

Les plugins ne sont pas déclarés à un seul endroit. En plus de ceux que vous installez vous-même, des plugins peuvent être requis, approuvés ou interdits par votre repo et par l’admin de votre organisation. Chaque source constitue un niveau, et les niveaux sont classés par autorité, de la plus élevée à la plus faible :

Enterprise — le manifeste géré à l’échelle du compte, configuré par un admin.
Org — un manifeste géré au niveau de l’org, situé sous le compte dans la hiérarchie (une org peut compléter ce que son compte déclare, mais ne peut pas y déroger). Cela s’applique uniquement aux cloud Devin sessions : la CLI s’authentifie au niveau du compte et n’a aucun contexte d’org. Les plugins requis ou interdits au niveau de l’org ne s’appliquent donc pas aux utilisateurs de la CLI. Placez dans le manifeste Enterprise/compte tout ce qui doit être appliqué dans la CLI.
Repo — les requiredPlugins / optionalPlugins / forbiddenPlugins dans le .devin/config.json d’un checkout, détectés en remontant depuis votre répertoire de travail.
User — les plugins que vous installez vous-même avec devin plugins install.

Chaque niveau déclare les mêmes trois listes et, au sein d’un même niveau, elles se combinent selon les mêmes règles de priorité au refus et d’auto-dérogation qu’un manifeste unique. La seule règle supplémentaire apportée par les niveaux est la suivante : l’autorité supérieure l’emporte.

L’autorité supérieure prime

Un niveau inférieur ne peut jamais réautoriser ce qu’un niveau supérieur interdit.
Un niveau inférieur ne peut jamais interdire ce qu’un niveau supérieur exige — l’interdiction est ignorée et le plugin est quand même chargé.

Ainsi, un administrateur peut imposer un plugin auquel aucun repo ni utilisateur ne peut se soustraire, et interdire un plugin qu’aucun niveau inférieur ne peut réactiver.

Une liste de refus ne peut être outrepassée qu’à son propre niveau

Comme les listes d’autorisation ne s’appliquent pas d’un niveau à l’autre, la seule façon de ménager une exception à une liste de refus est de le faire au même niveau que celui qui l’a déclarée. Le forbiddenPlugins d’un niveau ne peut être outrepassé que par le optionalPlugins de ce même manifeste (ou requiredPlugins) — jamais par une liste située à un niveau inférieur. Par exemple, un manifeste géré au niveau de l’entreprise peut restreindre le compte à un seul plugin approuvé :

// Manifeste géré au niveau entreprise
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

Cela signifie “sur l’ensemble du compte, n’autoriser que acme/approved et interdire tout autre plugin.” Aucune organisation, aucun dépôt ni aucun utilisateur ne peut élargir cette liste d’autorisation — ni en installant un plugin, ni en l’ajoutant aux optionalPlugins d’un niveau inférieur. L’exception ne couvre également que les entrées que ce manifeste liste directement ; les dépendances transitives d’un plugin requis ne sont pas exemptées, alors indiquez-les explicitement dans une configuration verrouillée.

Conflits et dépendances

Pour un même plugin, un require et un forbid au même niveau mais issus de manifestes différents (par exemple, deux plugins distincts installés au niveau utilisateur) donnent priorité à forbid — une liste d’autorisation n’exempte que les entrées de son propre manifeste, elle ne peut donc pas lever l’interdiction d’un plugin interdit par un autre manifeste. (Au sein d’un même manifeste, ses propres éléments requis/facultatifs restent exemptés de ses propres interdictions, comme ci-dessus.)
Un plugin bloqué par la gouvernance échoue de manière non bloquante : au démarrage de la session, ses skills sont ignorées avec un avertissement indiquant l’origine de l’interdiction, au lieu d’interrompre la session.
Le fait d’être une dépendance n’accorde aucune exemption. Un plugin inclus uniquement comme dépendance transitive reste soumis à toute interdiction qui s’applique à lui, et il hérite du niveau d’autorité le plus élevé de tout plugin qui l’exige.

Prise en main

Intégrations d’éditeur

Extensibilité

Entreprise

Référence

Changelog

Installation d’un plugin

Gérer les plugins

Le manifeste

Dépendances et gouvernance

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Héritage et niveaux

L’autorité supérieure prime

Une liste de refus ne peut être outrepassée qu’à son propre niveau

Conflits et dépendances

​Installation d’un plugin

​Gérer les plugins

​Le manifeste

​Dépendances et gouvernance

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​Héritage et niveaux

​L’autorité supérieure prime

​Une liste de refus ne peut être outrepassée qu’à son propre niveau

​Conflits et dépendances

Installation d’un plugin

Gérer les plugins

Le manifeste

Dépendances et gouvernance

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Héritage et niveaux

L’autorité supérieure prime

Une liste de refus ne peut être outrepassée qu’à son propre niveau

Conflits et dépendances