> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Plugin-Ökosystem einrichten

> Erstellen, hosten und verwalten Sie eine gemeinsame Sammlung von Devin-Plugins für Ihre gesamte Org oder Ihr Enterprise

<Note>
  Plugins befinden sich in der **geschlossenen Beta**. Um Zugriff anzufordern, wenden Sie sich an [support@cognition.ai](mailto:support@cognition.ai). Verhalten und Konfiguration können sich in künftigen Releases ändern.
</Note>

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**](https://github.com/CognitionAI/plugin-template) — eine Vorlage zum Entwickeln eines einzelnen Plugins (oder einiger weniger).
* [**team-marketplace-template**](https://github.com/CognitionAI/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.

<div id="1-author-your-plugins">
  ## 1. Entwickeln Sie Ihre Plugins
</div>

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](https://github.com/CognitionAI/plugin-template) und sieh in der [CLI-Plugin-Referenz](/de/cli/extensibility/plugins/overview) nach dem vollständigen Format. Halte `AGENTS.md` kurz — sie kostet in jeder Sitzung Kontext für alle, die das Plugin verwenden.

<div id="2-validate-and-test-locally">
  ## 2. Lokal validieren und testen
</div>

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](/de/cli/index) aus einem lokalen Ordner:

```bash theme={null}
devin plugins install ./plugins/my-plugin   # verknüpft: Änderungen werden in der nächsten Sitzung übernommen
devin plugins list
```

<div id="3-host-them-in-one-repo">
  ## 3. In einem Repo hosten
</div>

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](https://github.com/CognitionAI/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.

<div id="4-define-your-baseline-with-a-meta-plugin">
  ## 4. Legen Sie Ihre Ausgangsbasis mit einem Meta-Plugin fest
</div>

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:

```jsonc theme={null}
// .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/*"
  ]
}
```

<div id="5-distribute-from-settings-marketplace">
  ## 5. Über Settings → Marketplace verteilen
</div>

Ein Admin fügt dem verwalteten Manifest auf der [Marketplace-Einstellungsseite](https://app.devin.ai/settings/marketplace) einen Eintrag hinzu — siehe den [Leitfaden zum Plugin-Marketplace](/de/product-guides/plugins):

```json theme={null}
{
  "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.

<div id="6-govern">
  ## 6. Richtlinien steuern
</div>

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:

```json theme={null}
{
  "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](/de/product-guides/plugins#governance-rules).

<div id="7-evolve">
  ## 7. Weiterentwickeln
</div>

* Das Zusammenführen in den Standard-Branch Ihres Plugin-Repos **ist** das Release: Neue Sitzungen übernehmen es automatisch — siehe [wie Updates ausgerollt werden](/de/product-guides/plugins#how-updates-roll-out).
* 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.

<div id="current-limitations">
  ## Aktuelle Einschränkungen
</div>

* Plugins werden in Cloud-Sitzungen, der [Devin CLI](/de/cli/index) 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](/de/cli/extensibility/hooks/lifecycle-hooks) 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.

<div id="learn-more">
  ## Mehr erfahren
</div>

* [Plugin-Marketplace](/de/product-guides/plugins) — die Web-App: Manifeste, Geltungsbereiche, Uploads
* [CLI-Plugin-Referenz](/de/cli/extensibility/plugins/overview) — Dateiformat, Erstellung, Installationen pro Nutzer
* [Skills](/de/product-guides/skills) — die in Plugins gebündelten `SKILL.md`-Anleitungen