[ENHANCEMENT] Add `/plugin` command to install ClaudeCode plugins

[ryouka0731]

Problem (one or two sentences)

There is currently no simple way to install and use ClaudeCode plugins within RooCode.
Users must rely on manual or external setup, which increases complexity and friction.

Context (who is affected and when)

This affects developers who want to extend RooCode using ClaudeCode plugins.
It typically occurs when users try to enhance functionality but cannot find a built-in way to integrate plugins.

Desired behavior (conceptual, not technical)

Users should be able to install ClaudeCode plugins easily using a simple command within RooCode.
The process should feel seamless and require minimal manual setup.

Constraints / preferences (optional)

• The command should be lightweight and fast
• Should not disrupt existing workflows
• Ideally consistent with existing CLI/command patterns

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

Given a user is working in RooCode
When they run /plugin install <plugin-name>
Then the specified ClaudeCode plugin is installed and ready to use
And the setup is completed without requiring manual configuration
But the command should not break existing functionality or workflows

Proposed approach (optional)

Introduce a /plugin command namespace that supports install, list, and remove operations for ClaudeCode plugins.

Trade-offs / risks (optional)

• Requires defining a plugin management system
• Potential compatibility issues with different plugins
• Maintenance overhead for plugin ecosystem support

[roomote-v0]

I'd like to help with this issue, but I need some clarification to ensure I implement the right solution. Could you please provide more details on the following:

• What are "ClaudeCode plugins"? Could you point to documentation or examples of what these plugins are, how they're structured, and where they're sourced from? Roo Code doesn't currently have a concept of "ClaudeCode plugins," so understanding the exact plugin format/spec is critical.
• Plugin source/registry: Where would plugins be installed from? A registry (like npm), a GitHub repo, a local directory? What does a plugin look like on disk?
• Plugin capabilities: What would an installed plugin actually do within Roo Code? Would it add new slash commands, modify agent behavior, provide new tools, or something else?
• Relationship to existing extension points: Roo Code already has MCP (Model Context Protocol) servers and custom modes as extension mechanisms. How does this plugin concept relate to or differ from those?
• Prior art: Is this based on a specific feature from Claude Code (Anthropic's CLI tool)? If so, could you link to the relevant documentation?

Without a clearer definition of what "ClaudeCode plugins" are and how they integrate with Roo Code's architecture, it's difficult to propose a concrete implementation plan. The existing MCP server and custom modes infrastructure may already cover some of the use cases you have in mind.

Please tag @roomote in your response with the answers, and I'll be happy to propose an implementation plan once I have this information.

[ryouka0731]

@roomote
Thanks for your thoughtful questions — you're absolutely right that the concept needs to be clarified.

Let me restate the proposal in a more concrete way.

---

1. What are "ClaudeCode plugins"?

At the moment, there is no formal public specification for "ClaudeCode plugins" (so this proposal is somewhat conceptual).

What I meant by "ClaudeCode plugins" is:

Lightweight, installable extensions that enhance the coding workflow powered by LLM agents (like Claude), similar in spirit to CLI plugins or VSCode extensions.

So instead of referring to an existing strict format, this proposal is closer to:

• A plugin system for Roo Code inspired by LLM-driven workflows
• Not necessarily tied to an official Claude Code spec

---

2. Plugin source / registry

This is flexible, but a practical starting point would be:

• GitHub repositories (primary source)
• Optional future registry (like npm-style)

Example:
/plugin install owner/repo

On disk, a plugin could look like:

plugin/
manifest.json
index.ts (or js)
commands/
tools/

---

3. Plugin capabilities

A plugin could extend Roo Code in the following ways:

• Add new slash commands (e.g., /review, /test, /refactor)
• Provide reusable agent workflows
• Register tools/functions callable by the agent
• Inject prompts or templates
• Customize behavior of existing modes

---

4. Relationship to MCP servers and custom modes

Good point — this is where clarification is important.

• MCP servers = external tool providers (runtime integrations)
• Custom modes = predefined agent configurations

Proposed plugin system:

• A higher-level packaging layer that can bundle:
  • MCP integrations
  • custom modes
  • commands
  • prompts

In other words:

Plugins would act as a distribution + installation mechanism on top of existing extension points.

---

5. Prior art

This idea is loosely inspired by:

• VSCode extensions
• npm-based CLI plugins
• emerging patterns in LLM tools (like reusable prompt/tool bundles)

It is not tied to an official Claude Code feature, but rather a direction for improving extensibility and UX in Roo Code.

---

Summary

This proposal is less about integrating an existing "ClaudeCode plugin spec" and more about:

Introducing a simple, unified plugin installation system (/plugin) to package and distribute Roo Code extensions.

---

If this direction makes sense, I'm happy to help refine:

• plugin manifest structure
• install flow
• minimal viable implementation

Let me know your thoughts!

[roomote-v0]

I've seen this comment and explored the codebase to understand how the existing extension points (slash commands, custom modes, MCP servers, skills, marketplace) work together.

Opened a draft PR with my attempt at an MVP plugin system: #11975

What the PR includes:

• Plugin manifest schema (plugin.json) with Zod validation for defining what a plugin bundles
• GitHubSource for fetching plugin manifests and files from repos (supports owner/repo@ref)
• PluginInstaller that handles installing/removing commands, modes, MCP configs, and skills into their standard locations
• PluginManager orchestrating install/remove/list with tracking via plugins.json
• A /plugin built-in command with subcommands: install, remove, list
• 25 unit tests covering the new components

The plugin system acts as a distribution and installation layer on top of the existing extension points, exactly as proposed. Each plugin is a GitHub repo with a plugin.json at its root that declares what it bundles.

Feedback welcome -- this is a starting point and there's room to iterate on the manifest format, add a registry, update mechanisms, and WebView UI.