Plugin-qualified skill names are not resolved by the native Skill tool

[ayu-exorcist]

Environment

• Kimi Code: 0.29.1
• Superpowers: 6.1.1
• Platform: MINGW64_NT-10.0-19045 3.5.7-463ebcdc.x86_64 x86_64 unknown
• Provider/model: not relevant; the failure is deterministic in local skill catalog/tool resolution.

Problem

Plugin-qualified skill names such as superpowers:systematic-debugging cannot be invoked through the native Skill tool, even though the plugin skill is installed and can be invoked by its bare name.

Skill("superpowers:systematic-debugging")
→ Skill "superpowers:systematic-debugging" not found in the current skill listing.

Skill("systematic-debugging")
→ Skill "systematic-debugging" loaded inline. Follow its instructions.

This breaks Superpowers' normal bootstrap flow. Its using-superpowers skill uses cross-harness canonical names such as:

"Fix this bug" → superpowers:systematic-debugging
"Let's build X" → superpowers:brainstorming

The Kimi plugin adapter correctly tells the model to use Kimi Code's native Skill tool, but that tool only accepts the unqualified bare name.

This also leaves plugin-to-plugin collisions unresolved. If two plugins provide review or brainstorming, the global bare-name catalog keeps one registration-order winner, while normal user/model invocation has no way to select the other plugin's skill.

Reproduction

1. Install and enable obra/superpowers.

2. Start a new session so sessionStart.skill = "using-superpowers" loads.

3. Invoke the native Skill tool with:

   {"skill":"superpowers:systematic-debugging"}

4. Observe not found in the current skill listing.

5. Invoke:

   {"skill":"systematic-debugging"}

6. Observe that the same installed skill loads successfully.

Expected behavior

Support plugin-qualified identities for model and user invocation, retaining bare names as compatibility aliases when unambiguous:

Skill("superpowers:systematic-debugging")
→ catalog.getPluginSkill("superpowers", "systematic-debugging")

Skill("systematic-debugging")
→ load when exactly one candidate exists
→ return an ambiguity error listing qualified candidates when multiple plugins provide it

The model-facing listing should expose each plugin skill's exact invocable canonical ID, e.g. superpowers:systematic-debugging, so names round-trip through the Skill tool.

Source analysis

The catalog already contains most of the required machinery:

• InMemorySkillCatalog maintains byName, byPluginAndName, and getPluginSkill(pluginId, name):
  https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core-v2/src/app/skillCatalog/registry.ts
• Plugin sessionStart correctly calls getPluginSkill(pluginId, skillName):
  https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core-v2/src/agent/plugin/agentPluginService.ts
• The native model Skill tool only calls getSkill(args.skill):
  https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core-v2/src/agent/tools/skill/skillTool.ts
• User slash activation also only calls getSkill(input.name):
  https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core-v2/src/agent/skill/skillService.ts
• Source-priority merging handles workspace/user/extra/plugin/builtin collisions, but does not provide explicit selection between same-priority plugins:
  https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core-v2/src/app/skillCatalog/skillSource.ts
  https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core-v2/src/session/sessionSkillCatalog/skillCatalogService.ts

I searched open and closed issues for qualified skill names, plugin namespaces, getPluginSkill, Superpowers skill-not-found errors, and duplicate plugin skill names, and found no existing report covering this behavior.

[zenozan]

Hi, I would like to work on this issue.

I reproduced the behavior on current main: model invocation in skillTool.ts and user activation in skillService.ts still resolve only through getSkill, while the catalog already exposes getPluginSkill.

Proposed scope:

• support canonical pluginId:skillName resolution through a shared resolver;
• expose qualified IDs in the model-facing skill listing;
• retain bare names as compatibility aliases only when unambiguous;
• return an actionable ambiguity error listing qualified candidates;
• add regression coverage for model and user invocation, including duplicate names across plugins.

Could a maintainer confirm that this resolution and ambiguity behavior is the desired contract? If so, please assign this issue to me.