[FEATURE] Support for Plugin Dependencies and Shared Resources

they already sollved this you can have the resources in the market place root, and then use strict: false, and then the plugin config in the market place can define more granular assignments of command/agents/hooks

I would argue this is a work around, not a solution. In my opinion the solution would use the same @ reference already implemented but be context aware of the marketplace.

they already sollved this you can have the resources in the market place root, and then use strict: false, and then the plugin config in the market place can define more granular assignments of command/agents/hooks

I tested this and, unless I am missing something, You cannot reference things at the market place root from a plugin due to the schema requirement that the plugin paths start with ./. see error below.

/plugin

⎿ Failed to load all marketplaces. Errors: test-marketplace: Invalid schema:
plugins.0.skills.0: Invalid input: must start with "./",

"plugins": [
{
"name": "test",
"source": "./plugins/test",
"description": "test",
"strict": false,
"commands": [
"./hello.md"
],
"skills": [
"../dep.md"
]
},

Edit: I figured out how to reference, it requires raising the source path. It does not work with @ reference but does work with "use skill X". Still feels like a workaround, its not awesome.

thank you @jawhnycooke...I was just about to file a feature request before I found yours

Regarding the dependencies block

The current structure:

"dependencies": {
    "common-core": "^1.0.0",
    "security-core": "^2.1.0"
}

While this follows the familiar npm/PyPI pattern, it assumes a single centralized marketplace. To support multiple Claude Code Marketplaces/Plugins, including private/internal registries, I'd suggest a more flexible structure:

"dependencies": [
    {
        "name": "my-plugin",
        "version": "1.0.0",
        "source": "./plugins/my-plugin"
    },
    {
        "name": "my-other-plugin",
        "version": "1.0.1",
        "source": {
            "type": "git",
            "url": "https://gitlab.com/team/my-other-plugin.git"
        }
    },
]

This approach would:

• Support local file paths for development/internal plugins
• Enable git repositories as dependency sources
• Allow custom registries/marketplaces

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Building on what @smar-sean-sekora suggests, I might also add that local referenced plugins should probably not have a version. I'd probably consider the reference similar to github actions, where references to remote repos can use a tag or sha or branch.

I'd forsee some basic issues here though: when you have dependencies, how do you ensure those dependencies do their thing before you need to (eg hook ordering).

One thing that made me think about this was the potential for a plugin that contains a bunch of supporting rules, and an mcp server that syncs those rules in to the .claude folder for an org to use to sync rules. (the mcp server doesn't do anything, it just uses the execution to kick off the syncing process and potentially watch for updates on long running sessions)

To this end, I wanted to make a plugin that handled the basic ideas of the syncing and mcp server with no rules, and another plugin that depended on that other plugin to sync it's rules.

To help mitigate issues, perhaps plugins should opt in to being used as a dependency by stating in their schema that they take inputs, which then lets the depend-_er_ define the dependency and then pass it's own info to the other plugin.

As I type this, while "dependencies" feels like the right term, the actuality is that this feels a bit more like github actions. Having the following as the schema would enact the above ideas:

"dependencies": [
    {
        "uses": "./plugins/rule-sync"
        "with": {
			"ruleRoot": "./rules" // relative to this plugin
		}
    },
    {
        "uses": "https://gitlab.com/team/my-other-plugin.git@1.0.1"
    },
    {
        "uses": "https://gitlab.com/team/my-other-plugin.git/subpath/to/pluginroot@v1.0.1" // where the .claude-plugin folder lives
    },
    {
        "uses": "githuborg/github-repo" // default to sourcing from github, and from default branch
    },
]

The update to the schema for the plugins that can be depended on could look like:

"depdenencies": [
  {
  	// if this were to be installed rather than depended on, this is where it would define it's inputs
  	// If a plugin defines a reusable block, but doesn't depend on itself, then it doesn't do anything!
    // This ensures plugin use is intentional and won't break due to some things being missing.
    // Probably better to encourage an in-tree plugin that uses the reusable one instead of the
    // reusable one depending on itself?
    "uses": "./"
  }
]
"resusable": {  // presence indicates you can `use` it in another one
  "inputs": {
    "rulesRoot": {
      "type": "path", // so strings are mapped relative to the plugin that sent the input
      "required": true, // if the value isn't passed, this plugin fails to load and claude reports an error
      "default": "./rules", // the value (relative to the USING plugin) to use if not provided
      "mcp": {  // use this value in MCP configs
        "env": { // by setting an env var to expose it
            "RULES_ROOT_DIR": "${{ .value }}"
        }
       },
  	  "hooks": { /* ... */ }, // same as mcp, but expose for hooks
      "env": { // or set globally for things used within this plugin
        "RULES_ROOT_DIR": "${{ .value }}"
      }
    }
  }
}

> they already sollved this you can have the resources in the market place root, and then use strict: false, and then the plugin config in the market place can define more granular assignments of command/agents/hooks I tested this and, unless I am missing something, You cannot reference things at the market place root from a plugin due to the schema requirement that the plugin paths start with ./. see error below. > /plugin > ⎿ Failed to load all marketplaces. Errors: test-marketplace: Invalid schema: > plugins.0.skills.0: Invalid input: must start with "./", `` "plugins": [ { "name": "test", "source": "./plugins/test", "description": "test", "strict": false, "commands": [ "./hello.md" ], "skills": [ "../dep.md" ] }, `` Edit: I figured out how to reference, it requires raising the source path. It does not work with @ reference but does work with "use skill X". Still feels like a workaround, its not awesome.

What if we use a git submodule placed inside the your own plugin folder, then it would look something like:
``
"plugins": [
{
"name": "test",
"source": "./plugins/test",
"description": "test",
"strict": false,
"commands": [
"./hello.md"
],
"skills": [
"./{submodulename}/dep.md"
]
},
``

Then, for updating it is not hard to set an action that auto-update submodules.

Did someone tried a workaround like this? Would that work?

Cross marketplace dependencies feel like an unstoppable pandoras box of complexity, constant bugs, and unpredictable behavior. It's hard to look at the constant problems with npm (and even python, pre-uv) and say "Yes that's a successful pattern we should be duplicating!"

Within a single market place though, seems fine. Would be nice to have some way of sharing resources across plugins within strict mode without resorting to symlinks.

I landed here looking how to require an NPM package of Skills from the WordPress AI project, https://github.com/WordPress/agent-skills from within a Claude Code plugin.

I can see the value in allowing for plugins to have dependencies other than Claude Plugins, as folks create LLM abstracted Skills and Agents as packages.

I feel like @smar-sean-sekora comment above would help achieve this.

My entire organization is avoiding the use of plugins because MCPs are currently not managed as shared resources, which can create a lot of context window waste, especially with large numbers of plugins and MCPs.

Reducing redundancy should at least be rather simple for remotely deployed MCPs, given that the URL can determine redundancy.

I'd love to see this implemented even in minimal form.

+1, I have shared utilities packaged as plugins which I'd love to use as dependencies for other plugins.

+1, this would help here as well.

+1, it would be nice to have a core plugin with skills that other higher level plugins can depend on. This can ofcourse be done manually at the moment, but requires engineers to know the dependency tree and enable/disable other plugins accordingly.

Until the plugin system supports formal dependencies, here are patterns for sharing resources between plugins:
Workaround 1 — Shared skills directory:
Create a shared library as a separate "plugin" that only contains skills:

my-marketplace/
├── plugins/
│   ├── shared-lib/       # Shared resources
│   │   └── skills/
│   │       ├── common-agents/
│   │       │   └── SKILL.md
│   │       └── shared-prompts/
│   │           └── SKILL.md
│   ├── plugin-a/         # Uses shared resources via SKILL.md references
│   │   └── skills/
│   │       └── my-skill/
│   │           └── SKILL.md  # "Use the common-agents skill first"
│   └── plugin-b/

Each plugin references shared skills by name in their SKILL.md instructions.
Workaround 2 — Symlinks for shared files:

mkdir -p ~/.claude/shared-resources/
ln -s ~/.claude/shared-resources/common-agent.md plugins/plugin-a/skills/common/SKILL.md
ln -s ~/.claude/shared-resources/common-agent.md plugins/plugin-b/skills/common/SKILL.md

Workaround 3 — Monorepo-style plugin with multiple skills:
Instead of multiple interdependent plugins, create one plugin with multiple skills:

my-plugin/
└── skills/
    ├── shared-utils/    # Shared utilities
    ├── feature-a/       # Uses shared-utils
    └── feature-b/       # Also uses shared-utils

Skills within the same plugin can reference each other naturally.
Workaround 4 — CLAUDE.md as the dependency resolver:

<!-- CLAUDE.md -->
Plugin loading order:
1. Always load shared-lib skills first
2. plugin-a and plugin-b depend on shared-lib
3. When using plugin-a skills, ensure shared-lib skills are available

This looks to be already documented and available: https://code.claude.com/docs/en/plugin-dependencies.md

Anyone tested it ?

Seems like they added it on apr 28:
https://code.claude.com/docs/en/changelog#2-1-121
https://code.claude.com/docs/en/plugin-dependencies

I haven't tried it yet

I built a small tool: npx @lucassantana/sharekit install <user> pulls a CLAUDE.md + skills from a <user>/sharekit-profile repo, previews a diff, backs up, rollbacks. File-based (no service), so a team keeps one profile repo as the shared source.

Not Anthropic-affiliated, just scratching the same itch

[github.com/LucasSantana-Dev/sharekit](github.com/LucasSantana-Dev/sharekit)