Français

Créer des plugins

Créez, testez et distribuez des plugins pour ChatGPT

Cette page s’adresse aux auteurs de plugins. Si vous souhaitez parcourir, installer et utiliser des plugins avec ChatGPT Work sur le web, ou avec ChatGPT Work ou Codex dans l’application de bureau ChatGPT, consultez Plugins. Si vous travaillez encore sur un seul dépôt ou un workflow personnel, commencez par une skill locale. Créez un plugin lorsque vous souhaitez partager ce workflow entre plusieurs équipes, regrouper des connecteurs ou une configuration MCP, intégrer des hooks de cycle de vie ou publier un package stable.

Un plugin peut inclure des skills, une application basée sur MCP, ou les deux. Si votre plugin doit se connecter à un service ou exposer des outils par l’intermédiaire d’un serveur MCP, consultez Créer une application.

Pour consulter des exemples publics complets, examinez Figma, Notion et Build web apps.

Créer un plugin avec @plugin-creator

Pour une configuration rapide, utilisez la skill @plugin-creator intégrée.

Skill de création de plugins dans ChatGPT

Elle génère la structure du manifeste .codex-plugin/plugin.json requis et peut également créer une entrée de marketplace locale à des fins de test. Si vous disposez déjà d’un dossier de plugin, vous pouvez tout de même utiliser @plugin-creator pour l’intégrer à une marketplace locale.

Comment invoquer la skill plugin-creator

Créer et tester localement un plugin qui pointe vers une application en mode développement basée sur un serveur MCP

Vous pouvez également utiliser la skill plugin-creator si vous souhaitez tester localement un plugin qui inclut une application basée sur un serveur MCP. Le plugin nécessite toujours un dossier de plugin local et un manifeste, mais l’application elle-même démarre en mode développeur dans ChatGPT.

Commencez par activer le mode développeur dans ChatGPT :

  1. Ouvrez ChatGPT.
  2. Ouvrez Settings.
  3. Sélectionnez Security and login.
  4. Activez Developer mode.

Créez ensuite l’application en mode développeur :

  1. Ouvrez Settings → Plugins ou la page Plugins.
  2. Sélectionnez le bouton plus.
  3. Remplissez la fenêtre modale pour créer une application en mode développeur pour votre serveur MCP.
  4. Une fois l’application créée par ChatGPT, copiez son ID depuis l’URL du navigateur. Il commence par plugin_asdk_app.

Fournissez cet ID plugin_asdk_app... à @plugin-creator dans une conversation ChatGPT Work ou à $plugin-creator dans Codex. Par exemple, avec ChatGPT Work :

  Prompt pour Plugin Creator
@plugin-creator create a Codex plugin for my ChatGPT app.
Use plugin_asdk_app_6a4c0062f3b88191855c0a80eac5d53d and name it Acme Support.
Include a personal marketplace entry so I can test it locally.

La skill plugin-creator créera le dossier du plugin, créera le fichier .codex-plugin/plugin.json requis et ajoutera la configuration reliant le plugin à l’application ChatGPT. Si vous lui demandez de créer une entrée de marketplace personnelle, le plugin apparaîtra sous votre source locale dans le répertoire Plugins à des fins de test.

Une fois le plugin créé par la skill plugin-creator :

  1. Vérifiez .app.json et confirmez qu’il pointe vers le bon ID plugin_asdk_app....
  2. Vérifiez .codex-plugin/plugin.json et assurez-vous que son champ apps pointe vers ./.app.json.
  3. Ajoutez les éventuelles skills incluses sous skills/ si le plugin doit proposer des workflows reproductibles en complément de l’application.
  4. Si la skill a créé une entrée de marketplace personnelle, actualisez ChatGPT, puis installez le plugin depuis votre source locale dans le répertoire Plugins. Testez-le ensuite dans une nouvelle conversation.

Pour connaître la structure du manifeste et l’organisation des fichiers, consultez Structure d’un plugin et Règles relatives aux chemins.

Créer votre propre liste de plugins organisée

Une marketplace est un catalogue JSON de plugins. @plugin-creator peut en générer un pour un seul plugin, et vous pouvez continuer à ajouter des entrées à cette même marketplace pour constituer votre propre liste organisée pour un dépôt, une équipe ou un workflow personnel.

