Mettre en place votre écosystème de plugins

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

Ce guide vous explique comment mettre en place votre propre écosystème de plugins : un repo de plugins géré par votre organisation, distribué à chaque session Devin et à chaque utilisateur CLI via un manifeste géré, avec des plugins requis, facultatifs et interdits comme mécanismes de gouvernance. Deux repos modèles accompagnent ce guide :

plugin-template — une base de départ pour créer un plugin unique (ou un ou deux).
team-marketplace-template — le modèle complet d’écosystème : un monorepo de plugins, ainsi qu’un méta-plugin dont le manifeste définit votre configuration de base et votre politique.

1. Créez vos plugins

Un plugin est un répertoire contenant un manifeste .devin-plugin/plugin.json ; tout le reste est facultatif :

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, dependency + policy lists
├── AGENTS.md           # always-on rule
├── rules/              # triggered rules
├── agents/<name>.md   # sous-agents personnalisés (CLI/Desktop uniquement pour l'instant) ; agents/<name>/AGENT.md fonctionne aussi
├── hooks.json          # lifecycle hooks
├── mcp_config.json     # MCP servers
└── skills/<name>/SKILL.md   # skills, exposed as /<plugin>:<skill>

Commencez par faire un fork de plugin-template, puis consultez la référence des plugins CLI pour le format complet. Gardez AGENTS.md court — il consomme du contexte à chaque session pour tous les utilisateurs du plugin.

2. Valider et tester en local

Les deux modèles sont fournis avec un validateur (node scripts/validate-template.mjs) et un workflow CI qui l’exécute à chaque PR. Pour un test en conditions réelles, installez-les depuis un dossier local avec le Devin CLI :

devin plugins install ./plugins/my-plugin   # lié : les modifications s'appliquent à la prochaine session
devin plugins list

3. Hébergez-les dans un seul repo

Placez tous les plugins de votre org dans un seul repo, dans des sous-dossiers (plugins/<name>/), chacun référencé avec sa propre source git-subdir. Le repo peut rester privé : les sessions cloud le récupèrent via votre intégration Git, et les utilisateurs du CLI le récupèrent avec leurs propres identifiants Git (ils doivent donc eux aussi avoir accès au repo). Faites un fork de team-marketplace-template pour utiliser cette structure — puis mettez à jour les URL git-subdir de son méta-plugin pour qu’elles pointent vers votre fork. Dans le template, le méta-plugin se trouve à la racine du repo ; le repo lui-même est donc l’unité installable : déclarer your-org/your-marketplace installe toute la configuration de base.

4. Définissez votre configuration de base avec un méta-plugin

L’approche du méta-plugin transforme tout votre écosystème en une seule unité installable. Il s’agit d’un plugin avec peu, voire pas, de contenu propre — c’est son manifeste qui fait le travail. Placez-le à la racine du repo afin que le repo lui-même soit le méta-plugin :

// .devin-plugin/plugin.json (racine du dépôt)
{
  "name": "team-starter-pack",
  "requiredPlugins": [
    // installé automatiquement pour tous, de façon récursive
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    // approuvé, non installé automatiquement ; constitue également une exception aux interdictions de ce manifeste
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ],
  "forbiddenPlugins": [
    "untrusted-vendor/*"
  ]
}

5. Distribuer depuis Settings → Marketplace

Un administrateur ajoute une entrée au manifeste géré sur la page Marketplace de Settings — voir le guide de la marketplace des plugins:

{
  "requiredPlugins": ["acme/plugins"]
}

Rendre obligatoire le repo de la marketplace installe son méta-plugin racine, qui inclut récursivement toute la configuration de base. Toutes les personnes dans le périmètre reçoivent désormais automatiquement la configuration de base. Choisissez le périmètre avec soin :

Le manifeste enterprise/account s’applique aux sessions cloud et aux utilisateurs du CLI connectés au compte.
Le manifeste org s’applique uniquement aux sessions cloud — le CLI n’a pas de contexte d’organisation.

6. Gouvernance

Les trois listes forment le langage de politique à chaque niveau (manifestes gérés, config du repo, manifestes du plugin). Le niveau d’autorité supérieur l’emporte — Enterprise/compte sur org, sur repo, sur utilisateur — et un niveau inférieur ne peut jamais réautoriser ce qu’un niveau supérieur interdit, ni interdire ce qu’il exige. Pour verrouiller un compte afin de n’autoriser qu’un ensemble approuvé :

{
  "forbiddenPlugins": ["*"],
  "requiredPlugins": [
    "acme/plugins",
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ]
}

Les entrées required/optional du manifeste lui-même sont exemptées de leur propre interdiction "*" ; rien d’autre ne l’est, et aucun niveau inférieur ne peut élargir cette exception. L’exemption ne couvre que les entrées directement listées — les dépendances transitives d’un plugin requis ne sont pas exemptées — donc, en cas de verrouillage, listez explicitement tout ce que le méta-plugin embarque (ici engineering-baseline et security-guardrails). Consultez les règles de gouvernance pour la sémantique complète.

7. Faire évoluer

La fusion dans la branche par défaut du repo de votre plugin constitue la publication : les nouvelles sessions la prennent en compte automatiquement — voir comment les mises à jour sont déployées.
Teams ajoutent des plugins par PR au repo de la marketplace ; la CI du template valide la structure à chaque PR.
Les plugins Claude existants s’installent tels quels (Devin utilise .claude-plugin/plugin.json à défaut), vous pouvez donc recommander des plugins de la communauté dans optionalPlugins sans les intégrer au dépôt.

Limitations actuelles

Les plugins se chargent dans les sessions cloud, le Devin CLI et Devin Desktop (lors de l’utilisation de Devin Local) ; ils ne s’appliquent pas à l’agent Cascade classique.
Les Subagents (agents/<name>.md or agents/<name>/AGENT.md) se chargent uniquement dans les agents Devin locaux (CLI et Devin Desktop), et non dans les sessions cloud.
Hooks : les sessions cloud exécutent les hooks command pour chaque événement, à l’exception de SessionStart et SessionEnd ; les hooks de type prompt sont réservés au CLI et au local.
Le MCP fourni par un plugin se charge dans la session, mais n’apparaît pas encore dans l’interface Settings du MCP.
Les manifestes au niveau de l’organisation ne s’appliquent pas aux utilisateurs du CLI ; utilisez le manifeste Enterprise/de compte pour l’application dans le CLI.

En savoir plus

Marketplace des plugins — côté application web : manifestes, périmètres, mises en ligne
Référence des plugins CLI — format de fichier, création, installations par utilisateur
Skills — les procédures SKILL.md fournies avec les plugins

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Mettre en place votre écosystème de plugins

1. Créez vos plugins

2. Valider et tester en local

3. Hébergez-les dans un seul repo

4. Définissez votre configuration de base avec un méta-plugin

5. Distribuer depuis Settings → Marketplace

6. Gouvernance

7. Faire évoluer

Limitations actuelles

En savoir plus

​1. Créez vos plugins

​2. Valider et tester en local

​3. Hébergez-les dans un seul repo

​4. Définissez votre configuration de base avec un méta-plugin

​5. Distribuer depuis Settings → Marketplace

​6. Gouvernance

​7. Faire évoluer

​Limitations actuelles

​En savoir plus

1. Créez vos plugins

2. Valider et tester en local

3. Hébergez-les dans un seul repo

4. Définissez votre configuration de base avec un méta-plugin

5. Distribuer depuis Settings → Marketplace

6. Gouvernance

7. Faire évoluer

Limitations actuelles

En savoir plus