claude-code - 💡(How to fix) Fix Plugin skills from custom/private marketplaces appear in slash menu but fail with "Unknown skill" on invocation

Summary

Plugin skills from a custom/private marketplace are partially discovered by Claude Code — they appear in the slash command menu — but fail at invocation with either Unknown command: /skill-name or Unknown skill: namespace:skill-name. The Skill tool returns "Unknown skill" and the skills do not appear in the system-reminder available skills list.

Environment

• Claude Code version: 2.1.150
• OS: Windows 11 Enterprise
• Plugin source: Custom Git repository marketplace (not claude-plugins-official)

Steps to Reproduce

1. Install a plugin from a custom/private marketplace configured in settings.json:

{
  "enabledPlugins": {
    "myPlugin@myDivision": true
  },
  "extraKnownMarketplaces": {
    "myDivision": {
      "source": {
        "source": "git",
        "url": "https://github.com/myDivision/plugins.git"
      }
    }
  }
}

1. Confirm the plugin is installed — claude plugin list shows myPlugin@myDivision as ✔ enabled

2. Start a new session — the plugin's skills appear in the slash menu (e.g. /myPlugin-plan)

3. Attempt to invoke:

   • Via slash menu: Unknown command: /myPlugin-plan
   • Via Skill tool with myPlugin:myPlugin-plan syntax → Unknown skill: myPlugin:myPlugin-plan

Expected Behavior

Skills from all enabled plugins, regardless of marketplace source, should:

• Appear in the system-reminder available skills list at session start
• Be invokable via the Skill tool as pluginName:skillName
• Be invokable as slash commands

Actual Behavior

Root Cause Hypothesis

The harness's skill registry build (which populates both the system-reminder and the Skill tool's runtime) appears to skip or fail for plugins from non-official/custom marketplaces. Meanwhile, the slash menu file scan (a filesystem walk) picks them up correctly, causing the split behavior.

Investigation

The plugin cache is fully present and correctly structured:

~/.claude/plugins/cache/myDivision/myPlugin/1.x.x/
├── .claude-plugin/
│   ├── marketplace.json
│   └── plugin.json          # valid, with correct name/version/author fields
├── hooks/
│   ├── hooks.json           # identical structure to superpowers
│   ├── run-hook.cmd         # polyglot Windows/Unix wrapper
│   └── session-start        # bash script; injects CLAUDE.md context
├── skills/
│   ├── myPlugin-plan/
│   │   └── SKILL.md         # valid frontmatter: name, description
│   ├── myPlugin-review/
│   │   └── SKILL.md
│   └── ...
└── CLAUDE.md

plugin.json:

{
  "name": "myPlugin",
  "version": "1.x.x",
  "dependencies": [
    { "name": "superpowers", "marketplace": "claude-plugins-official" }
  ]
}

settings.json confirms the plugin is enabled ("myPlugin@myDivision": true). The claude plugin list command confirms Status: ✔ enabled. The hooks/hooks.json is structurally identical to the working superpowers plugin.

The only observable difference between the working and broken plugin is the marketplace source (claude-plugins-official vs a custom Git-backed marketplace entry in extraKnownMarketplaces).

Workaround

Reading the SKILL.md directly via the Read tool and manually executing the skill steps works, but loses automatic skill-routing.

Additional Notes

This was discovered when trying to use a private team knowledge/workflow plugin. The plugin's SessionStart hook runs correctly (context is injected), so hook execution itself is not the problem — it is specifically the skill registry that is not being populated for custom-marketplace plugins.