“Plugin Dependencies / Plugin Composition”

Feature Requests
1

Problem

Currently, a plugin cannot directly contain or bundle another plugin as one of its internal components.

This becomes limiting when building a larger plugin composed of specialized sub-plugins. For example, a main orchestration plugin such as PRIME may want to include another reusable plugin such as Caveman without converting the entire sub-plugin into a simple skill or duplicating its files and logic.

Without nested plugin support, developers may need to:

  • Copy functionality between plugins.

  • Convert full plugins into skills even when they have their own skills, agents, commands, hooks, configuration, or resources.

  • Maintain duplicate code across multiple plugins.

  • Ask users to install several dependent plugins separately.

  • Manually coordinate plugin dependencies.

Solution

Add support for nested plugins, plugin dependencies, or plugin composition, allowing one plugin to declare and use other plugins as internal dependencies.

For example:

prime-method/
├── plugin.json
├── skills/
├── agents/
├── commands/
└── plugins/
    └── caveman/
        ├── plugin.json
        ├── skills/
        ├── agents/
        └── commands/

Alternatively, the parent plugin could declare dependencies in its manifest:

{
  "name": "prime-method",
  "plugins": [
    {
      "name": "caveman",
      "source": "./plugins/caveman"
    }
  ]
}

The platform should automatically discover and register the nested plugin when the parent plugin is loaded.

Ideally, nested plugins should preserve their own:

  • Skills

  • Agents

  • Commands

  • Hooks

  • Configuration

  • Resources

  • Documentation

  • Internal routing behavior

The parent plugin should also be able to invoke or route work to the child plugin while keeping clear namespace and dependency boundaries.

For example:

/prime
/prime:caveman

or internally:

PRIME → Caveman plugin → Caveman skill/agent

There should also be safeguards for:

  • Circular plugin dependencies

  • Command or skill naming conflicts

  • Version compatibility

  • Dependency loading order

  • Duplicate plugin loading

  • Namespace isolation

Use Case

This would be useful for building larger modular AI-agent systems where one plugin acts as an orchestrator and several smaller plugins provide specialized capabilities.

Example:

PRIME Plugin
│
├── Frontend capabilities
├── Backend capabilities
├── Testing capabilities
├── Documentation capabilities
│
└── Nested Plugins
    ├── Caveman
    ├── Ultrareview
    └── Other specialized plugins

Instead of merging all of these plugins into one large codebase, each component could remain independently developed, tested, versioned, and maintained.

This would also allow developers to create reusable plugins that can function both independently and as components of larger plugin ecosystems.

Priority

:yellow_circle: Medium - Important improvement

This is not necessarily blocking basic plugin development, but it would significantly improve plugin modularity, reusability, dependency management, and architecture for advanced plugin systems.

Additional Info

Comparable concepts already exist in software ecosystems:

  • npm package dependencies

  • Python package dependencies

  • VS Code extension dependencies

  • Composer packages

  • Gradle/Maven modules

  • Plugin-to-plugin dependencies in other extensible platforms

The goal is essentially to support composition instead of duplication:

Plugin A
   ↓ depends on
Plugin B
   ↓ depends on
Plugin C

while allowing each plugin to remain an independent, reusable unit.