Plugin-Ökosystem einrichten

Plugins befinden sich in der geschlossenen Beta. Um Zugriff anzufordern, wenden Sie sich an support@cognition.ai. Verhalten und Konfiguration können sich in künftigen Releases ändern.

Diese Anleitung zeigt, wie Sie Ihr eigenes Plugin-Ökosystem aufbauen: ein Repo mit Plugins, das Ihrer Org gehört und über ein verwaltetes Manifest an jede Devin-Sitzung und alle CLI-Nutzer verteilt wird, wobei erforderliche, optionale und verbotene Plugins als Governance-Regeln dienen. Zu dieser Anleitung gehören zwei Vorlage-Repos:

plugin-template — eine Vorlage zum Entwickeln eines einzelnen Plugins (oder einiger weniger).
team-marketplace-template — das vollständige Muster für ein Ökosystem: ein Monorepo mit Plugins plus ein Meta-Plugin, dessen Manifest Ihre Ausgangsbasis und Richtlinie definiert.

1. Entwickeln Sie Ihre Plugins

Ein Plugin ist ein Verzeichnis mit einem .devin-plugin/plugin.json-Manifest; alles andere ist optional:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, dependency + policy lists
├── AGENTS.md           # always-on rule
├── rules/              # triggered rules
├── agents/<name>.md   # benutzerdefinierte Subagenten (derzeit nur CLI/Desktop); agents/<name>/AGENT.md funktioniert ebenfalls
├── hooks.json          # lifecycle hooks
├── mcp_config.json     # MCP servers
└── skills/<name>/SKILL.md   # skills, exposed as /<plugin>:<skill>

Forke zunächst plugin-template und sieh in der CLI-Plugin-Referenz nach dem vollständigen Format. Halte AGENTS.md kurz — sie kostet in jeder Sitzung Kontext für alle, die das Plugin verwenden.

2. Lokal validieren und testen

Beide Vorlagen enthalten einen Validator (node scripts/validate-template.mjs) und einen CI-Workflow, der ihn bei jeder PR ausführt. Für einen Praxistest installieren Sie das Paket mit der Devin CLI aus einem lokalen Ordner:

devin plugins install ./plugins/my-plugin   # verknüpft: Änderungen werden in der nächsten Sitzung übernommen
devin plugins list

3. In einem Repo hosten

Legen Sie alle Plugins Ihrer Org in einem einzigen Repo als Unterordner ab (plugins/<name>/), wobei jedes über eine eigene git-subdir-Quelle referenziert wird. Das Repo kann privat bleiben: Cloud-Sitzungen greifen über Ihre Git-Integration darauf zu, und CLI-Nutzer greifen mit ihren eigenen Git-Zugangsdaten darauf zu (sie benötigen also ebenfalls Zugriff auf das Repo). Forken Sie team-marketplace-template für dieses Layout — und aktualisieren Sie die git-subdir-URLs des Meta-Plugins so, dass sie auf Ihren Fork verweisen. Im Template befindet sich das Meta-Plugin im Repo-Stammverzeichnis, sodass das Repo selbst die installierbare Einheit ist: Wenn Sie your-org/your-marketplace angeben, wird die gesamte Ausgangsbasis installiert.

4. Legen Sie Ihre Ausgangsbasis mit einem Meta-Plugin fest

Das Meta-Plugin-Muster macht Ihr gesamtes Ökosystem zu einer installierbaren Einheit. Es ist ein Plugin mit wenig oder gar keinem eigenen Inhalt — sein Manifest erledigt die Arbeit. Platzieren Sie es im Stammverzeichnis des Repos, damit das Repo selbst das Meta-Plugin ist:

// .devin-plugin/plugin.json (Repo-Stammverzeichnis)
{
  "name": "team-starter-pack",
  "requiredPlugins": [
    // automatisch für alle installiert, rekursiv
    { "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": [
    // empfohlen, nicht automatisch installiert; auch eine Ausnahme von den Verboten dieses Manifests
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ],
  "forbiddenPlugins": [
    "untrusted-vendor/*"
  ]
}

5. Über Settings → Marketplace verteilen

Ein Admin fügt dem verwalteten Manifest auf der Marketplace-Einstellungsseite einen Eintrag hinzu — siehe den Leitfaden zum Plugin-Marketplace:

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

Das Festlegen des Marketplace-Repo als erforderlich installiert sein Meta-Plugin auf Stammebene, das rekursiv die gesamte Ausgangsbasis einbindet. Alle im Geltungsbereich erhalten jetzt automatisch die Ausgangsbasis. Wählen Sie den Geltungsbereich bewusst:

Das **Enterprise-/Konto-**Manifest gilt für Cloud-Sitzungen und für CLI-Nutzer, die beim Konto angemeldet sind.
Das org-Manifest gilt nur für Cloud-Sitzungen — die CLI hat keinen org-Kontext.

6. Richtlinien steuern

Auf jeder Ebene gibt es dieselben drei Listen als Richtliniensprache (verwaltete Manifeste, Repo-Konfiguration, Plugin-Manifeste). Die höhere Ebene hat Vorrang — Enterprise/Konto vor Organisation vor Repo vor Nutzer — und eine niedrigere Ebene kann niemals wieder erlauben, was eine höhere Ebene verbietet, oder verbieten, was sie vorschreibt. Um ein Konto ausschließlich auf eine genehmigte Auswahl festzulegen:

{
  "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" }
  ]
}

