Devin-Plugins und die Customize-Seite

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. Plugins sind die gemeinsame Anpassungsschicht über Cloud-Devin-Sitzungen, die Devin CLI und Devin Desktop hinweg: Installiere ein Plugin einmal, und seine Skills stehen überall dort, wo du Devin nutzt, als /<plugin>:<skill>-Befehle zur Verfügung. Plugins können auf drei Ebenen installiert werden:

Geltungsbereich	Wer installiert	Wer erhält es
Personal	Du	Deine eigenen Sitzungen — Cloud, CLI und Desktop, auf jedem Gerät, auf dem du angemeldet bist
Organization	Org-Admins	Die Cloud-Sitzungen dieser Organisation sowie die CLI und Desktop für Mitglieder, deren primäre Organisation sie ist
Enterprise	Enterprise-Admins	Alle in jeder Organisation des Enterprise

Diese Seite behandelt die Web-App-Seite: die Customize-Seite, die Installation in den einzelnen Geltungsbereichen, Indexing, MCPs und die verwalteten Manifeste, die dahinterstehen.

Die Customize-Seite

Plugins befinden sich auf der Seite Customize, die du über den Eintrag Customize in der Sidebar erreichst (sie ersetzt die früheren Seiten Settings → Plugins, Settings → Marketplace und Settings → Connections → MCP servers; alte Links werden weitergeleitet). Sie hat fünf Tabs:

Plugins — alles Installierte, nach Geltungsbereich gruppiert, sowie Browse marketplace, um weitere zu installieren.
Skills — die Skills, die Devin bei Bedarf lädt, aus installierten Plugins und deinen Repositories.
MCPs — die MCP-Server, die Devin Tools über die integrierten hinaus bereitstellen. Siehe MCPs weiter unten.
Hooks — Befehle, die an bestimmten Punkten einer Sitzung automatisch ausgeführt werden.
Rules — dauerhafte Vorgaben, die Devin in jeder Sitzung befolgt.

Über die Geltungsbereich-Tabs wählst du je nach deinen Zugriffsrechten Personal, Organization oder Enterprise. Jeder Geltungsbereich zeigt seinen effektiven Inhalt: das, was nach der Governance tatsächlich gilt. Inhalte auf Repository-Ebene (Skills, Rules und Plugins, die in der .devin/config.json eines Repos deklariert sind) änderst du direkt in den Dateien des Repositories. Wer was ändern kann:

Personal — alle, für ihren eigenen Geltungsbereich.
Organization — Member mit Zugriff auf die Organization Settings.
Enterprise — Member mit Zugriff auf die enterprise settings.

Klicke auf ein Plugin, um sein Detailfenster zu öffnen: seine Skills, MCPs, Hooks, Rules und Subagents; die verfolgte Ref oder den angepinnten SHA samt Pfad; in welchen Geltungsbereichen es installiert ist und was es voraussetzt; seine Permissions; und — sofern du die entsprechenden Rechte hast — Aktionen, um seine MCPs zu verbinden, seine Voraussetzungen zu ändern, es zu deinstallieren oder (bei einem hochgeladenen Plugin) zu löschen.

Plugins installieren

Aus dem Marketplace

Klicke im Tab Plugins auf Browse marketplace. Der Marketplace ist eine einzige Liste, die den offiziellen Devin-Marketplace (CognitionAI/devin-marketplace, meist ein Plugin pro Integration, etwa Linear, Notion, Datadog oder Snowflake) mit allen Plugins zusammenführt, die deine Organisation oder dein Enterprise hinzugefügt hat. Jede Karte bietet ein Installationsmenü mit allen Geltungsbereichen, in die du schreiben darfst, und zeigt an, wo das Plugin bereits installiert ist („Installed for me“, „Installed at organization“, …). Vor der ersten Installation eines Plugins zeigt Devin einen Sicherheitshinweis an: Mit der Installation darf Devin die Rules, Hooks und Skills des Plugins ausführen (und bei einem Plugin mit MCP-Servern über diese auf externe Daten zugreifen). Fahre also nur fort, wenn du dem Plugin vertraust und seine Quelle überprüft hast. Plugins aus dem offiziellen Marketplace sind entsprechend gekennzeichnet. Nach der Installation bestätigt ein Toast den Geltungsbereich und bietet – falls das Plugin einen MCP-Server mitbringt, der Anmeldedaten oder eine Autorisierung benötigt – Connect MCP an, um das Setup direkt abzuschließen. Enterprise-Admins können den offiziellen Marketplace für alle Organisationen ausblenden (Schalter Show official marketplace plugins) und unter Marketplace availability steuern, welche MCP-Server aus dem Marketplace für Organisationen sichtbar sind.

