Skill tool: one specific skill fails 'Unknown skill' while sibling skills installed in the same batch work fine

Summary

A single user-installed skill (veteran-ai-engineer, part of a set of 9 "veteran-*" review skills installed together as separate plugins) cannot be invoked via the Skill tool — every call returns Unknown skill: veteran-ai-engineer — even though:

• ListSkills shows it with enabled: true.
• Its entry in the local manifest.json (skills-plugin cache) is structurally identical to every working sibling skill (skillId, name, description, creatorType, updatedAt, enabled: true, backingPluginId all present and well-formed).
• Its SKILL.md file exists on disk in the expected location, with the same directory shape (a references/ subfolder + SKILL.md) as every sibling skill that works.

Repro

1. Install a batch of skills as separate plugins in the same session (in this case, 9 "veteran-*" role-review skills: ai-engineer, solution-architect, accountant, devops-engineer, security-engineer, legal-counsel, engineer, humanizer, ux-designer, company-secretary, marketing-head, testing-head, penetration-tester — installed within the same ~11-second window per their manifest.json updatedAt timestamps).
2. Call Skill({skill: "veteran-ai-engineer"}) → fails with Unknown skill: veteran-ai-engineer.
3. Call Skill({skill: "veteran-solution-architect"}) (or any of the other 8 skills from the same install batch) → succeeds normally, returns the full SKILL.md content as expected.

Confirmed reproducible in two contexts within the same session:

• Directly in the main conversation loop.
• Inside a Workflow-tool spawned subagent (the subagent's own Skill call failed the same way, independently confirmed by re-testing directly afterward).

What this suggests

Since the local manifest entry for the failing skill looks identical in shape to the working ones, the failure looks like it's in a separate runtime name-resolution/index step the Skill tool consults at invocation time — not in the manifest or the on-disk SKILL.md file, both of which are present and well-formed. Possibly a registration step that didn't complete for this one skill during the batch install, or a stale in-session index that doesn't include every skill installed in that batch.

Environment

• Claude Code desktop app, Windows 11
• Skills installed via a plugin bundle (creatorType: "user"), each skill with its own backingPluginId
• The failing skill's manifest entry: skillId: skill_01XxPQ9f6j5zSU9YN5CpMikL, backingPluginId: plugin_014R7WX8cYtBADRpymmhyWH9
• Skill file location (relative to the plugin's skills directory): skills-plugin/<install-id>/<session-id>/skills/veteran-ai-engineer/SKILL.md — present, non-empty, same shape as working sibling skills

Impact

Multi-agent workflows that fan out subagents to each load a different skill by name silently degrade: the affected agent falls back to its own unassisted judgment instead of the packaged skill content, with no error surfaced to the user unless the agent happens to report the failure itself (as one did here, which is how this was caught).