Project-scope plugin auto-discovery from <cwd>/.claude/plugins/*/

Summary

Support auto-discovery of project-scope plugins in <cwd>/.claude/plugins/*/plugin.json, without requiring a marketplace wrapping. Equivalent semantics to running claude plugin install <path> --scope project implicitly when the directory exists at startup.

Use case

Tools like claude-devkit generate filtered plugin views per-repo (a subset of skills/commands/agents from upstream plugins, plus the consuming repo's own assets). With CC 2.x's current model, this requires:

1. Generate the view as a directory tree.
2. Generate a wrapping marketplace.json that lists the view as a plugin.
3. Run claude plugin marketplace add + install + update per regeneration, re-stamping a content-hash version into the marketplace.json so CC re-caches.

If CC auto-discovered <cwd>/.claude/plugins/<name>/plugin.json directly, devkit (and similar tools) could write the view and stop — no marketplace plumbing, no content-hash dance.

Suggested behavior

• On CC startup (or workspace-open), scan <cwd>/.claude/plugins/*/plugin.json.
• For each match, load the plugin in-place from that directory (no copy to cache).
• Behave equivalent to claude plugin install --scope project for discovery, load order, and claude plugin list output.
• File-watch the directory: hot-reload on change.

Migration path for tool authors

A tool that ships wrapping marketplaces today can detect CC version ≥ X (the one with auto-discovery) and skip the wrapping plumbing. Backwards-compat path stays trivial.

Why not just symlinks / hot-reload the current cache?

Tried (Plan 6 Option 2 in our design doc). Brittle: CC update overwrites symlinks. Cache is canonical, source dir is not. Auto-discovery would flip the canonical location to the source dir itself.

Context

• ParisGroup uses claude-devkit to manage per-repo filtered views across ~10 repos.
• Plan 5 dogfooding (May 2026) revealed that local-path installs at project scope are rejected by CC 2.1.138 — "not found in any configured marketplace".
• Plan 6 ships a wrapping-marketplace workaround (linked above) but it is noticeable complexity (~150 LOC + 4 doctor checks + 4 real-cc smoke fixtures). Auto-discovery would let us delete most of it.

We also discovered along the way (CC 2.1.138):

• claude plugin list does not accept --scope — needed to add a client-side filter.
• CC registers managed views under the marketplace-namespaced id <plugin-name>@<marketplace-name>, not the bare <plugin-name>.
• marketplace.json source is resolved relative to the parent of the marketplace.json directory (installLocation), not the directory containing it.

If any of those are documented somewhere we missed, a pointer would help. Happy to chat through implementation specifics or beta-test if you ship the auto-discovery feature.