Aus einem Repository, einer `.zip`-Datei oder dem Editor

Das Menü Add plugin im Tab Plugins unterstützt drei weitere Quellen, die sich jeweils in jedem Geltungsbereich installieren lassen, für den du Schreibrechte hast:

Speicherort	So fügst du es hinzu
Git-Repo (öffentlich oder privat)	From repository – gib `owner/repo` oder eine git URL an, bei Plugins in einem Unterordner zusätzlich das Unterverzeichnis. Jedes private Repo, das Devin über deine Git-Integration erreichen kann, funktioniert.
Nicht in einem Repo	Upload .zip – ein hochgeladenes Plugin-Bundle wird im jeweiligen Geltungsbereich gespeichert und für alle darin installiert.
Existiert noch nicht	Create plugin – ein Datei-Editor mit den Tabs Preview/Source und Version history (jedes Speichern erzeugt eine wiederherstellbare Version).

Hochgeladene und erstellte Plugins lassen sich später über ihr Detailfenster bearbeiten. Beim Löschen werden die zugehörigen Dateien dauerhaft entfernt – es gibt keine weitere Kopie. Lege keine Secrets in Plugin-Dateien ab; verwende stattdessen Secret-Referenzen.

Über die CLI

devin plugins install <source> fügt das Plugin standardmäßig Ihrem persönlichen Geltungsbereich hinzu, sodass es Ihnen in Cloud-Sitzungen und auf Ihre anderen Geräte folgt. Mit --local installieren Sie es nur auf der aktuellen Maschine. Siehe die CLI-Befehle.

Devin die Arbeit überlassen

In einer Cloud-Sitzung können Sie Devin bitten, etwas als persönlichen Skill, persönliche Rule, persönlichen Hook oder persönlichen MCP-Server zu speichern oder ein Plugin für Sie zu installieren. Devin schlägt die Änderung als Karte vor, die Sie genehmigen oder ablehnen können; genehmigte Änderungen werden in Ihrem persönlichen Geltungsbereich gespeichert und gelten für künftige Sitzungen.

Wie Plugins zu Sitzungen gelangen (Cloud ↔ lokale Synchronisierung)

Jeder Geltungsbereich basiert auf einem managed manifest, das in Devin Cloud gespeichert wird (siehe Das Manifest). Eine Installation an beliebiger Stelle schreibt in dieses Manifest, und jede Surface liest es aus:

Cloud-Sitzungen rufen beim Start die Manifeste von Enterprise, Organisation und Nutzer ab und installieren die daraus resultierenden Plugins auf der Sitzungsmaschine – zusätzlich zu den Plugins, die von den geklonten Repositorys deklariert werden.
Die Devin CLI und Devin Desktop rufen dieselben Manifeste ab, wenn Sie angemeldet sind. Ein Plugin, das Sie im Web installieren, erscheint so auch auf Ihrem Laptop, und ein devin plugins install auf Ihrem Laptop wirkt sich auf Ihre nächste Cloud-Sitzung aus. Plugins aus privaten Repos werden mit Ihren lokalen git-Anmeldedaten abgerufen, Sie benötigen also selbst Zugriff auf das Repo. Ein Enterprise kann CLI-Plugins vollständig deaktivieren (Devin CLI plugins in den enterprise settings).
Einzelnutzer (ohne Organisation) verfügen nur über einen persönlichen Geltungsbereich.

Laufende Sitzungen behalten das, was sie beim Start geladen haben; Änderungen greifen erst in der nächsten Sitzung. Plugin-Installation und MCP-Authentifizierung sind separate Schritte. Cloud-MCPs verbinden Sie über Customize → MCPs; für den OAuth-Server eines Plugins, der in der CLI läuft, verwenden Sie devin mcp login. Die Synchronisierung eines Plugins bedeutet nicht, dass alle Geräte dieselben Anmeldedaten verwenden.

Indexing

Devin führt einen Index der Plugins jedes Geltungsbereichs: Devin klont jede Plugin-Quelle, liest deren Manifest und Inhalte, bezieht Abhängigkeiten und wendet Governance an. Die Customize-Seite zeigt das Ergebnis der Indexierung — die Plugins, ihre Skills, MCPs, Hooks und Rules sowie alles, was durch eine Richtlinie blockiert wurde — und die Statuszeile gibt an, wann jeder Geltungsbereich zuletzt indexiert wurde.

