Skill tool resolves a stale plugin-cache copy of a user skill, silently, with no version signal

Skill tool resolves a stale plugin-cache copy of a user skill, silently, with no version signal

Summary

Invoking a user-created skill by its plugin-qualified name via the Skill tool (e.g.
anthropic-skills:slow-is-pro) loaded content from a local plugin cache that was measurably
stale relative to the same skill's actual installed copy — with no warning, no version
indicator, and no way to detect the mismatch short of independently diffing the two copies
by hand. This happened twice in one session (same stale copy both times), and fed two pieces of
downstream work from outdated rules before the mismatch was noticed.

Environment

• Claude Desktop app, Code tab, Windows.
• Skill in question: a user-authored skill, slow-is-pro, creatorType: "user" in the account's

manifest.json.

What was observed

• Installed copy (~/.claude/skills/slow-is-pro/SKILL.md): 341 lines, includes six dated

2026-09-26 fixes recorded in its own changelog section, and is byte-identical to the user's own
GitHub mirror of it (pushed 2026-09-28) — confirmed by direct diff.

• Copy the Skill tool loaded, twice, when invoked as anthropic-skills:slow-is-pro: missing

~70 lines present in the installed copy, including all six of those 2026-09-26 fixes. Loaded
from a path under
%APPDATA%\Claude\local-agent-mode-sessions\skills-plugin\<uuid>\<uuid>\skills\slow-is-pro\.

• A manifest.json sitting in that same cache directory lists this skill's updatedAt as

2026-09-22T01:25:58Z — a week behind the installed copy's real edit history and the GitHub
push. That timestamp is the only artifact anywhere that hints the cache is behind; nothing
surfaced it at invocation time.

• No error, warning, or version string appeared when the stale copy loaded. It looked like a

completely normal, successful skill invocation both times.

Impact

Two draft artifacts were built by reading the stale copy for reference and were missing content
the installed/canonical copy already had, discovered only by a later, unrelated manual diff
against the live files. Nothing in the session surfaced the mismatch on its own.

Why this isn't fixable from the skill's own content

There's no field in a skill's own files that could report "here is the version that's actually
loaded" independent of the loader — the same structural point raised in #87507 about plugin
manifests. The fix has to be in the Skill tool / plugin-cache resolution layer itself.

Suggested fixes, in rough order of value

1. Surface the actually-resolved skill's source path and/or a modification time whenever a skill

loads, not only incidentally when a skill happens to print its own "base directory" line.

1. Compare the plugin-cache copy's mtime/hash against the installed copy's at invocation time and

warn (not silently proceed) on a mismatch.

1. Give /plugin update or an equivalent an explicit "force re-sync this skill's cache" action,

independent of whatever currently makes it report clean.

Related, already-tracked issue

#87507 ("Skill tool: session can resolve a plugin version far behind installed, with no
observable signal and a misdiagnosing error message") describes the same class of problem for
versioned marketplace plugins — a session pinning to a plugin version far behind what's actually
installed, invisible to every available diagnostic. This report is the same failure mode for a
user's own single skill, where there's no version field at all, only an unpublicized cache
timestamp.