Skill tool: session can resolve a plugin version far behind installed, with no observable signal and a misdiagnosing error message

Summary

A running session can resolve skills from a plugin cache version significantly older than what installed_plugins.json reports as installed, and no available diagnostic reveals this from inside the session. The only failure surface is Skill(skill="...") returning Unknown skill for a skill name that genuinely exists — indistinguishable from a typo, a renamed skill, or a routing bug.

Measured

installed_plugins.json  →  dr-workflow  0.1.114  (sha 9c323ed2)
session resolved        →  dr-workflow  0.1.76
                                        ^^^^^^^ 38 versions behind

The session's actual resolved version was observable only because a skill happened to load and printed its own base directory in its output:

Base directory for this skill:
  ~/.claude/plugins/cache/claude-skills/dr-workflow/0.1.76/skills/workflow-protocol

There is no other surface that reveals this. /plugin marketplace update and /plugin update <name> both ran clean and reported the plugin as current; a full-tree md5 checksum of the installed cache against the plugin repo's origin/main returned 0 mismatches. All of these checks are correct and are all answering a question about the installed cache on disk — none of them can observe what version the running session actually has resolved into its own tool-call context.

The misdiagnosis this produces

Two skills (review, delegate) were added to the dr-workflow plugin after version 0.1.76. From the stale session:

Skill(skill="rv")                            → Unknown skill
Skill(skill="dr-workflow:review")            → Unknown skill
Skill(skill="delegate")                      → Unknown skill
Skill(skill="dr-workflow:delegate")          → Unknown skill
Skill(skill="dr-workflow:workflow-protocol") → resolves fine

The last line is what makes this hard to diagnose correctly: some skills in the same plugin resolve and others don't, because workflow-protocol existed at version 0.1.76 and the other two didn't. Two independent sessions hitting this concluded "routing bug in the skills marketplace repo" and nearly filed bug reports against that repo — the actual cause (a stale in-session plugin-version pin) was invisible to every instrument available to them.

Suggested fixes, in order of value

1. Make the session's actually-resolved plugin version observable without requiring a skill to load. Any surface would do — a field in a status/debug command, something /plugin list or similar could report, anything that prints the number that currently only leaks out incidentally via a skill's own "base directory" line.
2. Improve the Unknown skill error itself. If the tool/loader has access to the currently-installed plugin manifest, and the requested name exists there but not in the version this session has resolved, say so explicitly: e.g. "'review' exists in dr-workflow 0.1.114 but this session resolved 0.1.76 at startup; restart the session to pick up newer skills." That one sentence converts a misdiagnosis (routing bug) into an actionable fix (restart).

Why this isn't a marketplace/plugin-repo bug

I checked whether this is something a plugin repo (e.g. a marketplace.json/plugin.json) could work around — it cannot. There's no field or hook in the plugin manifest schema for version-reporting or custom error text, and the "base directory" line that revealed the actual bug is emitted by the Skill tool's own implementation, not by any skill's content. This needs a fix in the Skill tool / plugin-loading mechanism itself.

Environment

Observed in a live Claude Code session against a private plugin marketplace repo (multiple plugins, versioned independently, updated frequently — several PRs/hour from parallel sessions is the normal operating condition for this repo).