Plugins

Plugins sind in der geschlossenen Beta. Um Zugang anzufordern, kontaktieren Sie support@cognition.ai. Verhalten und Konfiguration können sich in zukünftigen Releases ändern.

Ein Plugin ist ein Bündel von Skills und optionalen Regeln, Hooks, MCP-Servern oder benutzerdefinierten Subagenten, das Sie aus einem GitHub-Repo, einer Git-URL, einem Unterordner eines Repo oder einem lokalen Ordner installieren können. Plugins funktionieren in Devin Cloud-Sitzungen, der Devin CLI und Devin Desktop, vorbehaltlich der unten beschriebenen oberflächenspezifischen Einschränkungen. Beim Installieren eines Plugins werden seine Skills als /<plugin>:<skill>-Slash- Befehle verfügbar. Das Plugin ist die Installationseinheit. Beim Installieren eines Plugins werden alle seine Skills und seine requiredPlugins installiert; Sie können keine einzelnen Skills aus einem Plugin installieren. Um Skills separat anzubieten, teilen Sie sie in separate Plugins auf. Ein Plugin ist einfach eine Quelle, die Folgendes enthält:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # The plugin manifest
├── AGENTS.md           # Optional always-on rule
├── rules/              # Optional triggered rules
├── agents/
│   └── reviewer.md     # Optionaler benutzerdefinierter Subagent (reviewer/AGENT.md funktioniert auch)
├── hooks.json          # Optional lifecycle hooks
├── mcp_config.json     # Optional MCP servers
└── skills/
    └── review/
        └── SKILL.md    # An ordinary skill

Das skills/-Verzeichnis enthält normale Skills — Plugins bringen kein neues Skill- Format mit. Das Format von SKILL.md wird unter Skills erstellen beschrieben. Ein Repo (oder ein git-subdir-Unterordner) entspricht einem Plugin. Ein einzelnes Repo kann viele Plugins als Unterordner enthalten, die jeweils mit einer eigenen git-subdir-Quelle referenziert werden. Über Skills hinaus kann ein Plugin Folgendes mitliefern:

Regeln — eine AGENTS.md im Plugin-Stammverzeichnis wird in jeder Sitzung zusammen mit den eigenen Regeln Ihres Projekts als immer aktive Regel eingefügt. Markdown-Dateien in einem rules/-Ordner werden ebenfalls geladen, mit demselben trigger-Frontmatter und denselben Aktivierungstypen wie Windsurf-Regeln.
Benutzerdefinierte Subagenten — agents/<name>.md oder agents/<name>/AGENT.md-Profile (dasselbe Format für benutzerdefinierte Subagenten wie Projekt- Subagenten), verfügbar als <plugin>:<name>. Plugin-Subagenten werden derzeit nur in lokalen Devin-Agenten geladen — in der CLI und in Devin Desktop — nicht in Cloud-Devin-Sitzungen.
Hooks — eine hooks.json im Plugin-Stammverzeichnis registriert Lifecycle-Hooks, die in jeder Sitzung ausgeführt werden, in der das Plugin installiert ist. In Cloud-Sitzungen werden command-Hooks auf der Maschine der Sitzung ausgeführt und nur ausgelöst, solange diese Maschine läuft. Sie unterstützen jedes Ereignis außer SessionStart und SessionEnd — einschließlich PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop und PostCompaction; Hooks vom Typ prompt sind nur in der CLI bzw. lokal verfügbar.
MCP-Server — eine mcp_config.json im Plugin-Stammverzeichnis deklariert MCP-Server ("mcpServers": { "<name>": { … } }), die mit der Sitzung starten. Plugin-MCP- Server werden noch nicht in der MCP-Settings-UI angezeigt, aber ihre Tools sind für Devin verfügbar. Eine Plugin-MCP-Konfiguration kann eine OAuth-Client-ID und Scopes festlegen, aber niemals ein Client Secret — eine Serverkonfiguration, die eines enthält, wird bei der Aktivierung abgelehnt. Die .mcp.json im Plugin-Stammverzeichnis von Claude-Plugins und das mcpServers-Feld im Manifest werden ebenfalls berücksichtigt.

Kompatible Formate

