Feature: Declarative skill/plugin dependencies at the project level
Summary
Projects should be able to declare which skills and plugins they depend on, with Claude Code prompting users to install missing dependencies when they open a project — similar to how package.json declares npm dependencies.
Problem
Today, teams can create shared skills via plugin marketplaces and provision skills org-wide, but there's no way for a project to declare "this repo requires plugins X and Y." This creates several issues:
- No install prompting: When a new team member clones a repo, there's no signal that they're missing required skills/plugins. They discover gaps only when they try to use a capability that isn't there.
- No required vs. recommended distinction:
.claude/settings.jsoncan specifyenabledPlugins, but if those plugins aren't installed, nothing happens — no warning, no prompt. - Skill sprawl in large orgs: A marketplace can accumulate many plugins with no way for individual projects to say "these are the ones that matter here."
- Workarounds are fragile: Teams resort to documenting required plugins in CLAUDE.md (which Claude reads but can't act on programmatically) or using git submodules for shared skills (which are cumbersome).
Proposed solution
A declarative dependency block in .claude/settings.json (or a dedicated manifest) that Claude Code resolves on project open:
{
"dependencies": {
"required": [
"brand-voice@company-tools",
"deployment-tools@company-tools"
],
"recommended": [
"extension-capture@company-tools"
]
},
"extraKnownMarketplaces": {
"company-tools": {
"source": { "source": "github", "repo": "company/claude-plugins" }
}
}
}
Behavior on project open:
- If any
requiredplugins are missing → prompt user to install them (similar to the trust prompt) - If any
recommendedplugins are missing → inform the user once, allow dismissal - If all dependencies are satisfied → no prompt
Additional considerations:
- Version pinning (e.g.,
"brand-voice@company-tools": "^1.2.0") - A CLI command to reconcile (
claude plugins reconcileor similar) - Integration with org-level plugin provisioning (org-provisioned plugins could auto-satisfy project requirements)
Use case
I'm a CEO of a small company. We've built several Claude Code skills (brand voice, extension capture, deployment tools) and distribute them via a private GitHub marketplace. Different projects need different subsets of these skills. Today there's no way for a project to declare its dependencies, so onboarding a new team member means manually telling them which plugins to install for which repos. A declarative manifest would make this self-service.
Alternatives considered
- CLAUDE.md documentation: Claude reads it and can nudge users, but it's not programmatic — no install flow, no version checking
- Git submodules for
.claude/skills/: Skills auto-discover, but submodules are painful to manage and don't work for plugins that bundle MCP servers or hooks - Org-wide provisioning: Works for universal skills but can't express per-project requirements
- A "setup" skill: A bootstrapping skill that walks users through installation — functional but manual
Related
This builds on the existing plugin marketplace system and enabledPlugins in .claude/settings.json. The infrastructure is mostly there — what's missing is the "resolve and prompt" step.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