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

# Plugin-Marketplace

> Installieren Sie Skill-Bundles und schreiben Sie sie für alle in Ihrer Org oder Ihrem Enterprise in der Devin Web-App vor

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

<div id="what-are-plugins">
  ## Was sind Plugins?
</div>

Ein **Plugin** ist ein Paket aus [Skills](/de/product-guides/skills) — und optional aus Regeln, Hooks und MCP-Servern —, die so gebündelt sind, dass sie als Einheit installiert und wiederverwendet werden können. Während ein Skill in einem einzelnen Repo liegt, ist ein Plugin eine portable Quelle (ein GitHub-Repo, eine git-URL, ein Unterordner eines Repos oder eine hochgeladene `.zip`), die du für deine gesamte Org oder dein Enterprise vorschreiben kannst.

**Verwaltete Plugins** ermöglichen es einem Admin, Plugins zentral über die Devin Web-App zu installieren, sodass sie für **alle in der Org oder im Enterprise** gelten — ganz ohne Setup pro Nutzer. Das gilt für Cloud-Devin-Sitzungen **und** für [Devin CLI](/de/cli/index)-Nutzer, die im Konto angemeldet sind (Konfigurationen auf Enterprise-/Kontoebene gelten auch für die CLI — siehe [Cloud-Sitzungen vs. die CLI](#cloud-sessions-vs-the-cli)). Wenn ein Plugin installiert ist, stehen seine Skills Devin automatisch als `/<plugin>:<skill>`-Befehle zur Verfügung.

Diese Seite behandelt Plugins in der Cloud (Web-App). Informationen zum Plugin-Dateiformat und zum Installationsablauf pro Nutzer in der CLI findest du in der [CLI-Plugin-Referenz](/de/cli/extensibility/plugins/overview).

<div id="where-to-configure-them">
  ## Wo Sie diese konfigurieren
</div>

Gehen Sie zu [**Settings → Marketplace**](https://app.devin.ai/settings/marketplace). Die Seite hat zwei Tabs:

* **Marketplace** — Plugins durchsuchen (den offiziellen Devin-Katalog sowie alle, die Ihre org oder Ihr Enterprise hinzugefügt hat) und installieren. Wenn Sie ein Plugin installieren, **wird es dem Manifest des gewählten Geltungsbereichs als erforderliches Plugin hinzugefügt**, sodass es für alle in diesem Geltungsbereich installiert wird.
* [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration) — das Plugin-**Manifest** direkt als JSON bearbeiten und Ihr eigenes Plugin als Ordner oder `.zip` hochladen (oder im Editor eines erstellen).

Der Zugriff ist durch Berechtigungen eingeschränkt:

* **Org-Admins** (Zugriff auf Organization Settings) verwalten das **org**-Manifest.
* **Enterprise-Admins** (Zugriff auf enterprise settings) verwalten zusätzlich das gemeinsame **enterprise**-Manifest.

<div id="the-manifest">
  ## Das Manifest
</div>

Das Manifest ist ein JSON-Dokument mit drei Listen:

```jsonc theme={null}
{
  "requiredPlugins": [
    // GitHub-Inhaber/Repo
    "acme/review-tools",

    // beliebige Git-URL
    "https://gitlab.com/acme/secure-base.git",

    // Objektform
    { "source": "github", "repo": "acme/audit-logging" },

    // ein Plugin in einem Unterordner
    {
      "source": "git-subdir",
      "url": "https://github.com/acme/vendor-plugins.git",
      "path": "plugins/stripe"
    }
  ],

  "optionalPlugins": [],

  "forbiddenPlugins": [
    "sketchy-org/bad-plugin",
    "acme/*"
  ]
}
```

* **`requiredPlugins`** — für alle im Geltungsbereich installiert (rekursiv, einschließlich aller Plugins, von denen sie abhängen).
* **`optionalPlugins`** — eine Allowlist, die Plugins zulässt, ohne sie automatisch zu installieren; wird verwendet, um Ausnahmen zu einem verbotenen Eintrag zu definieren.
* **`forbiddenPlugins`** — eine Denylist aus Plugin-Identitäten oder Glob-Mustern (z. B. `acme/*` oder `"*"` für einen vollständigen Lockdown).

Jeder Eintrag in `requiredPlugins` / `optionalPlugins` ist eine **source** — entweder eine Kurzform als String oder ein Objekt:

| Form                                                               | Bedeutung                                                      |
| ------------------------------------------------------------------ | -------------------------------------------------------------- |
| `"owner/repo"`                                                     | GitHub-Repository                                              |
| `"https://…"`, `"git@…"`, `"ssh://…"`                              | beliebige Git-URL                                              |
| `{ "source": "github", "repo": "owner/repo" }`                     | GitHub, Objektform                                             |
| `{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }` | Git-URL, Objektform                                            |
| `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`        | ein Plugin in einem Unterordner eines gemeinsam genutzten Repo |

Alle GitHub-Formen für dasselbe Repo (`owner/repo`, die HTTPS-URL, die `.git`-URL, die SSH-Form) verweisen auf dieselbe Plugin-Identität.

Das Manifest wird unverändert gespeichert; der Agent validiert beim Installieren die vollständige source.

<div id="governance-rules">
  ### Governance-Regeln
</div>

`forbiddenPlugins`-Einträge werden mit Plugin-Identitäten abgeglichen:

* Eine **exakte Identität**, angegeben als `owner/repo` oder als git-URL. Alle GitHub-Varianten desselben Repo (`owner/repo`, die HTTPS-URL, die `.git`-URL, die SSH-Form) beziehen sich auf dieselbe Identität.
* Ein **Glob-Muster** — also jeder Eintrag, der `*` enthält. Das `*` steht für jede Zeichenfolge, einschließlich `/`: `acme/*` entspricht allen GitHub-Repos von `acme`, `*/secrets` entspricht einem Repo namens `secrets` unter jedem Owner und `https://gitlab.com/acme/*` entspricht jedem Repo unter diesem Pfad.
* Das einzelne `"*"`, das auf alles andere passt (ein vollständiger Lockdown).

Die Listen werden nach dem Deny-wins-Prinzip kombiniert:

* **Deny wins.** Ein Plugin wird blockiert, wenn es von einem aktiven Manifest oder einem installierten Plugin verboten wird. Wenn nichts verboten ist, wird auch nichts blockiert.
* **Selbst-Override.** Die eigenen `requiredPlugins` und `optionalPlugins` eines Manifests (oder Plugins) — und bei einem Plugin das Plugin selbst — sind von seiner **eigenen** Verbotsliste ausgenommen; `"forbiddenPlugins": ["*"]` plus `"optionalPlugins": ["acme/approved"]` bedeutet also: „Erlaube nur, was dieses Manifest auflistet; verbiete alles andere.“ Diese Ausnahme gilt nur für diese direkten Einträge, nicht für die transitiven Abhängigkeiten eines erforderlichen Plugins — führe sie bei einem Lockdown ausdrücklich auf.
* **Keine scope-übergreifende Wiederfreigabe.** Die Allow-List eines Manifests oder Plugins kann nicht erneut erlauben, was ein **anderes** verbietet. Ein `"forbiddenPlugins": ["*"]`-Lockdown kann nicht aus einem niedrigeren Geltungsbereich ausgehebelt werden.

Die Durchsetzung erfolgt an zwei Stellen:

* **Bei der Installation** — die Installation eines blockierten Plugins (oder eines Plugins, dessen erforderliche Plugins nicht erfüllt werden können oder dessen Name mit einem installierten Plugin kollidiert) wird verweigert.
* **Beim Laden** — ein Plugin, das erst nach der Installation blockiert wird, bleibt auf dem Datenträger, aber seine Skills werden beim Start der Sitzung übersprungen, zusammen mit einer Warnung, die den Verursacher des Verbots nennt.

Zusätzlich zu diesen Regeln sind verwaltete Manifeste **hierarchisch gestuft** — **Enterprise/Konto** über **Org** über Plugin-Konfigurationen auf Repo- und Nutzerebene. Die höhere Ebene hat Vorrang: Eine niedrigere Ebene kann niemals ein Plugin verbieten, das auf einer höheren Ebene erforderlich ist, und auch niemals ein Plugin wieder erlauben, das auf einer höheren Ebene verboten ist. Ein Verbot auf Org-Ebene kann also kein auf Enterprise-Ebene erforderliches Plugin blockieren, aber ein Verbot auf Enterprise-Ebene setzt eine Anforderung auf Org-Ebene außer Kraft.

<div id="adding-your-own-plugins">
  ## Eigene Plugins hinzufügen
</div>

Ein Plugin ist einfach ein Verzeichnis, das ein `.devin-plugin/plugin.json`-Manifest und einen `skills/`-Ordner mit normalen [Skills](/de/product-guides/skills) enthält:

```
my-plugin/
├── .devin-plugin/
│   └── plugin.json     # Name, Version und optionale Abhängigkeitslisten
├── AGENTS.md           # optionale immer aktive Regel
├── rules/              # optionale ausgelöste Regeln
├── hooks.json          # optionale Lifecycle Hooks
├── mcp_config.json     # optionale MCP-Server
└── skills/
    └── review/
        └── SKILL.md    # eine gewöhnliche Skill-Datei
```

Neben Skills kann ein Plugin Folgendes mitliefern:

* **Regeln** — eine `AGENTS.md` im Plugin-Stamm wird in jeder Sitzung als immer aktive Regel eingebunden — sowohl in Cloud-Sitzungen als auch in der CLI. Markdown-Dateien in einem `rules/`-Ordner werden ebenfalls geladen; ihr `trigger`-Frontmatter wird dabei berücksichtigt — siehe die [CLI-Plugin-Referenz](/de/cli/extensibility/plugins/overview).
* **Hooks** — eine `hooks.json` im Plugin-Stamm registriert [Lifecycle Hooks](/de/cli/extensibility/hooks/lifecycle-hooks), die in der Sitzung ausgeführt werden. Cloud-Sitzungen führen `command`-Hooks für jedes Ereignis außer `SessionStart` und `SessionEnd` aus — daher funktionieren `PreToolUse`, `PostToolUse`, `PermissionRequest`, `UserPromptSubmit`, `Stop` und `PostCompaction`; Hooks vom Typ `prompt` sind nur in der CLI/lokal verfügbar.
* **MCP-Server** — eine `mcp_config.json` im Plugin-Stamm deklariert [MCP](/de/work-with-devin/mcp)-Server (`"mcpServers": { "<name>": { … } }`), die in jeder Sitzung geladen werden, in der das Plugin installiert ist. Sie erscheinen noch nicht in der MCP-Settings-UI, aber ihre Tools sind für Devin verfügbar. Die MCP-Konfiguration eines Plugins kann eine OAuth-Client-ID und Scopes festlegen, aber niemals ein OAuth-Client-Secret — eine Serverkonfiguration, die eines enthält, wird bei der Aktivierung abgelehnt.
* **Benutzerdefinierte Subagenten** — `agents/<name>.md`-Profile (oder `agents/<name>/AGENT.md`). Diese werden derzeit nur in lokalen Devin-Agenten geladen — in der [Devin CLI](/de/cli/extensibility/plugins/overview) und in Devin Desktop — nicht in Cloud-Sitzungen.

Das **Plugin ist die Installationseinheit**: Wenn Sie es installieren, werden alle enthaltenen Skills installiert (plus alles in `requiredPlugins`) — einzelne Skills aus einem Plugin lassen sich nicht installieren. Wenn Sie Skills separat anbieten möchten, teilen Sie sie auf separate Plugins auf. Das vollständige `plugin.json`-Format und den lokalen Authoring-Workflow finden Sie in der [CLI-Plugin-Referenz](/de/cli/extensibility/plugins/overview).

Je nachdem, wo sich das Plugin befindet, fügen Sie es auf eine der folgenden Arten hinzu:

| Wo es sich befindet                                          | So fügen Sie es hinzu                                                                                                                                 |
| ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Öffentliches git-Repo**                                    | Fügen Sie `"owner/repo"` (oder die git URL) zum Manifest hinzu oder installieren Sie es über den Marketplace-Tab, wenn es im Katalog enthalten ist    |
| **Privates git-Repo**                                        | Derselbe Manifest-Eintrag — unter [Verwenden eines privaten Skill-Repos](#using-a-private-skills-repo) finden Sie Informationen zur Authentifizierung |
| **Unterordner eines Repos** (z. B. ein Monorepo für Plugins) | `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }` — jeder Unterordner ist ein eigenes Plugin                                                |
| **Überhaupt nicht in einem Repo**                            | Laden Sie es als Bundle hoch (siehe unten)                                                                                                            |

Ein Repo (oder ein `git-subdir`-Unterordner) entspricht einem Plugin. Ein einzelnes Repo kann viele Plugins in Unterordnern enthalten, auf die jeweils mit einem eigenen `git-subdir`-Eintrag verwiesen wird.

<div id="uploading-a-plugin-bundle">
  ### Hochladen eines Plugin-Bundles
</div>

Auf dem Tab [**Configuration**](https://app.devin.ai/settings/marketplace?tab=configuration) können Sie im Abschnitt **Hochgeladenes Plugin** ein Plugin als Ordner oder `.zip` hochladen oder direkt im Editor erstellen. Beim Speichern wird es dem Manifest als erforderliches Plugin hinzugefügt (und damit für alle im Geltungsbereich installiert); beim Löschen wird der Verweis entfernt. Das ist eine gute Option für Plugins, die Sie nicht in einem Git-Repo hosten möchten oder können.

<div id="using-a-private-skills-repo">
  ### Verwendung eines privaten Skill-Repos
</div>

Verweisen Sie im Manifest direkt auf das private Repo — in der Regel müssen Sie es nicht in Ihren [Environment-Snapshot](/de/onboard-devin/environment/blueprints) aufnehmen. Jedes private Repo, auf das Devin über Ihre Git-Integration bereits zugreifen kann, wird automatisch installiert. Verwenden Sie die Git-URL-Form oder `git-subdir`, um ein Plugin aus einem Unterordner eines gemeinsam genutzten Repos zu installieren. (CLI-Nutzer, auf die derselbe Manifest-Abruf zutrifft, verwenden ihre eigenen lokalen Git-Zugangsdaten und benötigen daher ebenfalls Zugriff auf das Repo.)

Wenn das Repo über Ihre Git-Integration nicht erreichbar ist, **laden Sie es entweder als Bundle hoch** (oben) oder klonen Sie es während des Environment-Setup und referenzieren Sie es über einen lokalen Pfad.

<div id="how-updates-roll-out">
  ## Wie Updates bereitgestellt werden
</div>

* **Manifest-Änderungen** (Settings → Marketplace) gelten ab der **nächsten Sitzung**.
* **Plugin-Änderungen** — ein Merge in den Branch, den ein Plugin verfolgt, wird innerhalb weniger Stunden automatisch in neue Sitzungen übernommen. Pinne das Plugin an eine Commit-SHA an, um Updates selbst zu steuern; in der CLI aktualisiert `devin plugins update` sofort.
* Laufende Sitzungen behalten, was sie beim Start geladen haben — Updates ändern eine Sitzung niemals während der Laufzeit.

<div id="compatibility">
  ## Kompatibilität
</div>

Claude-Plugins funktionieren auch: Wenn keine `.devin-plugin/plugin.json` vorhanden ist, greift Devin stattdessen auf `.claude-plugin/plugin.json` zurück. Wenn beide Manifestdateien vorhanden sind, hat die von Devin Vorrang.

<div id="scope-and-inheritance">
  ## Geltungsbereich und Vererbung
</div>

Verwaltete Manifeste gibt es auf bis zu zwei Ebenen:

* **Standalone-Konten** haben ein einzelnes **account**-Manifest, das für alle gilt.
* **Enterprises** haben ein gemeinsames **enterprise**-Manifest, das **an jede untergeordnete org vererbt wird**, sowie ein pro-**org**-Manifest darunter. Die Marketplace-Ansicht zeigt beide an, und Enterprise-Admins können wählen, ein plugin auf Enterprise-Ebene zu installieren (gilt überall), oder ein Org-Admin kann es nur für seine org installieren.

Diese stehen ganz oben in der gesamten plugin-Hierarchie, über jeder plugin-Konfiguration pro Repo oder pro Nutzer:

1. **Enterprise / account**-Manifest (diese Seite)
2. **Org**-Manifest (diese Seite)
3. plugin-Konfiguration auf **Repo**-Ebene (die `.devin/config.json` eines Repo)
4. plugins auf **Nutzer**-Ebene — die eigenen [CLI](/de/cli/extensibility/plugins/overview)-Installationen einer Person, die nur für ihren lokalen Devin-Agenten gelten und nie in Cloud-Sitzungen geladen werden

Die höhere Ebene hat Vorrang: Eine niedrigere Ebene kann niemals ein plugin erlauben, das auf einer höheren Ebene verboten ist, oder ein plugin verbieten, das auf einer höheren Ebene erforderlich ist (siehe [Governance-Regeln](#governance-rules)).

<div id="cloud-sessions-vs-the-cli">
  ### Cloud-Sitzungen vs. die CLI
</div>

Sowohl Cloud-Devin-Sitzungen als auch die [Devin CLI](/de/cli/index) erzwingen das **Enterprise-/Konto-Manifest** — erforderliche Plugins werden installiert, und Verbote gelten auch für CLI-Nutzer, die beim Konto angemeldet sind.

Das **org**-Manifest gilt nur für **Cloud-Sitzungen**. Bei der CLI erfolgt die Authentifizierung auf Kontoebene und sie hat keinen org-Kontext, daher gelten Anforderungen und Verbote auf org-Ebene nicht für CLI-Nutzer. Alles, was in der CLI (oder kontoweit) erzwungen werden muss, sollte im Enterprise-/Konto-Manifest stehen; das org-Manifest ist für org-spezifische Ergänzungen in Cloud-Sitzungen gedacht.

<div id="learn-more">
  ## Weitere Informationen
</div>

* [Skills](/de/product-guides/skills) — die in `SKILL.md` definierten Anleitungen, die Plugins mitliefern
* [CLI-Plugin-Referenz](/de/cli/extensibility/plugins/overview) — Plugin-Dateiformat, Erstellung und Installation pro Nutzer
* [Playbooks](/de/product-guides/creating-playbooks) — wiederverwendbare Prompt-Vorlagen, die Sitzungen zugeordnet werden