Set up your plugin ecosystem

Plugins are in closed beta. To request access, contact support@cognition.ai. Behavior and configuration may change in future releases.

This guide walks through standing up your own plugin ecosystem: a repo of plugins your organization owns, distributed to every Devin session and CLI user through a managed manifest, with required, optional, and forbidden plugins as the governance controls. Two template repos accompany this guide:

plugin-template — a starter for authoring a single plugin (or a couple of them).
team-marketplace-template — the full ecosystem pattern: a monorepo of plugins plus a meta-plugin whose manifest defines your baseline and policy.

1. Author your plugins

A plugin is a directory with a .devin-plugin/plugin.json manifest; everything else is optional:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, dependency + policy lists
├── AGENTS.md           # always-on rule
├── rules/              # triggered rules
├── agents/<name>.md   # custom subagents (CLI/Desktop-only today); agents/<name>/AGENT.md also works
├── hooks.json          # lifecycle hooks
├── mcp_config.json     # MCP servers
└── skills/<name>/SKILL.md   # skills, exposed as /<plugin>:<skill>

Fork plugin-template to start, and see the CLI plugins reference for the full format. Keep AGENTS.md short — it costs context in every session for everyone who has the plugin.

2. Validate and test locally

Both templates ship a validator (node scripts/validate-template.mjs) and a CI workflow that runs it on every PR. For a live test, install from a local folder with the Devin CLI:

devin plugins install ./plugins/my-plugin   # linked: edits apply on the next session
devin plugins list

3. Host them in one repo

Put all of your org’s plugins in a single repo as subfolders (plugins/<name>/), each referenced with its own git-subdir source. The repo can stay private: cloud sessions fetch it through your Git integration, and CLI users fetch with their own git credentials (so they need repo access too). Fork team-marketplace-template for this layout — and update its meta-plugin’s git-subdir URLs to point at your fork. In the template the meta-plugin lives at the repo root, so the repo itself is the installable unit: requiring your-org/your-marketplace installs the whole baseline.

4. Define your baseline with a meta-plugin

The meta-plugin pattern turns your whole ecosystem into one installable unit. It’s a plugin with little or no content of its own — its manifest does the work. Put it at the repo root so the repo itself is the meta-plugin:

// .devin-plugin/plugin.json (repo root)
{
  "name": "team-starter-pack",
  "requiredPlugins": [
    // auto-installed for everyone, recursively
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    // endorsed, not auto-installed; also a carve-out from this manifest's forbids
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ],
  "forbiddenPlugins": [
    "untrusted-vendor/*"
  ]
}

5. Distribute from Settings → Marketplace

An admin adds one entry to the managed manifest on the Marketplace settings page — see the Plugin marketplace guide:

{
  "requiredPlugins": ["acme/plugins"]
}

Requiring the marketplace repo installs its root meta-plugin, which pulls in the whole baseline recursively. Everyone in scope now gets the baseline automatically. Pick the scope deliberately:

The enterprise/account manifest reaches cloud sessions and CLI users logged into the account.
The org manifest reaches cloud sessions only — the CLI has no org context.

6. Govern

The three lists are the policy language, at every level (managed manifests, repo config, plugin manifests). Higher authority wins — enterprise/account over org over repo over user — and a lower level can never re-permit what a higher level forbids, nor forbid what it requires. To lock an account down to an approved set only:

{
  "forbiddenPlugins": ["*"],
  "requiredPlugins": [
    "acme/plugins",
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ]
}

The manifest’s own required/optional entries are exempt from its own "*" forbid; nothing else is, and no lower level can widen the carve-out. The exemption covers only directly listed entries — a required plugin’s transitive dependencies aren’t exempt — so under a lockdown, list everything the meta-plugin pulls in (here engineering-baseline and security-guardrails) explicitly. See governance rules for the full semantics.

7. Evolve

Merging to your plugin repo’s default branch is the release: new sessions pick it up automatically — see how updates roll out.
Teams add plugins by PR to the marketplace repo; the template’s CI validates the layout on every PR.
Existing Claude plugins install as-is (Devin falls back to .claude-plugin/plugin.json), so you can endorse community plugins in optionalPlugins without vendoring them.

Current limitations

Plugins load in cloud sessions, the Devin CLI, and Devin Desktop (when using Devin Local); they do not apply to the classic Cascade agent.
Subagents (agents/<name>.md or agents/<name>/AGENT.md) load in local Devin agents only (CLI and Devin Desktop), not in cloud sessions.
Hooks: cloud sessions run command hooks for every event except SessionStart and SessionEnd; prompt-type hooks are CLI/local-only.
Plugin-served MCP loads in-session but doesn’t yet appear in the MCP settings UI.
Org-level manifests don’t reach CLI users; use the enterprise/account manifest for CLI enforcement.

Learn more

Plugin marketplace — the web app side: manifests, scopes, uploads
CLI plugins reference — file format, authoring, per-user installs
Skills — the SKILL.md procedures plugins bundle

Get Started

Essential Guidelines

Onboarding Devin

Working with Devin

Product Guides

Integrations

Admin

Release Notes

Set up your plugin ecosystem

1. Author your plugins

2. Validate and test locally

3. Host them in one repo

4. Define your baseline with a meta-plugin

5. Distribute from Settings → Marketplace

6. Govern

7. Evolve

Current limitations

Learn more

​1. Author your plugins

​2. Validate and test locally

​3. Host them in one repo

​4. Define your baseline with a meta-plugin

​5. Distribute from Settings → Marketplace

​6. Govern

​7. Evolve

​Current limitations

​Learn more

1. Author your plugins

2. Validate and test locally

3. Host them in one repo

4. Define your baseline with a meta-plugin

5. Distribute from Settings → Marketplace

6. Govern

7. Evolve

Current limitations

Learn more