Plugin-Ökosystem einrichten

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.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 --local ./plugins/my-plugin   # verknüpft, nur diese Maschine: Änderungen werden in der nächsten Sitzung übernommen
devin plugins list

Sie können einen Plugin-Ordner oder eine .zip-Datei auch über Customize → Plugins in Ihren persönlichen Geltungsbereich hochladen und in einer Cloud-Sitzung ausprobieren.

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 Customize verteilen

Ein Admin installiert das Marketplace-Repo über Customize → Plugins → Add plugin → From repository im Geltungsbereich der Organisation oder des Enterprise – siehe den Plugins-Leitfaden. Dadurch wird dem verwalteten Manifest des Geltungsbereichs ein Entry hinzugefügt:

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

Wenn Sie das Marketplace-Repo als erforderlich festlegen, wird dessen Root-Meta-Plugin installiert, das die gesamte Ausgangsbasis rekursiv einbezieht. Customize indexiert daraufhin den Geltungsbereich und listet jedes einbezogene Plugin samt seiner Skills, MCPs, Hooks und Rules auf. Alle im Geltungsbereich erhalten die Ausgangsbasis nun automatisch — in Cloud-Sitzungen, in der Devin CLI und in Devin Desktop. Wählen Sie den Geltungsbereich bewusst:

Das Enterprise-Manifest erreicht jede Organisation im Enterprise.
Ein Organisations-Manifest erreicht die Cloud-Sitzungen dieser Organisation sowie CLI und Desktop der Member, deren primäre Organisation sie ist.

Wenn die Ausgangsbasis MCP-Server enthält, die Credentials benötigen, schließen Sie das Setup nach der Indexierung im Tab MCPs ab. Verbinden Sie bei OAuth-Servern mit Organization-Zugriff ein Service Account, den sich die Member teilen; bei Personal-Zugriff verbindet jedes Member sein eigenes Konto. Fehlen Inhalte der Ausgangsbasis, folgen Sie Indexierungs-Probleme beheben.

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 Org 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 Erforderlich/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 Abhängigkeiten und Governance.

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 sind derzeit Best Effort und Fail-Open — ein Hook, der nicht geladen werden kann oder nicht ausgeführt wird, hält die Sitzung nicht an — verlassen Sie sich daher noch nicht auf sie für entscheidende Guardrails. Weitere Informationen zur lokalen Konfiguration finden Sie in der CLI-Hooks-Referenz.
Governance ist Fail-Open: Wenn ein verwaltetes Manifest zum Sitzungsstart nicht abgerufen werden kann, werden die Plugins dieser Ebene nicht installiert und ihre Verbote für diese Sitzung nicht durchgesetzt.
Plugin-Inhalte aus einem privaten Repo erscheinen in Customize nur für Organisationen, deren Git-Integration das Repo erreichen kann; andernfalls werden sie zurückgehalten, bis das Repo unter Settings → Repositories freigegeben wird.

Mehr erfahren

Plugin-Leitfaden — die Web-App: Customize, Geltungsbereiche, Indexierung, MCPs
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 Customize 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 Customize 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 Customize verteilen

6. Richtlinien steuern

7. Weiterentwickeln

Aktuelle Einschränkungen

Mehr erfahren