Was sie auslöst — beim Installieren, Entfernen oder Bearbeiten eines Plugins wird automatisch eine erneute Indexierung in die Warteschlange gestellt. Verwende Plugin settings → Reindex plugins, um den Index zu aktualisieren, nachdem du Änderungen in das Quell-Repository eines Plugins gepusht hast.
Während der Ausführung — ein Lauf kann scheduled, queued, starting oder indexing sein. Häufige erneute Indexierungen werden zeitlich entzerrt, und beim Speichern hochgeladener Bundles kann es einen Moment dauern, bis sie in der Warteschlange landen. Plugin-MCPs können verbunden werden, sobald ihre Konfiguration indexiert wurde.
Ergebnisse — öffne Plugin settings (das Zahnradmenü), um den Zeitpunkt der letzten Indexierung und etwaige Probleme zu sehen. Nach einer fehlgeschlagenen Aktualisierung kann weiterhin das letzte erfolgreiche Ergebnis sichtbar sein; dass ein Plugin in der Liste erscheint, bedeutet also nicht, dass die letzte Aktualisierung erfolgreich war.
Repository-Zugriff — Plugin-Inhalte, die aus einem Repository indexiert wurden, werden nur in einer Organisation angezeigt, die über ihre Git-Integration Zugriff auf dieses Repository hat. Ist das nicht der Fall, wird der Inhalt des Geltungsbereichs mit dem Hinweis Plugin repos unauthorized zurückgehalten; erteile den Zugriff auf das Repository unter Settings → Repositories. Die Governance eines zurückgehaltenen Geltungsbereichs (dessen forbid-Regeln) gilt weiterhin.
Network policy — die Indexierung läuft auf einer Maschine, welche die session network policy deiner Organisation erbt; Plugin-Quellen müssen darunter also erreichbar sein.

Die Sitzungen selbst warten nicht auf den Index: Sie holen und installieren Plugins direkt beim Start.

Indexing-Probleme beheben

Öffnen Sie Customize → Plugins in der Organisation, in der Sie das Plugin benötigen. Wählen Sie den Geltungsbereich Personal, Organization oder Enterprise aus und öffnen Sie anschließend Plugin settings, um das Problem sowie das darin genannte Plugin bzw. den genannten Geltungsbereich einzusehen.
Wenn ein Lauf geplant ist, in der Warteschlange steht, gerade startet oder indexiert wird, lassen Sie ihn zunächst abschließen. Wurde das Plugin noch nie indexiert oder hat sich seine Quelle seit dem letzten Index geändert, wählen Sie Reindex plugins.
Verwenden Sie bei einem fehlgeschlagenen Lauf oder fehlenden Inhalten die passende Lösung aus der Tabelle unten. Speichern oder committen Sie die Korrektur, wählen Sie dann Reindex plugins und prüfen Sie das Ergebnis erneut. Für Änderungen an einem gemeinsam genutzten Manifest oder an Repository-Berechtigungen ist unter Umständen ein Admin erforderlich.