Die eigenen Required/Optional-Einträge des Manifests sind von seinem eigenen "*"-Verbot ausgenommen; nichts anderes ist ausgenommen, und keine niedrigere Ebene kann diese Ausnahme erweitern. Die Ausnahme gilt nur für direkt aufgeführte Einträge — die transitiven Abhängigkeiten eines erforderlichen Plugins sind also nicht ausgenommen — deshalb müssen Sie bei einem Lockdown alles, was das Meta-Plugin einbindet (hier engineering-baseline und security-guardrails), explizit aufführen. Die vollständige Semantik finden Sie unter Governance-Regeln.

7. Weiterentwickeln

Das Zusammenführen in den Standard-Branch Ihres Plugin-Repos ist das Release: Neue Sitzungen übernehmen es automatisch — siehe wie Updates ausgerollt werden.
Teams fügen Plugins per PR zum Marketplace-Repo hinzu; die CI der Vorlage validiert das Layout bei jeder PR.
Vorhandene Claude-Plugins werden unverändert installiert (Devin greift auf .claude-plugin/plugin.json zurück), sodass Sie Community-Plugins in optionalPlugins empfehlen können, ohne sie ins Repo übernehmen zu müssen.

Aktuelle Einschränkungen

Plugins werden in Cloud-Sitzungen, der Devin CLI und in Devin Desktop (bei Verwendung von Devin Local) geladen; auf den klassischen Cascade-Agenten sind sie nicht anwendbar.
Subagenten (agents/<name>.md oder agents/<name>/AGENT.md) werden nur in lokalen Devin-Agenten geladen (CLI und Devin Desktop), nicht in Cloud-Sitzungen.
Hooks: Cloud-Sitzungen führen command-Hooks für jedes Ereignis außer SessionStart und SessionEnd aus; Hooks vom Typ prompt sind nur in CLI/lokalen Umgebungen verfügbar.
Von Plugins bereitgestelltes MCP wird innerhalb der Sitzung geladen, erscheint aber noch nicht in der MCP-Settings-UI.
Manifeste auf Org-Ebene erreichen CLI-Nutzer nicht; verwenden Sie für die CLI-Enforcement das Enterprise-/Account-Manifest.

Mehr erfahren

Plugin-Marketplace — die Web-App: Manifeste, Geltungsbereiche, Uploads
CLI-Plugin-Referenz — Dateiformat, Erstellung, Installationen pro Nutzer
Skills — die in Plugins gebündelten SKILL.md-Anleitungen

Loslegen

Grundlegende Richtlinien

Einführung in Devin

Arbeiten mit Devin

Produktleitfäden

Integrationen

Admin

Versionshinweise

Plugin-Ökosystem einrichten

1. Entwickeln Sie Ihre Plugins

2. Lokal validieren und testen

3. In einem Repo hosten

4. Legen Sie Ihre Ausgangsbasis mit einem Meta-Plugin fest

5. Über Settings → Marketplace verteilen

6. Richtlinien steuern

7. Weiterentwickeln

Aktuelle Einschränkungen

Mehr erfahren

​1. Entwickeln Sie Ihre Plugins

​2. Lokal validieren und testen

​3. In einem Repo hosten

​4. Legen Sie Ihre Ausgangsbasis mit einem Meta-Plugin fest

​5. Über Settings → Marketplace verteilen

​6. Richtlinien steuern

​7. Weiterentwickeln

​Aktuelle Einschränkungen

​Mehr erfahren

1. Entwickeln Sie Ihre Plugins

2. Lokal validieren und testen

3. In einem Repo hosten

4. Legen Sie Ihre Ausgangsbasis mit einem Meta-Plugin fest

5. Über Settings → Marketplace verteilen

6. Richtlinien steuern

7. Weiterentwickeln

Aktuelle Einschränkungen

Mehr erfahren