The ClaudePluginManifest interface was missing the `commands` field
(the standard Claude plugin format), and resolvePluginDir only checked
the legacy `slash-commands` key. Plugins declaring their command path
via `"commands": "..."` silently fell back to the hardcoded
`<plugin-root>/commands/` directory, which doesn't exist for
Claude-format plugins, so no slash commands were ever loaded.
Changes:
- Added `commands?: string` to ClaudePluginManifest.
- Changed resolvePluginDir to accept ReadonlyArray<keyof
ClaudePluginManifest> and iterate in priority order; the first
non-empty match wins.
- loadSlashCommands now passes ["commands", "slash-commands"] so
the canonical Claude plugin key takes precedence over the legacy one.
- Added two regression tests: one covering the `commands` key in
isolation, one verifying its precedence over `slash-commands` when
both fields are present.
Fixes#1076
- P1: Use root.scope instead of hardcoded 'user' level in claude-plugins provider
- P2: Iterate all registry entries per plugin ID, not just first one
- P3: Add home parameter to discoverAgents() for test isolation
- P4: Add test coverage for claude-plugins discovery (12 tests)
- P5: Cache listClaudePluginRoots results to avoid repeated parsing
Addresses issues found in adversarial review of PR #49
roboomp