Meldung oder Symptom	Vorgehen
Plugin repos unauthorized	Bitten Sie einen Admin, der betroffenen Organisation unter Settings → Repositories Zugriff auf jedes im Problem genannte Repository zu gewähren. Bei einem Enterprise-Plugin muss der Repository-Zugriff möglicherweise mehreren Organisationen gewährt werden. Das Hinzufügen des Plugins zu einem Manifest gewährt für sich genommen keinen Repository-Zugriff.
Plugin source could not be cloned oder Repository unavailable	Prüfen Sie die Repository-URL, den Branch oder Tag und den angepinnten Commit. Stellen Sie sicher, dass die Organisation Leseberechtigung für das Repository hat, auch wenn es bereits in der Repository-Liste erscheint. Prüfen Sie die network policy, falls der Git-Host nicht erreichbar ist. Führen Sie nach der Korrektur des Zugriffs oder der Quellreferenz ein Reindexing durch.
No plugin manifest found	Prüfen Sie, ob die Quelle auf das Plugin-Verzeichnis verweist. Ein Plugin in einem Unterordner benötigt dieses Unterverzeichnis in seiner Quellreferenz. Legen Sie ein unterstütztes Manifest am erwarteten Ort ab.
Plugin manifest malformed, Skill malformed, MCP config malformed oder ein anderes fehlerhaftes Asset	Öffnen Sie beim Problem den Link Learn more zum jeweiligen Format. Korrigieren Sie die genannte Datei im Quell-Repository oder im Editor des hochgeladenen Plugins. Prüfen Sie Manifest-Felder, Skill-Frontmatter, MCP Configuration sowie Pfade relativ zum Plugin-Stammverzeichnis.
Conflicting version pins	Prüfen Sie die Manifeste, die das Plugin erfordern. Gleichen Sie deren `sha`-Werte an oder lassen Sie den Geltungsbereich mit der höheren Autorität den Pin vorgeben. Siehe Konflikte und Abhängigkeiten. Ein Reindexing allein kann widersprüchliche Pins nicht auflösen.
Plugin source not pinned	Dies ist lediglich ein Hinweis, kein Indexing-Fehler. Das Plugin folgt einem Branch oder Tag. Pinnen Sie es an einen Commit an, wenn Sie eine feste Version benötigen.
Could not load plugin contents oder Indexed content unavailable	Wählen Sie Reindex plugins, um die indexierten Inhalte neu aufzubauen. Zeigt die Seite stattdessen Couldn’t load your configuration an, versuchen Sie es über Try again erneut.
Installed but blocked	Sehen Sie nach, welcher Geltungsbereich das Plugin verbietet, und bitten Sie den Eigentümer der Richtlinie um eine Prüfung. Ein niedrigerer Geltungsbereich kann diese Richtlinie nicht übersteuern; siehe Governance.

Nach erfolgreichem Indexing öffnen Sie die Details des Plugins und prüfen, ob die erwarteten Skills, Rules, Hooks oder MCPs erscheinen. Wenn ein MCP noch eine Autorisierung benötigt, schließen Sie die Verbindung ab. Um geänderte Plugin-Inhalte zu verwenden, starten Sie eine neue Sitzung. Bei einer veralteten CLI-Installation verwenden Sie devin plugins update; ein Reindexing in Customize aktualisiert lediglich die Web-Auflistung. Eine mit --local durchgeführte Installation bleibt auf dem jeweiligen Gerät. Wenn das Indexing weiterhin fehlschlägt oder ein Lauf ohne Fortschritt in der Warteschlange oder im Indexing verbleibt, wenden Sie sich an den Support. Geben Sie dabei Organisation und Geltungsbereich, Plugin-Quelle und Ref, den Zeitpunkt des letzten Indexings, die genaue Fehlermeldung sowie einen Screenshot des Problems an.

MCPs

MCP-Server werden im Tab MCPs von Customize verwaltet – für dieselben drei Geltungsbereiche. Der Tab enthält zwei Arten von Einträgen:

From plugins — MCP-Server, die von einem installierten Plugin deklariert werden. Die Verbindungseinstellungen (URL, Transport, erforderliche Anmeldedaten) gehören zum Plugin und werden read-only angezeigt; aktivieren, deaktivieren, verbinden oder deinstallieren kannst du es trotzdem. Die meisten offiziellen Marketplace-Plugins bestehen aus einem einzelnen MCP-Server und optional Skills.
Standalone — MCP-Server, die eigenständig installiert werden: eigene Server (Add custom MCP) sowie Server aus dem bisherigen MCP marketplace, der weiterhin über den Tab erreichbar ist.

Verbinden. Ein Plugin-MCP, das einen API key benötigt, öffnet ein Connect-Fenster, in dem die zugehörigen Secrets bereits zum Ausfüllen bereitstehen; eines, das OAuth verwendet, öffnet den Autorisierungsablauf des Anbieters; eines, das beides nicht benötigt, ist einsatzbereit, sobald das Plugin installiert ist. Verbinden kannst du über den Installations-Toast, das Detailfenster des Plugins oder die Zeile des MCP. Gemeinsame Verbindungen vs. Verbindungen pro Member. Bei einem OAuth-MCP, das im Geltungsbereich Organization oder Enterprise installiert ist, bestimmt die Einstellung Access des Servers, wie die Verbindung geteilt wird: Bei Organization-Zugriff gibt es eine gemeinsame Verbindung für alle im Geltungsbereich — verwende dafür ein service account und kein persönliches Login — bei Personal-Zugriff autorisiert dagegen jedes Member sein eigenes Konto. Bei Servern ohne Zugriff pro Member installierst du das Plugin (oder das MCP) im persönlichen Geltungsbereich, wenn jedes Member eigene Anmeldedaten benötigt. Wenn Members dasselbe Marketplace-MCP nacheinander einzeln verbinden, kann ein Admin es einmal für die Organization installieren; Plugins, die es deklarieren, nutzen dann diese Verbindung. Enterprise-MCPs. Enterprise admins konfigurieren einen Server einmalig — einschließlich eines CA certificate-Bundles einer privaten CA für MCP-Traffic, der über das Kundennetzwerk geroutet wird — und wählen aus, welche Organizations ihn erhalten. Installiert eine Organization denselben Server selbst, überschreibt das die Enterprise-Installation. Informationen zu Transporttypen, Feldern für eigene Server und serverspezifischen Setup-Hinweisen findest du unter MCP-Server.