Dans ChatGPT Work ou Codex au sein de l’application de bureau ChatGPT, chaque marketplace apparaît comme une source sélectionnable dans le répertoire Plugins. Utilisez $REPO_ROOT/.agents/plugins/marketplace.json pour une liste limitée à un dépôt ou ~/.agents/plugins/marketplace.json pour une liste personnelle. Ajoutez une entrée par plugin sous plugins[], faites pointer chaque source.path vers le dossier du plugin au moyen d’un chemin préfixé par ./ et relatif à la racine de la marketplace, puis définissez interface.displayName sur le libellé que vous souhaitez afficher dans le sélecteur de marketplaces de l’application. Redémarrez ensuite l’application de bureau ChatGPT. Après cela, ouvrez le répertoire Plugins, choisissez votre marketplace, puis parcourez ou installez les plugins de cette liste organisée.

Vous n’avez pas besoin d’une marketplace distincte pour chaque plugin. Une marketplace peut présenter un seul plugin pendant vos tests, puis devenir un catalogue organisé plus vaste à mesure que vous ajoutez des plugins.

Marketplace locale personnalisée dans le répertoire Plugins

Ajouter une marketplace depuis la CLI

Utilisez codex plugin marketplace add pour ajouter et suivre une source de marketplace au lieu de modifier config.toml manuellement. Ces commandes facilitent la création de plugins et la configuration des catalogues. Utilisez l’application de bureau ChatGPT pour installer et tester un plugin local.

codex plugin marketplace add owner/repo
codex plugin marketplace add owner/repo --ref main
codex plugin marketplace add https://github.com/example/plugins.git --sparse .agents/plugins
codex plugin marketplace add ./local-marketplace-root

Les sources de marketplace peuvent être des raccourcis GitHub (owner/repo ou owner/repo@ref), des URL Git HTTP ou HTTPS, des URL Git SSH ou des répertoires racines de marketplaces locales. Utilisez --ref pour épingler une référence Git et répétez --sparse PATH pour utiliser un checkout partiel avec les dépôts de marketplace basés sur Git. --sparse est uniquement valide pour les sources de marketplace Git.

Pour examiner, actualiser ou supprimer les marketplaces configurées :

codex plugin marketplace list
codex plugin marketplace upgrade
codex plugin marketplace upgrade marketplace-name
codex plugin marketplace remove marketplace-name

codex plugin marketplace list affiche chaque marketplace prise en compte par Codex ainsi que le chemin racine à partir duquel elle est résolue, y compris les marketplaces locales par défaut et les instantanés de marketplaces configurées.

Créer un plugin manuellement

Commencez par un plugin minimal qui intègre une skill.

  1. Créez un dossier de plugin avec un manifeste à l’emplacement .codex-plugin/plugin.json.
mkdir -p my-first-plugin/.codex-plugin

my-first-plugin/.codex-plugin/plugin.json

{
  "name": "my-first-plugin",
  "version": "1.0.0",
  "description": "Reusable greeting workflow",
  "skills": "./skills/"
}

Utilisez un name de plugin stable au format kebab-case. Codex l’utilise comme identifiant du plugin et espace de noms des composants.

  1. Ajoutez une skill sous skills/<skill-name>/SKILL.md.
mkdir -p my-first-plugin/skills/hello

my-first-plugin/skills/hello/SKILL.md

---
name: hello
description: Greet the user with a friendly message.
---

Greet the user warmly and ask how you can help.
  1. Ajoutez le plugin à une marketplace. Utilisez @plugin-creator pour en générer une, ou suivez la section Créer votre propre liste de plugins organisée pour intégrer manuellement le plugin à Codex.

Vous pouvez ensuite ajouter une configuration MCP, des connecteurs ou des métadonnées de marketplace selon vos besoins.

Installer manuellement un plugin local

Utilisez une marketplace de dépôt ou une marketplace personnelle, selon les personnes qui doivent pouvoir accéder au plugin ou à la liste organisée.

Dépôt

Ajoutez un fichier de marketplace à l’emplacement `$REPO_ROOT/.agents/plugins/marketplace.json`
et stockez vos plugins sous `$REPO_ROOT/plugins/`.

**Exemple de marketplace de dépôt**

