プラグインはクローズドベータ版です。アクセスをリクエストするには、support@cognition.ai までお問い合わせください。動作や設定は今後のリリースで変更される場合があります。
/<plugin>:<skill> スラッシュ
コマンドとして利用できます。
プラグインはインストールの単位です。プラグインをインストールすると、そのすべての
スキルと requiredPlugins もインストールされます。プラグインから個別のスキルをインストールすることはできません。
スキルを個別に提供するには、別々のプラグインに分割してください。
プラグインとは、次の内容を含むソースのことです:
skills/ ディレクトリには通常のスキルが格納されます。プラグインによって新しいスキルの
形式が追加されることはありません。SKILL.md の形式については、Creating Skills を参照してください。
1 つのリポジトリ (または 1 つの git-subdir サブフォルダー) が 1 つのプラグインです。1 つのリポジトリで
複数のプラグインをサブフォルダーとしてホストでき、それぞれを独自の git-subdir ソースで参照できます。
スキルに加えて、プラグインには次のものを含めることができます:
- ルール — プラグインルートにある
AGENTS.mdは、プロジェクト独自のルールとあわせて、すべてのセッションで常時適用 ルールとして読み込まれます。rules/フォルダー内の Markdown ファイルも読み込まれ、 Windsurf rules と同じtriggerfrontmatter と activation types を使用します。 - カスタムサブエージェント —
agents/<name>.mdまたはagents/<name>/AGENT.mdプロファイル (プロジェクトの サブエージェントと同じ custom subagent format) で、<plugin>:<name>として利用できます。現在、プラグインのサブエージェントが読み込まれるのはローカルの Devin エージェント のみ、つまり CLI と Devin Desktop で、cloud Devin セッションでは読み込まれません。 - フック — プラグインルートにある
hooks.jsonは、 プラグインがインストールされているすべての セッションで実行される ライフサイクルフック を登録します。クラウドセッションでは、commandフックは セッションのマシン上で実行され、そのマシンが起動している間のみ実行されます。SessionStartとSessionEndを除く すべてのイベント (PreToolUse、PostToolUse、PermissionRequest、UserPromptSubmit、Stop、PostCompactionを含む) をサポートします。promptタイプのフックは CLI/ローカル専用です。 - MCPサーバー — プラグインルートにある
mcp_config.jsonは、 セッションの開始時に起動する MCPサーバー ("mcpServers": { "<name>": { … } }) を宣言します。プラグインの MCP サーバーはまだ MCP 設定 UI には表示されませんが、そのツールは Devin で利用できます。プラグインの MCP 設定では OAuth クライアント ID と スコープを設定できますが、クライアントシークレットは設定できません。クライアントシークレットを含むサーバー設定は 有効化時に拒否されます。Claude プラグインルート.mcp.jsonとマニフェストのmcpServersフィールドも有効です。
互換形式
.devin-plugin/plugin.json > .claude-plugin/plugin.json > ルートの
plugin.json:
-
Claudeプラグイン —
.devin-plugin/plugin.jsonがない場合、Devinは.claude-plugin/plugin.jsonにフォールバックします。Claudeプラグインでは、ルートの.mcp.jsonと マニフェストのmcpServersフィールドが使用され、サーバー設定内の${CLAUDE_PLUGIN_ROOT}は プラグインルートに展開されます。 -
Agentプラグイン — オープンな
Agent Plugins 1.0.0
仕様 (プラグインルートに
plugin.jsonマニフェスト、ルートのmcp.jsonにMCPサーバー、skills/配下にスキル) に従ってパッケージ化されたプラグインも読み込まれます。これらのプラグインでは、ルートのmcp.jsonは通常のMCPソースとして読み取られます (サーバー名が競合した場合は.mcp.jsonが優先されます) 。レガシーなDevin/Claudeレイアウトのプラグインでは、 マニフェストで明示的に宣言されない限り読み取られません。MCPエントリでは、transportの代わりに仕様のtypeフィールド (stdio、streamable-http、またはsse) でトランスポートを指定でき、サーバー設定内の${PLUGIN_ROOT}は${CLAUDE_PLUGIN_ROOT}と同様にプラグインルートに展開されます。 認識されない$schemaバージョンについては警告が表示されますが、プラグインは可能な限り読み込まれます。 AgentプラグインのMCPサーバーには、仕様で定められたランタイム規約も適用されます (これらは マニフェストがルートのplugin.jsonであるプラグインにのみ適用されます。Devinおよび Claudeレイアウトはこれまでどおり動作します) :args、envの値、cwd内の${PLUGIN_DATA}は、 永続的で書き込み可能なプラグインごとのデータディレクトリに展開されます。このディレクトリは バージョンではなくプラグインIDをキーとするため、その内容はプラグインの更新後も保持され、 プラグインをアンインストールすると削除されます。stdioサーバープロセスは、設定で指定されたenvに加えてPLUGIN_ROOTとPLUGIN_DATA環境変数を受け取ります。- サーバーは
cwd(プラグインルートからの相対パス) を設定できます。デフォルトは プラグインルートです。./で始まるcommandはプラグインルートを基準に解決されるため、 プラグインは独自の実行可能ファイルを同梱できます。どちらもプラグインルートまたはデータディレクトリの 内部に収まるよう検証されます。
プラグインのインストール
owner/repo、git URL、またはローカルパスを指定できます。
-y / --yes を指定します。
プラグインは ユーザー レベルでインストールされ、すべての
プロジェクトで利用できます。
プラグインの管理
devin plugins install ./my-plugin → skills/<name>/SKILL.md を編集 → 変更内容は
次のセッションで反映されるため、update は不要です。
マニフェスト
.devin-plugin/plugin.json はプラグインを定義します。必須なのは name のみで、
インストール済みプラグイン内で一意である必要があります (/<name>:… 名前空間になります) 。
名前は小文字の英数字を単一の - または . で区切った形式です
(例: review-tools、acme.tools)。
name、version、description、author
({ name, email }) 、homepage、repository、license、keywords です。
さらに 2 つのオプション フィールドで、アセットの読み込み元を制御できます。skills はスキル ディレクトリへのパスまたは
パスの配列で、デフォルトの skills/ を置き換えます。mcpServers は
MCP 宣言ファイルのパスまたはインラインのサーバー マップで、ルートの規約とあわせて
読み込まれます。
依存関係のエントリは ソース で、文字列の省略記法またはオブジェクトで指定します。
同じリポジトリを指すすべての GitHub 形式 (
owner/repo、HTTPS URL、.git URL、SSH 形式) は、同じプラグインの識別子として扱われます。
依存関係とガバナンス
requiredPlugins
optionalPlugins
forbiddenPlugins
forbiddenPlugins の各エントリは、プラグインの識別子に対して照合されます。
- 完全一致の識別子。
owner/repoまたは git URL 形式で記述します。同じリポジトリを指す GitHub の各形式 (owner/repo、HTTPS URL、.gitURL、SSH 形式) は、いずれも同じ識別子として扱われます。 - glob パターン —
*を含む任意のエントリです。*は/を含む任意の文字列に一致します。たとえば、acme/*はacmeの GitHub リポジトリすべてに一致し、*/secretsは任意のオーナー配下のsecretsという名前のリポジトリに一致し、https://gitlab.com/acme/*はそのパス配下の任意のリポジトリに一致します。 - 単独の
"*"。これはそれ以外のすべてに一致します (完全なロックダウン) 。
- Deny wins. アクティブなマニフェストまたはインストール済みプラグインのいずれかで禁止されている場合、そのプラグインはブロックされます。何も禁止されていなければ、何もブロックされません。
- Self-override. マニフェスト (またはプラグイン) 自身の
requiredPluginsとoptionalPlugins、およびプラグインの場合はそのプラグイン自身は、その自身の禁止リストの適用対象外です。したがって、"forbiddenPlugins": ["*"]と"optionalPlugins": ["acme/approved"]を組み合わせると、「このマニフェストに列挙されたものだけを許可し、それ以外はすべて禁止する」という意味になります。この例外が適用されるのは、それらの直接のエントリだけであり、required plugin の推移的な依存関係には適用されません。ロックダウン時は、それらも明示的に列挙してください。 - No cross-scope re-permitting. あるマニフェストまたはプラグインの許可リストで、別のマニフェストまたはプラグインが禁止したものを再び許可することはできません。
"forbiddenPlugins": ["*"]によるロックダウンは、より低いスコープからは回避できません。
- Install time — ブロックされたプラグイン (または required plugin の要件を満たせないプラグイン、あるいはインストール済みプラグインと名前が競合するプラグイン) のインストールは拒否されます。
- Load time — プラグインがすでにインストールされた後でブロックされた場合でも、ディスク上には残りますが、そのスキルはセッション開始時にスキップされ、どの禁止元によるものかを示す警告が表示されます。
owner/repo 形式や git URL 形式に加えて、ローカルパス (ローカルフォルダからインストールするプラグイン用) も指定できます。
継承とレベル
- Enterprise — 管理者が設定する、アカウント全体で管理されるマニフェスト。
- Org — accountの下位に重ねられる、orgレベルの管理マニフェスト (orgは accountが宣言した内容に追加できますが、それを上書きすることはできません) 。これは cloud Devin セッションにのみ適用されます。CLIはaccountレベルで認証され、 orgの前提情報を持たないため、orgレベルの必須設定や禁止設定はCLI ユーザーには適用されません。CLIで必ず適用したいものは、enterprise/account マニフェストに記載してください。
- Repo — checkoutの
.devin/config.json内にあるrequiredPlugins/optionalPlugins/forbiddenPluginsで、 作業ディレクトリから上位へたどって検出されます。 - User —
devin plugins installを使って自身でインストールするプラグイン。
- 下位レベルでは、上位レベルで禁止されているものを再び許可することはできません。
- 下位レベルでは、上位レベルで必須とされているものを禁止することはできません — その禁止は 無視され、プラグイン は引き続き読み込まれます。
denylist は定義されたレベルでのみ上書きできます
forbiddenPlugins は、
同じマニフェスト内の optionalPlugins (または
requiredPlugins) によってのみ上書きでき、下位レベルのリストで上書きされることはありません。
たとえば、Enterprise レベルの管理対象マニフェストを使うと、アカウントで利用できる
プラグインを承認済みの 1 つのみに制限できます。
acme/approved のみを許可し、それ以外の
すべてのプラグインを禁止する。“という意味です。org、リポジトリ、user のいずれも、この許可リストを
広げることはできません。プラグインをインストールしても、下位レベルの optionalPlugins に追加しても
同様です。
この例外は、このマニフェストに直接記載されているエントリにしか適用されません。必須
プラグイン自体の推移的依存関係は免除されないため、ロックダウン下ではそれらも
明示的に列挙してください。
競合と依存関係
- 同じプラグインに対する require と 禁止する が同じレベルで、しかも 異なるマニフェスト (たとえば個別にインストールされた 2 つのユーザーレベル プラグイン) から指定されている場合は、禁止する が優先されます。許可リスト が除外できるのは そのマニフェスト自身 のエントリだけなので、別のマニフェストで 禁止する された プラグインを覆すことはできません。 (1 つのマニフェスト内では、そのマニフェスト自身の required / optional は、前述のとおり、そのマニフェスト自身の forbids の 対象外のままです。)
- ガバナンスによってブロックされたプラグインは soft-fails します。セッション開始時に、その スキルは 禁止する を指定した主体を示す警告とともにスキップされ、セッションは中断されません。
- 依存先であることによる除外はありません。推移的依存関係としてのみ取り込まれた プラグインであっても、それに適用されるすべての 禁止する の対象であり続け、さらにそれを require するプラグインのうち、最も高い権限レベルを継承します。