Der obige Aufbau ist Devins eigenes Plugin-Format. Devin lädt auch Plugins, die in zwei weiteren Strukturen paketiert sind, mit folgendem Manifest-Vorrang: .devin-plugin/plugin.json > .claude-plugin/plugin.json > plugin.json im Stammverzeichnis:

Claude-Plugins — wenn keine .devin-plugin/plugin.json vorhanden ist, greift Devin auf .claude-plugin/plugin.json zurück. Die .mcp.json im Stammverzeichnis und das Manifestfeld mcpServers von Claude-Plugins werden berücksichtigt, und ${CLAUDE_PLUGIN_ROOT} in Serverkonfigurationen wird zum Plugin-Stammverzeichnis aufgelöst.
Agent Plugins — Plugins, die gemäß der offenen Agent Plugins 1.0.0 Spezifikation paketiert sind (ein plugin.json-Manifest im Plugin-Stammverzeichnis, MCP-Server in einer mcp.json im Stammverzeichnis, Skills unter skills/), werden ebenfalls geladen. Für diese Plugins wird die mcp.json im Stammverzeichnis als konventionelle MCP-Quelle gelesen (nach .mcp.json, die bei einer Kollision von Servernamen Vorrang hat) — Legacy-Plugins im Devin-/Claude-Aufbau lesen sie nur, wenn ihr Manifest sie ausdrücklich deklariert. MCP-Einträge können ihren Transport über das type-Feld der Spezifikation (stdio, streamable-http oder sse) statt über transport angeben, und ${PLUGIN_ROOT} in Serverkonfigurationen wird wie ${CLAUDE_PLUGIN_ROOT} zum Plugin-Stammverzeichnis aufgelöst. Bei einer nicht erkannten $schema-Version wird eine Warnung ausgegeben, und das Plugin wird dennoch bestmöglich geladen. MCP-Server von Agent Plugins erhalten außerdem die Runtime-Konventionen der Spezifikation (diese gelten nur für Plugins, deren Manifest die plugin.json im Stammverzeichnis ist; Devin- und Claude-Aufbauten verhalten sich genau wie zuvor):
- ${PLUGIN_DATA} in args, env-Werten und cwd wird zu einem persistenten, beschreibbaren Datenverzeichnis pro Plugin aufgelöst. Das Verzeichnis ist über die Plugin-Identität — nicht die Version — bestimmt, sodass sein Inhalt Plugin-Updates überdauert, und wird gelöscht, wenn das Plugin deinstalliert wird.
- stdio-Serverprozesse erhalten die Umgebungsvariablen PLUGIN_ROOT und PLUGIN_DATA zusätzlich zu allen env-Werten, die in der Konfiguration festgelegt sind.
- Ein Server kann cwd festlegen (relativ zum Plugin-Stammverzeichnis); standardmäßig ist dies das Plugin-Stammverzeichnis. Ein mit ./ beginnender command wird relativ zum Plugin-Stammverzeichnis aufgelöst, sodass Plugins ihre eigenen ausführbaren Dateien mitliefern können. Beide werden darauf geprüft, innerhalb des Plugin-Stammverzeichnisses oder Datenverzeichnisses zu bleiben.

Ein Plugin installieren

Als Plugin-Quelle sind ein GitHub-owner/repo, eine Git-URL oder ein lokaler Pfad möglich:

# Von GitHub
devin plugins install acme/review-tools

# Von einem beliebigen Git-Host
devin plugins install https://gitlab.com/acme/review-tools.git

# Aus einem lokalen Ordner (ideal zum Entwickeln)
devin plugins install ./my-plugin

Vor der Installation zeigt Devin an, was das Plugin hinzufügt — welche Skills es bereitstellt, welche erforderlichen Plugins automatisch installiert werden und welche Richtlinie es einführt (zum Beispiel, wenn es andere Plugins verbietet). Übergeben Sie -y / --yes, um die Abfrage zu überspringen. Plugins werden auf Nutzer-Ebene installiert und sind in all Ihren Projekten verfügbar.

Plugins verwalten

# Installierte Plugins, ihre Versionen und ob welche durch eine Richtlinie blockiert sind, auflisten
devin plugins list

# Skills eines Plugins sowie seine Pflicht-/optionalen/verbotenen Listen anzeigen
devin plugins info review-tools