Das Manifest

Hinter jedem Geltungsbereich steht ein managed manifest — ein JSON-Dokument mit drei Listen. Die Customize-UI bearbeitet es für Sie; über Plugin settings (Zahnrad) → Edit manifest auf dem Plugins-Tab lässt es sich direkt bearbeiten:

{
  "requiredPlugins": ["acme/review-tools"],
  "optionalPlugins": [],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*"]
}

requiredPlugins — für alle im Geltungsbereich installiert (rekursiv, einschließlich aller Plugins, von denen sie abhängen). Beim Installieren über die UI wird hier ein Eintrag hinzugefügt.
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.

Governance

Die drei Listen bilden die Richtliniensprache auf jeder Ebene – Enterprise, Organisation, Repository (.devin/config.json) und persönlich – wobei sich die höhere Ebene durchsetzt: Ein Enterprise kann ein Plugin verpflichtend machen, das keine Organisation, kein Repo und kein Nutzer entfernen kann, und eines verbieten, das keine niedrigere Ebene wieder aktivieren kann. Ein durch eine Richtlinie blockiertes Plugin erscheint im Tab „Plugins“ unter Installed but blocked; seine Skills werden beim Sitzungsstart übersprungen, zusammen mit einer Warnung, die die verbietende Ebene nennt. Um ein Enterprise auf eine freigegebene Auswahl zu beschränken, verbieten Sie "*" und führen Sie die freigegebenen Plugins (und deren Abhängigkeiten) in requiredPlugins/optionalPlugins auf. Ein ausgearbeitetes Beispiel finden Sie unter Setup Ihres Plugin-Ökosystems, die vollständigen Regeln unter Vererbung und Ebenen.

Geltungsbereich und Vererbung

Eigenständige Accounts besitzen ein Account-Manifest (in Customize als Organization bezeichnet) sowie das persönliche Manifest jedes Members.
Enterprises besitzen ein Enterprise-Manifest, das jede untergeordnete Organization erbt, darunter ein Manifest je Organization und darunter die persönlichen Manifeste.

Wie Updates bereitgestellt werden

Manifest-Änderungen (Installationen, Entfernungen, Manifest-Bearbeitungen) gelten ab der nächsten Sitzung, auf jeder Surface.
Änderungen an Plugin-Inhalten — ein Merge in den Branch, den ein Plugin verfolgt, wird automatisch in neue Sitzungen übernommen (Cloud-Sitzungen holen die Inhalte beim Start; die CLI aktualisiert bei devin plugins update). Customize zeigt die neuen Inhalte nach dem nächsten Indexlauf — klicke auf Reindex plugins, um sie sofort abzurufen.
Laufende Sitzungen behalten, was sie beim Start geladen haben — Updates ändern eine Sitzung niemals während der Laufzeit.

Ein Plugin anpinnen

Ein Plugin, das als "owner/repo" (oder mit einem ref) angegeben ist, folgt einem Branch oder Tag, sodass sich dasselbe Manifest im Laufe der Zeit auf unterschiedliche Inhalte beziehen kann. Customize kennzeichnet solche Einträge als Plugin source not pinned. Um ein Plugin auf exakte Inhalte festzulegen, verwenden Sie die Objektform mit einem sha:

{
  "requiredPlugins": [
    { "source": "github", "repo": "acme/review-tools", "sha": "3f2a9c1d8e4b7a6f5c0d1e2f3a4b5c6d7e8f9a0b" }
  ]
}

