Devin (Desktop & CLI)

Devin has no dedicated STAR Plugin package. It doesn't need one: Devin's plugin loader reads Claude plugin manifests, so the existing claude-code/ package installs as-is — the same agents and skills, the same Bright MCP server, no edits.

Devin resolves plugin manifests in this order, falling back until one is found:

Because the Bright repository holds one package per tool, you install the claude-code subdirectory rather than the repository root.

Prerequisites

1. Bright plugin requirements — a Bright API token and your cluster hostname, exactly as described in Installation:

   Bash

   export BRIGHT_HOSTNAME="app.brightsec.com"
   export BRIGHT_TOKEN="your-bright-api-token"

   Devin expands ${BRIGHT_HOSTNAME} and ${BRIGHT_TOKEN} from the environment when it loads the plugin's MCP configuration, so the shipped .mcp.json works unchanged. For cloud Devin sessions, supply both as Devin secrets or through your environment blueprint instead of a local shell profile.

2. Devin plugin support enabled on your account — Devin's plugin system is in beta and access-gated. If the Plugins tab in Devin shows "Plugins coming soon", your account doesn't have it yet; request access from Cognition support.

Choose an install route

Route 1: Per project

The quickest route, and the only one that needs no separate CLI login — Devin Desktop installs the plugin using the session it's already authenticated with.

Create .devin/config.json in the repository you want to scan:

{
  "requiredPlugins": [
    {
      "source": "git-subdir",
      "url": "https://github.com/NeuraLegion/bright-ai-plugins.git",
      "path": "claude-code"
    }
  ]
}

Restart Devin. Required plugins install automatically and recursively when the workspace is opened.

📘

.devin/config.json is repository configuration, not a personal setting

If .devin/ isn't in your .gitignore, committing this file enables the plugin for everyone working in the repository. That may be exactly what you want — just make it a deliberate choice.

Route 2: All your projects

Install at the user level so the plugin is available in every project. This covers both the Devin CLI and Devin Desktop, which share one plugin store.

devin auth login
devin plugins install "NeuraLegion/bright-ai-plugins#claude-code"

The #path suffix selects a plugin living below the repository root. Add -y to skip the trust prompt.

📘

If devin isn't on your PATH but you have Devin Desktop installed, the bundled binary ships inside the application — on macOS at /Applications/Devin.app/Contents/Resources/app/extensions/windsurf/devin/bin/devin.

Route 3: Whole organization

An administrator adds one entry to the managed plugin manifest in the Devin web app, under Settings → Resources → Plugins:

{
  "requiredPlugins": [
    {
      "source": "git-subdir",
      "url": "https://github.com/NeuraLegion/bright-ai-plugins.git",
      "path": "claude-code"
    }
  ]
}

Everyone in scope gets the plugin with no per-user setup. Pick the scope deliberately: the enterprise/account manifest reaches cloud sessions, the CLI, and Devin Desktop, while an org manifest reaches cloud sessions only — the CLI authenticates at account level and has no org context.

Verify the installation

Open a folder in Devin Desktop, then click Open Customizations in the header of the Devin panel. The Devin Local page lists what the plugin contributed:

Plugins → Available lists plugins offered to the workspace but not installed. You can't type an arbitrary source into this page — a plugin has to be declared by one of the three routes above.

Using it in Devin

Devin loads the orchestration agents as subagents and the building-block skills as skills. They're invoked differently.

Skills — slash commands

Skills are namespaced by plugin name. Type / in the chat input to browse them:

/bright-security:run-scan
/bright-security:setup-auth
/bright-security:register-entrypoints

Devin also calls them on its own when they're relevant. A skill run shows up in the step stream as Invoked skill: <name>.

Agents — name the subagent

Subagents have no slash command. Ask for one by name and Devin spawns it:

Scan this application with the bright-security:bright-application-testing subagent,
Bright project "acme-api"

Run bright-security:bright-remediation-loop on this repository.
Redeploy with `make deploy-dev`.

The subagent works in its own context window; the main session waits and then summarizes the result. Look for Ran task subagent: … in the step stream — that confirms the profile was actually spawned rather than your request being read as an ordinary instruction.

Every scenario in Usage & Examples applies here; just address the agents with their namespaced subagent names.

Surface limitations

Devin runs the plugin across three surfaces, and they don't all support the same components.

⚠️

In cloud Devin sessions the orchestration agents don't load

Plugin subagents run in local Devin agents only — Devin Desktop and the CLI. A cloud session gets the skills and the MCP server, but not bright-application-testing or bright-remediation-loop. Run the full workflows locally, or drive the skills individually in the cloud.

Two more things worth knowing before you rely on the remediation loop:

• Subagents pick their own model. A custom subagent runs on Devin's default subagent model, not the model driving your session, unless its profile pins one. bright-remediation-loop edits code, so if you want it on your primary model, add a model: field to the agent definition.
• Custom subagents are experimental in Devin, so their format and behavior may change between releases.

Update and uninstall

Troubleshooting

Reference

• Devin plugins reference — manifest format, install flows, governance
• Devin plugin marketplace — managed manifests and scopes
• Devin subagents — how subagent profiles are selected
• Agents & Skills — what each agent and skill does
• Usage & Examples — scanning scenarios and example prompts