Étape 1 : copiez le dossier du plugin dans `$REPO_ROOT/plugins/my-plugin`.
mkdir -p ./plugins
cp -R /absolute/path/to/my-plugin ./plugins/my-plugin
Étape 2 : ajoutez ou mettez à jour `$REPO_ROOT/.agents/plugins/marketplace.json` afin
que `source.path` pointe vers ce répertoire de plugin à l’aide d’un chemin relatif préfixé
par `./` :
{
  "name": "local-repo",
  "plugins": [
    {
      "name": "my-plugin",
      "source": {
        "source": "local",
        "path": "./plugins/my-plugin"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    }
  ]
}
Étape 3 : redémarrez l’application de bureau ChatGPT et vérifiez que le plugin apparaît.

Personnel

Ajoutez un fichier de marketplace à l’emplacement `~/.agents/plugins/marketplace.json` et stockez
vos plugins sous `~/.codex/plugins/`.

**Exemple de marketplace personnelle**

Étape 1 : copiez le dossier du plugin dans `~/.codex/plugins/my-plugin`.
mkdir -p ~/.codex/plugins
cp -R /absolute/path/to/my-plugin ~/.codex/plugins/my-plugin
Étape 2 : ajoutez ou mettez à jour `~/.agents/plugins/marketplace.json` afin que le champ
`source.path` de l’entrée du plugin pointe vers ce répertoire.

Étape 3 : redémarrez l’application de bureau ChatGPT et vérifiez que le plugin apparaît.

Le fichier de marketplace pointe vers l’emplacement du plugin. Ces répertoires sont donc des exemples et non des emplacements obligatoires. Codex résout source.path par rapport à la racine de la marketplace, et non par rapport au dossier .agents/plugins/. Consultez Métadonnées de marketplace pour connaître le format du fichier.

Après avoir modifié le plugin, mettez à jour le répertoire de plugin vers lequel pointe votre entrée de marketplace, puis redémarrez l’application de bureau ChatGPT afin que l’installation locale prenne en compte les nouveaux fichiers.

Partager un plugin local avec votre espace de travail

Après avoir créé un plugin, ajoutez-le depuis l’application de bureau ChatGPT. Sélectionnez ChatGPT et basculez vers Work dans le sélecteur, ou sélectionnez Codex, puis ouvrez Plugins. Vous pouvez ensuite le partager avec d’autres membres de votre espace de travail ChatGPT.

  1. Ouvrez Plugins dans l’application de bureau ChatGPT.
  2. Accédez à Created by you et ouvrez la page de détails du plugin.
  3. Sélectionnez Share.
  4. Ajoutez des membres ou des groupes de l’espace de travail, ou copiez un lien de partage.
  5. Choisissez les personnes autorisées à y accéder, puis envoyez l’invitation ou le lien.

Les personnes avec lesquelles vous partagez le plugin peuvent le trouver sous Shared with you dans le répertoire Plugins. Partager un plugin local avec votre espace de travail ne le publie pas dans le répertoire Plugins public. Les plugins partagés restent limités à votre espace de travail et au périmètre de votre organisation ; les comptes qui ne sont pas connectés à cet espace de travail ne peuvent pas y accéder. Utilisez des groupes lorsqu’une équipe ou un rôle doit disposer du même accès au plugin. Utilisez une marketplace pour une distribution par dépôt ou par CLI, et le partage dans l’espace de travail lorsque vous souhaitez permettre à certains membres de l’équipe d’installer un plugin depuis l’application de bureau ChatGPT.

Les administrateurs de l’espace de travail peuvent désactiver le partage de plugins dans les exigences gérées dans le cloud en ajoutant features.plugin_sharing = false à requirements.toml :

features.plugin_sharing = false

Métadonnées de marketplace

Si vous gérez une marketplace de dépôt, définissez-la dans $REPO_ROOT/.agents/plugins/marketplace.json. Pour une marketplace personnelle, utilisez ~/.agents/plugins/marketplace.json. Un fichier de marketplace contrôle l’ordre des plugins et les politiques d’installation dans l’application de bureau ChatGPT. Il peut représenter un seul plugin pendant vos tests ou une liste organisée de plugins que vous souhaitez voir affichés ensemble par l’application sous un même nom de marketplace. Avant d’ajouter un plugin à une marketplace, assurez-vous que son version, les métadonnées de son éditeur et les textes de l’interface d’installation sont prêts à être consultés par d’autres développeurs.

{
  "name": "local-example-plugins",
  "interface": {
    "displayName": "Local Example Plugins"
  },
  "plugins": [
    {
      "name": "my-plugin",
      "source": {
        "source": "local",
        "path": "./plugins/my-plugin"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    },
    {
      "name": "research-helper",
      "source": {
        "source": "local",
        "path": "./plugins/research-helper"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    }
  ]
}
  • Utilisez la propriété de premier niveau name pour identifier la marketplace.
  • Utilisez interface.displayName pour le titre de la marketplace affiché dans l’application de bureau ChatGPT.
  • Ajoutez un objet par plugin sous plugins afin de créer une liste organisée que l’application affiche sous le titre de cette marketplace.
  • Faites pointer la propriété source.path de chaque entrée de plugin vers le répertoire du plugin que Codex doit charger. Pour les installations de dépôt, il se trouve souvent sous ./plugins/. Pour les installations personnelles, ./.codex/plugins/<plugin-name> est une structure courante.
  • Gardez source.path relatif à la racine de la marketplace, faites-le commencer par ./ et conservez-le à l’intérieur de cette racine.
  • Pour les entrées locales, source peut également être un simple chemin sous forme de chaîne, comme "./plugins/my-plugin".
  • Incluez toujours policy.installation, policy.authentication et category dans chaque entrée de plugin.
  • Utilisez des valeurs policy.installation telles que AVAILABLE, INSTALLED_BY_DEFAULT ou NOT_AVAILABLE.
  • Utilisez policy.authentication pour déterminer si l’authentification intervient lors de l’installation ou de la première utilisation.

La marketplace détermine l’emplacement depuis lequel Codex charge le plugin. Une valeur locale source.path peut pointer ailleurs si votre plugin se trouve en dehors de ces exemples de répertoires. Un fichier de marketplace peut se trouver dans le dépôt où vous Développez le plugin ou dans un dépôt de marketplace distinct, et un même fichier de marketplace peut pointer vers un ou plusieurs plugins.

Les entrées de marketplace peuvent également pointer vers des sources de plugin adossées à Git. Utilisez "source": "url" lorsque le plugin se trouve à la racine du dépôt, ou "source": "git-subdir" lorsqu’il se trouve dans un sous-répertoire :

{
  "name": "remote-helper",
  "source": {
    "source": "git-subdir",
    "url": "https://github.com/example/codex-plugins.git",
    "path": "./plugins/remote-helper",
    "ref": "main"
  },
  "policy": {
    "installation": "AVAILABLE",
    "authentication": "ON_INSTALL"
  },
  "category": "Productivity"
}

Les entrées adossées à Git peuvent utiliser les sélecteurs ref ou sha. Si Codex ne parvient pas à résoudre la source d’une entrée de marketplace, il ignore cette entrée de plugin au lieu de faire échouer toute la marketplace.

Les entrées de marketplace peuvent également installer un plugin depuis un registre de packages JavaScript :

{
  "name": "npm-helper",
  "source": {
    "source": "npm",
    "package": "@example/codex-plugin",
    "version": "^1.2.0",
    "registry": "https://registry.npmjs.org"
  },
  "policy": {
    "installation": "AVAILABLE",
    "authentication": "ON_INSTALL"
  },
  "category": "Productivity"
}

package est obligatoire et peut inclure un scope de registre. version est facultatif et accepte les versions de package, les balises de distribution et les plages de versions, mais pas les sélecteurs de chemin ou d’URL. registry est facultatif et doit être une URL HTTPS sans identifiants intégrés, paramètre de requête ni fragment. Codex télécharge le package sans exécuter les scripts de cycle de vie. La CLI npm doit être installée, et l’authentification auprès du registre provient de sa configuration.

Utilisation des marketplaces par l’application de bureau ChatGPT

Une marketplace de plugins est un catalogue JSON de plugins que l’application de bureau ChatGPT peut consulter et installer.

L’application peut lire les fichiers de marketplace depuis :

  • la marketplace organisée qui alimente le répertoire officiel des plugins
  • une marketplace de dépôt à l’emplacement $REPO_ROOT/.agents/plugins/marketplace.json
  • une marketplace compatible avec l’ancien format à l’emplacement $REPO_ROOT/.claude-plugin/marketplace.json
  • une marketplace personnelle à l’emplacement ~/.agents/plugins/marketplace.json

Vous pouvez installer tout plugin proposé par une marketplace. L’application installe les plugins dans ~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/. Pour les plugins locaux, $VERSION vaut local, et l’application charge la copie installée depuis ce chemin de cache plutôt que directement depuis l’entrée de marketplace.

Vous pouvez activer ou désactiver chaque plugin individuellement. L’application enregistre l’état activé ou désactivé de chaque plugin dans ~/.codex/config.toml.

Empaqueter et distribuer des plugins

Structure d’un plugin

Chaque plugin possède un manifeste à l’emplacement .codex-plugin/plugin.json. Il peut également inclure un répertoire skills/, un répertoire hooks/ pour les hooks de cycle de vie, un fichier .app.json qui pointe vers un ou plusieurs connecteurs, un fichier .mcp.json qui configure les serveurs MCP, ainsi que des ressources utilisées pour présenter le plugin sur les surfaces prises en charge.

my-plugin/
├── .codex-plugin/
│   └── plugin.json       # Required: plugin manifest
├── skills/
│   └── my-skill/
│       └── SKILL.md      # Optional: skill instructions
├── hooks/
│   └── hooks.json        # Optional: lifecycle hooks
├── .app.json             # Optional: app or connector mappings
├── .mcp.json             # Optional: MCP server configuration
└── assets/               # Optional: icons, logos, screenshots

Seul plugin.json doit se trouver dans .codex-plugin/. Conservez skills/, hooks/, assets/, .mcp.json et .app.json à la racine du plugin.

Les plugins publiés utilisent généralement un manifeste plus complet que l’exemple minimal présent dans les squelettes de démarrage rapide. Le manifeste remplit trois fonctions :

  • Identifier le plugin.
  • Pointer vers les composants intégrés tels que les skills, les connecteurs, les serveurs MCP ou les hooks.
  • Fournir les métadonnées des surfaces d’installation, comme les descriptions, les icônes et les liens juridiques.

Voici un exemple de manifeste complet :

{
  "name": "my-plugin",
  "version": "0.1.0",
  "description": "Bundle reusable skills and connectors.",
  "author": {
    "name": "Your team",
    "email": "team@example.com",
    "url": "https://example.com"
  },
  "homepage": "https://example.com/plugins/my-plugin",
  "repository": "https://github.com/example/my-plugin",
  "license": "MIT",
  "keywords": ["research", "crm"],
  "skills": "./skills/",
  "mcpServers": "./.mcp.json",
  "apps": "./.app.json",
  "hooks": "./hooks/hooks.json",
  "interface": {
    "displayName": "My Plugin",
    "shortDescription": "Reusable skills and connectors",
    "longDescription": "Distribute skills and connectors together.",
    "developerName": "Your team",
    "category": "Productivity",
    "capabilities": ["Read", "Write"],
    "websiteURL": "https://example.com",
    "privacyPolicyURL": "https://example.com/privacy",
    "termsOfServiceURL": "https://example.com/terms",
    "defaultPrompt": [
      "Use My Plugin to summarize new CRM notes.",
      "Use My Plugin to triage new customer follow-ups."
    ],
    "brandColor": "#10A37F",
    "composerIcon": "./assets/icon.png",
    "logo": "./assets/logo.png",
    "screenshots": ["./assets/screenshot-1.png"]
  }
}

.codex-plugin/plugin.json est le point d’entrée obligatoire. Les autres champs du manifeste sont facultatifs, mais les plugins publiés les utilisent couramment.

Champs du manifeste

Utilisez les champs de premier niveau pour définir les métadonnées du package et pointer vers les composants intégrés :

  • name, version et description identifient le plugin.
  • author, homepage, repository, license et keywords fournissent les métadonnées relatives à l’éditeur et à la découverte.
  • skills, mcpServers, apps et hooks pointent vers les composants intégrés relativement à la racine du plugin.
  • interface contrôle la manière dont les surfaces d’installation présentent le plugin.

Utilisez l’objet interface pour les métadonnées des surfaces d’installation :

  • displayName, shortDescription et longDescription contrôlent le titre et les textes descriptifs.
  • developerName, category et capabilities ajoutent les métadonnées relatives à l’éditeur et aux fonctionnalités.
  • websiteURL, privacyPolicyURL et termsOfServiceURL fournissent des liens externes.
  • defaultPrompt, brandColor, composerIcon, logo et screenshots contrôlent les prompts de démarrage et la présentation visuelle.

Règles relatives aux chemins

  • Gardez les chemins du manifeste relatifs à la racine du plugin et faites-les commencer par ./.
  • Stockez si possible les ressources visuelles telles que composerIcon, logo et screenshots sous ./assets/.
  • Utilisez skills pour les dossiers de skills intégrés, apps pour .app.json, mcpServers pour .mcp.json et hooks pour les hooks de cycle de vie.
  • Les plugins activés peuvent inclure des hooks de cycle de vie avec des skills, des serveurs MCP et des connecteurs.
  • Si votre plugin stocke les hooks à l’emplacement ./hooks/hooks.json, vous n’avez pas besoin d’une entrée hooks dans .codex-plugin/plugin.json ; Codex recherche automatiquement ce fichier par défaut.

Serveurs MCP intégrés et hooks de cycle de vie

mcpServers peut pointer vers un fichier .mcp.json contenant soit un mappage direct de serveurs, soit un objet mcp_servers englobant.

Mappage direct de serveurs :

{
  "docs": {
    "command": "docs-mcp",
    "args": ["--stdio"]
  }
}

Mappage de serveurs englobé :

{
  "mcp_servers": {
    "docs": {
      "command": "docs-mcp",
      "args": ["--stdio"]
    }
  }
}

Après l’installation, les utilisateurs peuvent activer ou désactiver un serveur MCP intégré et ajuster la stratégie d’approbation des outils depuis leur configuration Codex sans modifier le plugin. Utilisez plugins.<plugin>.mcp_servers.<server> pour la stratégie de serveur MCP propre au plugin :

[plugins."my-plugin".mcp_servers.docs]
enabled = true
default_tools_approval_mode = "prompt"
enabled_tools = ["search"]

[plugins."my-plugin".mcp_servers.docs.tools.search]
approval_mode = "approve"

Lorsque votre plugin est activé, Codex peut charger ses hooks de cycle de vie en plus des hooks utilisateur, de projet et gérés.

L’installation ou l’activation d’un plugin n’accorde pas automatiquement la confiance à ses hooks. Les hooks intégrés aux plugins ne sont pas des hooks gérés ; Codex les ignore donc jusqu’à ce que l’utilisateur examine et approuve la définition actuelle du hook.

Le fichier de hooks par défaut du plugin est hooks/hooks.json :

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 ${PLUGIN_ROOT}/hooks/session_start.py",
            "statusMessage": "Loading plugin context"
          }
        ]
      }
    ]
  }
}

