claude-code - 💡(How to fix) Fix [FEATURE] Marketplace-level dependencies — declarative `dependentMarketplaces` and/or marketplace lifecycle hooks [1 participants]

Problem / Intent

Marketplaces frequently have meaningful relationships with each other: a "team" marketplace federates with an "organization" marketplace, a domain marketplace builds on a shared-foundations marketplace, etc. Today there is no way for a marketplace author to express "consumers of my marketplace also benefit from these other marketplaces" and have Claude Code surface that to users.

The closest existing primitives don't actually solve this:

• extraKnownMarketplaces in a project's .claude/settings.json fires only on local repo trust. Consumers who use /plugin marketplace add owner/repo never trigger it because they don't clone the marketplace repo locally.
• allowCrossMarketplaceDependenciesOn in marketplace.json is a guard (allowing plugins to depend on plugins from another marketplace), not a trigger — both marketplaces still must already be registered before dependency resolution runs.
• Per-plugin hooks fire after a plugin is installed and on every SessionStart, but they're per-plugin (users who haven't installed the right plugin never see them) and indirect (a plugin doing marketplace-management feels wrong).
• setup.sh convention is purely manual — requires consumers to read README and run a script.

Result: marketplace authors who want to recommend or require companion marketplaces rely on documentation and hope users follow it. Per-plugin federation via git-subdir handles the tightly-coupled case but doesn't help when the companion marketplace is genuinely separate.

Proposed primitive A — dependentMarketplaces (preferred)

Add a declarative field to marketplace.json that lists companion marketplaces, using the same source schema as extraKnownMarketplaces:

{
  "name": "team-tools",
  "owner": { "...": "..." },
  "plugins": [ "..." ],
  "dependentMarketplaces": [
    {
      "name": "shared-foundations",
      "kind": "recommended",
      "source": {
        "source": "github",
        "repo": "your-org/shared-foundations"
      },
      "reason": "team-tools plugins integrate with shared-foundations utilities; many work better when both are registered."
    }
  ]
}

Behavior on /plugin marketplace add team-tools:

• Claude Code parses dependentMarketplaces.
• For each entry, presents a prompt:

  team-tools recommends installing shared-foundations. Reason: (reason text). Add it now? [Y/n]

• kind: "required" makes the prompt non-skippable; kind: "recommended" is opt-in default.
• On /plugin marketplace update, re-evaluate in case the dep list changed.

This is the 80% case, purely declarative — no shell, no scripts, no hooks. Maps cleanly onto the existing extraKnownMarketplaces schema for source resolution.

Proposed primitive B — Marketplace lifecycle hooks (alternative or complement)

Introduce hook events for marketplace lifecycle:

Hooks are defined on marketplace.json at the marketplace level (mirroring how plugin hooks are declared on plugin.json):

{
  "name": "team-tools",
  "hooks": {
    "MarketplaceAdd": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_MARKETPLACE_ROOT}/scripts/post-install.sh"
          }
        ]
      }
    ]
  }
}

Use cases beyond dependentMarketplaces:

• Compatibility check (warn if Claude Code version is too old).
• Telemetry, with user consent.
• One-time data migrations across marketplace updates.
• Custom UX during install (multi-step wizards).

Recommendation

Ship A first — solves the documented use case declaratively with no security surface beyond what extraKnownMarketplaces already has. B can land later as a more general extensibility primitive if/when use cases beyond dependency declaration emerge.

Real-world scenario

I maintain two marketplaces in a federated relationship: a team marketplace and a broader organization marketplace. Per-plugin federation via git-subdir works for individual plugins (one federated, ~60 not). For the rest, every new consumer has to:

1. Run /plugin marketplace add <team-marketplace> — adds the team catalog.
2. Be told via README that they should also /plugin marketplace add <org-marketplace> to access the broader catalog.
3. Manually run that second command.

Step 3 is where adoption breaks. With dependentMarketplaces, the prompt happens automatically and consistently; the step users miss disappears.

Related

• #9444 (plugin-level dependencies) — different scope, related thinking.
• extraKnownMarketplaces in project settings — closest existing mechanism; doesn't apply to consumer-side /plugin marketplace add flow.
• allowCrossMarketplaceDependenciesOn — guard, not trigger; needed alongside this for plugin-dep scenarios.