> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up your plugin ecosystem

> Build, host, and govern a shared set of Devin plugins for your whole org or enterprise

<Note>
  Plugins are in **closed beta**. To request access, contact [support@cognition.ai](mailto:support@cognition.ai). Behavior and configuration may change in future releases.
</Note>

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**](https://github.com/CognitionAI/plugin-template) — a starter for authoring a single plugin (or a couple of them).
* [**team-marketplace-template**](https://github.com/CognitionAI/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](https://github.com/CognitionAI/plugin-template) to start, and see the [CLI plugins reference](/cli/extensibility/plugins/overview) 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](/cli/index):

```bash theme={null}
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](https://github.com/CognitionAI/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:

```jsonc theme={null}
// .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](https://app.devin.ai/settings/marketplace) — see the [Plugin marketplace guide](/product-guides/plugins):

```json theme={null}
{
  "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:

```json theme={null}
{
  "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](/product-guides/plugins#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](/product-guides/plugins#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](/cli/index), 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](/cli/extensibility/hooks/lifecycle-hooks) 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](/product-guides/plugins) — the web app side: manifests, scopes, uploads
* [CLI plugins reference](/cli/extensibility/plugins/overview) — file format, authoring, per-user installs
* [Skills](/product-guides/skills) — the `SKILL.md` procedures plugins bundle