Ein angepinntes Plugin ändert sich erst, wenn du den SHA bearbeitest. ref (ein Branch oder Tag) und sha schließen sich gegenseitig aus – ein Eintrag kann nicht beides angeben. Dieselben Felder funktionieren auch mit den source-Formen url und git-subdir. Hochgeladene Plugins sind immer an den von dir hochgeladenen Inhalt angepinnt. Wenn zwei Geltungsbereiche dasselbe Plugin auf unterschiedliche SHAs anpinnen, meldet der Index einen Pin-Konflikt.

Plugin-Umgebungsvariablen

Fügen Sie env zu einem Eintrag in requiredPlugins oder optionalPlugins hinzu, um Command-Hooks in Cloud-Sitzungen zu konfigurieren. Verwenden Sie für Anmeldedaten Devin Secrets; andere Werte können als Zeichenfolgenliterale angegeben werden.

{
  "requiredPlugins": [
    {
      "source": "github",
      "repo": "acme/review-tools",
      "env": {
        "API_KEY": "secret:org:REVIEW_API_KEY",
        "REVIEW_MODE": "strict"
      }
    }
  ]
}

Starten Sie eine neue Cloud-Sitzung, um die Änderungen zu übernehmen. Abhängigkeiten benötigen einen eigenen Eintrag im Manifest und env.

Unterstützte Referenzen

secret:org:NAME
secret:enterprise:NAME
secret:personal:NAME
secret:session:NAME
secret:repo:owner/repo:NAME

Das Secret muss für die Sitzung verfügbar sein. Bei einem vorhandenen Schlüssel-Wert-Secret fügen Sie /ENTRY an, zum Beispiel secret:org:AWS_CREDS/ACCESS_KEY_ID. Plugin-MCP-Konfigurationen referenzieren Secrets als ${NAME}; Member liefern die Werte über das Detailfenster des Servers, und literale Werte, die in die Konfiguration geschrieben werden, werden entfernt.

Mehr erfahren

Plugins-Referenz — Plugin-Dateiformat, Manifest, Governance-Semantik, CLI-Befehle
Setup deines Plugin-Ökosystems — eigenes Plugin-Repo aufbauen und verwalten
Quickstart: Team-Marketplace — von null zum gemeinsamen Plugin-Repo
Skills — die SKILL.md-Abläufe, die Plugins bündeln
MCP-Server — Transports, eigene Server, Setup pro Server

Loslegen

Grundlegende Richtlinien

Einführung in Devin

Arbeiten mit Devin

Produktleitfäden

Integrationen

Admin

Versionshinweise

Devin-Plugins und die Customize-Seite

Was sind Plugins?

Die Customize-Seite

Plugins installieren

Aus dem Marketplace

Aus einem Repository, einer `.zip`-Datei oder dem Editor

Über die CLI

Devin die Arbeit überlassen

Wie Plugins zu Sitzungen gelangen (Cloud ↔ lokale Synchronisierung)

Indexing

Indexing-Probleme beheben

MCPs

Das Manifest

Governance

Geltungsbereich und Vererbung

Wie Updates bereitgestellt werden

Ein Plugin anpinnen

Plugin-Umgebungsvariablen

Unterstützte Referenzen

Mehr erfahren

​Was sind Plugins?

​Die Customize-Seite

​Plugins installieren

​Aus dem Marketplace

​Aus einem Repository, einer .zip-Datei oder dem Editor

​Über die CLI

​Devin die Arbeit überlassen

​Wie Plugins zu Sitzungen gelangen (Cloud ↔ lokale Synchronisierung)

​Indexing

​Indexing-Probleme beheben

​MCPs

​Das Manifest

​Governance

​Geltungsbereich und Vererbung

​Wie Updates bereitgestellt werden

​Ein Plugin anpinnen

​Plugin-Umgebungsvariablen

​Unterstützte Referenzen

​Mehr erfahren

Was sind Plugins?

Die Customize-Seite

Plugins installieren

Aus dem Marketplace

Aus einem Repository, einer `.zip`-Datei oder dem Editor

Über die CLI

Devin die Arbeit überlassen

Wie Plugins zu Sitzungen gelangen (Cloud ↔ lokale Synchronisierung)

Indexing

Indexing-Probleme beheben

MCPs

Das Manifest

Governance

Geltungsbereich und Vererbung

Wie Updates bereitgestellt werden

Ein Plugin anpinnen

Plugin-Umgebungsvariablen

Unterstützte Referenzen

Mehr erfahren