Skip to main content
Plugins befinden sich in der geschlossenen Beta. Um Zugriff zu beantragen, wenden Sie sich an support@cognition.ai. Verhalten und Konfiguration können sich in zukünftigen Releases ändern.

​
Was sind Plugins?

Ein Plugin ist ein Paket aus 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-Nutzer, die im Konto angemeldet sind (Konfigurationen auf Enterprise-/Kontoebene gelten auch für die CLI — siehe Cloud-Sitzungen vs. die 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.

​
Wo Sie diese konfigurieren

Gehen Sie zu 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 — 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.

​
Das Manifest

Das Manifest ist ein JSON-Dokument mit drei Listen:
  • 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: 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.

​
Governance-Regeln

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.

​
Eigene Plugins hinzufügen

Ein Plugin ist einfach ein Verzeichnis, das ein .devin-plugin/plugin.json-Manifest und einen skills/-Ordner mit normalen Skills enthält:
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.
  • Hooks — eine hooks.json im Plugin-Stamm registriert 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-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 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. Je nachdem, wo sich das Plugin befindet, fügen Sie es auf eine der folgenden Arten hinzu: 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.

​
Hochladen eines Plugin-Bundles

Auf dem 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.

​
Verwendung eines privaten Skill-Repos

Verweisen Sie im Manifest direkt auf das private Repo — in der Regel müssen Sie es nicht in Ihren Environment-Snapshot 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.

​
Wie Updates bereitgestellt werden

  • 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.

​
Kompatibilität

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.

​
Geltungsbereich und Vererbung

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-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).

​
Cloud-Sitzungen vs. die CLI

Sowohl Cloud-Devin-Sitzungen als auch die Devin CLI 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.

​
Weitere Informationen

  • Skills — die in SKILL.md definierten Anleitungen, die Plugins mitliefern
  • CLI-Plugin-Referenz — Plugin-Dateiformat, Erstellung und Installation pro Nutzer
  • Playbooks — wiederverwendbare Prompt-Vorlagen, die Sitzungen zugeordnet werden