# Ein Plugin (oder alle Plugins) in der neuesten Version erneut abrufen
devin plugins update review-tools
devin plugins update

# Ein Plugin entfernen (automatisch installierte Pflicht-Plugins bleiben erhalten)
devin plugins remove review-tools

Lokale Plugins sind direkt mit ihrem Quellordner verknüpft, daher sind Änderungen sofort wirksam: devin plugins install ./my-plugin → skills/<name>/SKILL.md bearbeiten → Änderungen werden in der nächsten Sitzung übernommen, kein update erforderlich.

Das Manifest

.devin-plugin/plugin.json beschreibt das Plugin. Nur name ist erforderlich; der Wert muss unter den installierten Plugins eindeutig sein (er bildet den Namespace /<name>:…). Namen bestehen aus alphanumerischen Kleinbuchstaben mit einzelnen -- oder .-Trennzeichen (z. B. review-tools, acme.tools).

{
  "name": "review-tools",
  "version": "1.0.0",
  "description": "Code-review skills for our team",
  "requiredPlugins": [
    "acme/secure-base",
    { "source": "github", "repo": "acme/audit-logging" }
  ],
  "optionalPlugins": [
    "acme/deploy-tools",
    { "source": "url", "url": "https://gitlab.com/acme/extra.git" }
  ],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"]
}

Unterstützte Metadatenfelder: name, version, description, author ({ name, email }), homepage, repository, license und keywords. Zwei weitere optionale Felder steuern, wo Assets geladen werden: skills — ein Pfad oder ein Array von Pfaden zu Skill-Verzeichnissen, das den Standard skills/ ersetzt — und mcpServers — Pfade zu MCP-Deklarationsdateien oder eine Inline-Serverzuordnung, die zusätzlich zu den Konventionen im Stammverzeichnis eingelesen wird. Ein Eintrag für eine Abhängigkeit ist eine Quelle – entweder eine Kurzschreibweise 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.

Abhängigkeiten und Governance

Ein Plugin kann drei Listen definieren, sodass ein einzelnes Plugin als kuratierte, verwaltete Sammlung anderer Plugins dienen kann.

`requiredPlugins`

Wird automatisch (rekursiv) mitinstalliert, wenn das Plugin installiert wird. Wenn ein erforderliches Plugin durch eine Richtlinie blockiert wird, schlägt die gesamte Installation fehl — eine Teilinstallation ist nicht möglich.

`optionalPlugins`

Eine Allowlist von Plugins, die von diesem Plugin ausdrücklich erlaubt werden. Sie werden nicht automatisch installiert; die Liste ist nur als Ausnahme für einen verbotenen Eintrag relevant (siehe unten).

`forbiddenPlugins`

Eine Verbotsliste von Plugin-Identitäten und Glob-Mustern. 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.

Eine verbotene Identität kann neben den oben genannten Formen owner/repo und Git-URL auch ein lokaler Pfad sein (für Plugins, die aus einem lokalen Ordner installiert werden).

Vererbung und Ebenen

Plugins werden nicht an einer einzigen Stelle deklariert. Zusätzlich zu Ihren eigenen Installationen können Plugins von Ihrem Repo und vom Admin Ihrer Organisation vorgeschrieben, empfohlen oder verboten werden. Jede Quelle ist eine Ebene, und die Ebenen sind nach Autorität geordnet, mit der höchsten zuerst:

Enterprise — das kontoweit verwaltete Manifest, das von einem Admin konfiguriert wird.
Org — ein auf Organisationsebene verwaltetes Manifest, das unterhalb des zugehörigen Kontos liegt (eine Org kann ergänzen, was ihr Konto deklariert, es aber nicht außer Kraft setzen). Das gilt nur für Cloud-Devin-Sitzungen: Die CLI authentifiziert sich auf Kontoebene und hat keinen Org-Kontext, daher gelten Anforderungen und Verbote auf Organisationsebene nicht für CLI-Nutzer. Alles, was in der CLI erzwungen werden soll, muss im Enterprise-/Kontomanifest stehen.
Repo — die requiredPlugins / optionalPlugins / forbiddenPlugins in der .devin/config.json eines Checkouts, die ermittelt werden, indem vom Arbeitsverzeichnis aus nach oben traversiert wird.
User — Plugins, die Sie selbst mit devin plugins install installieren.

