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 bündelt Skills — und optional Regeln, Hooks, MCP-Server und Subagenten —, sodass es als Einheit installiert und wiederverwendet werden kann. Informationen zum Dateiformat und dazu, was ein Plugin enthalten kann, findest du in der Plugin-Referenz. 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 die Web-App-Seite von Plugins: verwaltete Manifeste, Geltungsbereiche und Uploads.

​
Wo Sie diese konfigurieren

Gehen Sie zu Settings → Resources → Plugins. 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.
Das Manifest wird unverändert gespeichert; der Agent validiert beim Installieren die vollständige source. In der Plugin-Referenz finden Sie die source-Formen, die jeder Eintrag annehmen kann, sowie die vollständige Abhängigkeits- und Governance-Semantik.

​
Eigene Plugins hinzufügen

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

​
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 → Resources → Plugins) 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.

​
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 der plugin-Konfiguration auf Repo- und Nutzer-Ebene. Informationen zu den anderen Ebenen und den Vorrangregeln finden Sie unter Vererbung und Ebenen.

​
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