Si vous définissez hooks dans .codex-plugin/plugin.json, Codex utilise cette entrée du manifeste à la place de la valeur par défaut hooks/hooks.json. Le champ du manifeste peut être un chemin unique, un tableau de chemins, un objet de hooks en ligne ou un tableau d’objets de hooks en ligne.

{
  "name": "repo-policy",
  "hooks": ["./hooks/session.json", "./hooks/tools.json"]
}

Les chemins des hooks suivent les mêmes règles de manifeste que skills, apps et mcpServers : ils commencent par ./, sont résolus relativement à la racine du plugin et restent à l’intérieur de celle-ci.

Les commandes des hooks de plugin reçoivent les variables d’environnement propres à Codex PLUGIN_ROOT et PLUGIN_DATA. PLUGIN_ROOT pointe vers la racine du plugin installé, et PLUGIN_DATA vers le répertoire de données accessible en écriture du plugin. Codex définit également CLAUDE_PLUGIN_ROOT et CLAUDE_PLUGIN_DATA pour assurer la compatibilité avec les hooks de plugins existants.

Les hooks de plugins utilisent le même schéma d’événements que les hooks ordinaires. Consultez Hooks pour connaître les événements, les entrées, les sorties, l’examen de confiance et les limitations actuelles pris en charge.

Publier des plugins publics officiels

Pour publier un plugin destiné au public, soumettez-le via le portail de soumission des plugins. Consultez Soumettre des plugins pour découvrir l’intégralité du processus d’examen et de publication.