Jede Ebene deklariert dieselben drei Listen, und innerhalb einer Ebene werden sie nach denselben Deny-wins-, Self-override-Regeln wie ein einzelnes Manifest zusammengeführt. Zusätzlich kommt über die Ebenen hinweg eine Regel hinzu: Die höhere Autorität setzt sich durch.

Höhere Autorität setzt sich durch

Eine niedrigere Ebene kann niemals wieder erlauben, was eine höhere Ebene verbietet.
Eine niedrigere Ebene kann niemals verbieten, was eine höhere Ebene verlangt — das Verbot wird ignoriert und das Plugin wird trotzdem geladen.

So kann ein Admin ein Plugin vorschreiben, das kein Repo und kein Nutzer abwählen kann, und ein Plugin verbieten, das keine niedrigere Ebene wieder zulassen kann.

Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

Da Allowlists keine Ebenen überschreiten, besteht die einzige Möglichkeit, eine Ausnahme von einer Denylist zu machen, darin, dies auf derselben Ebene zu tun, auf der sie festgelegt wurde. Das forbiddenPlugins einer Ebene wird nur durch die eigenen optionalPlugins (oder requiredPlugins) desselben Manifests überschrieben — niemals durch eine Liste auf einer niedrigeren Ebene. Zum Beispiel kann ein auf Enterprise-Ebene verwaltetes Manifest das Konto auf ein einziges genehmigtes Plugin beschränken:

// Verwaltetes Manifest auf Unternehmensebene
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

Das bedeutet “im gesamten Konto nur acme/approved zuzulassen und jedes andere Plugin zu verbieten.” Keine Org, kein Repo und kein Nutzer kann diese Allowlist erweitern — weder durch die Installation eines Plugins noch durch das Hinzufügen zu den optionalPlugins einer niedrigeren Ebene. Diese Ausnahme gilt außerdem nur für die Einträge, die dieses Manifest direkt aufführt; die eigenen transitiven Abhängigkeiten eines erforderlichen Plugins sind nicht ausgenommen und müssen bei einem Lockdown daher ausdrücklich mit aufgeführt werden.

Konflikte und Abhängigkeiten

Ein require und ein forbid für dasselbe Plugin auf derselben Ebene, aber aus verschiedenen Manifesten (zum Beispiel zwei separat installierte Plugins auf Nutzer-Ebene), führen dazu, dass sich das forbid durchsetzt — eine Allowlist nimmt nur Einträge im eigenen Manifest aus, sie kann also kein Plugin retten, das ein anderes Manifest verbietet. (Innerhalb eines einzelnen Manifests bleiben dessen eigene required/optional von dessen eigenen forbids ausgenommen, wie oben.)
Ein durch Governance blockiertes Plugin scheitert weich: Zu Sitzungsbeginn werden seine Skills mit einer Warnung übersprungen, die nennt, wer das forbid gesetzt hat, statt die Sitzung abzubrechen.
Eine Abhängigkeit von ihm gewährt keine Ausnahme. Ein Plugin, das nur als transitive Abhängigkeit eingebunden wird, unterliegt weiterhin jedem forbid, das auf es zutrifft, und es übernimmt die höchste Autoritätsebene aller Plugins, die es voraussetzen.

Erste Schritte

Editor-Integrationen

Erweiterbarkeit

Enterprise

Referenz

Changelog

Kompatible Formate

Ein Plugin installieren

Plugins verwalten

Das Manifest

Abhängigkeiten und Governance

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Vererbung und Ebenen

Höhere Autorität setzt sich durch

Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

Konflikte und Abhängigkeiten

​Kompatible Formate

​Ein Plugin installieren

​Plugins verwalten

​Das Manifest

​Abhängigkeiten und Governance

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​Vererbung und Ebenen

​Höhere Autorität setzt sich durch

​Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

​Konflikte und Abhängigkeiten

Kompatible Formate

Ein Plugin installieren

Plugins verwalten

Das Manifest

Abhängigkeiten und Governance

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Vererbung und Ebenen

Höhere Autorität setzt sich durch

Eine Denylist wird nur auf ihrer eigenen Ebene überschrieben

Konflikte und Abhängigkeiten