Skip to main content
Les plugins sont en bêta. 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
└── skills/
    └── review/
        └── SKILL.md    # Un 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.

​
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. Une entrée de dépendance est une source — soit une forme abrégée sous forme de chaîne, soit un objet :
  • "owner/repo" → GitHub
  • "https://…", "git@…", "ssh://…" → URL git
  • { "source": "github", "repo": "owner/repo" }
  • { "source": "url", "url": "https://gitlab.com/team/plugin.git" }
Toutes les formes GitHub pour le même dépôt (owner/repo, l’URL HTTPS, l’URL .git, la forme SSH) désignent le même 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 d’interdiction. Chaque entrée est l’un des éléments suivants :
  • Une identité de plugin exacte, écrite sous la forme owner/repo, d’une URL git ou d’un chemin local.
  • Un motif glob — toute entrée contenant *. Le * correspond à n’importe quelle séquence de caractères, y compris /. Les motifs sont d’abord normalisés dans l’espace d’identité canonique : acme/* devient donc https://github.com/acme/* (tous les repos GitHub de acme), */secrets correspond à un repo nommé secrets sous n’importe quel propriétaire, et https://gitlab.com/acme/* correspond à n’importe quel repo sous ce chemin.
  • Le seul "*", qui correspond à tous les autres plugins (un verrouillage impossible à contourner).
Les règles de la politique sont :
  • L’interdiction l’emporte. Un plugin est bloqué si un plugin installé l’interdit (via son identité exacte, un glob correspondant ou "*").
  • Auto-dérogation. Les requiredPlugins, optionalPlugins d’un plugin, ainsi que le plugin lui-même, sont exemptés de sa propre liste d’interdiction. Ainsi, forbiddenPlugins: ["*"] avec optionalPlugins: [B, C] signifie « m’autoriser, moi-même, B et C ; interdire tout le reste. »
  • Aucune réautorisation inter-plugin. Les listes d’autorisation d’un plugin ne peuvent pas réautoriser ce qu’un autre plugin interdit. Un plugin installé avec forbiddenPlugins: ["*"] constitue un verrouillage impossible à contourner.
  • Ouvert par défaut. Si aucun plugin installé n’interdit quoi que ce soit, rien n’est bloqué.
La politique est appliquée à deux moments :
  • Au moment de 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 moment du chargement — si un plugin devient bloqué après l’installation (par exemple, si un plugin qui l’interdit est installé plus tard), il reste sur disque mais ses skills sont ignorées au démarrage de la session, avec un avertissement indiquant le nom du plugin qui l’interdit.