Plugin resolves to the oldest installed version (0.1.0), silently hiding 8 newer skills incl. release-planning

[avrabe]

Symptom

Asked to use the release-planning skill in a live session, the Skill tool rejected it:

Skill(pulseengine-claude:release-planning) -> Unknown skill: pulseengine-claude:release-planning

…even though it is installed on disk.

Cause: an old version is the active one

Three versions are present in the plugin cache, and the session resolved to the oldest:

$ ls ~/.claude/plugins/cache/pulseengine-eu/pulseengine-claude
0.1.0   0.13.0   0.15.1

The session's available-skills list matches 0.1.0 exactly — 7 skills:
capture-session-learnings, clean-room-verification, oracle-gate-a-change, pulseengine-feature-loop, release-artifact-pipeline, release-execution, report-tool-friction

So everything added since 0.1.0 is installed but unreachable:
release-planning, issue-hunt, claim-verification, traceability-audit, proof-synthesis, stpa-audit, bootstrap-verification, repo-hygiene (8 skills, 0.15.1).

Earlier in the same session the loaded skills reported a base directory of .../0.10.0/skills/... — a version no longer on disk — so the resolution appears to pin at session start and not follow updates.

Impact

Silent capability loss. The agent doesn't get an error until it names a skill explicitly; otherwise it simply never learns those skills exist and falls back to ad-hoc behaviour. In this case the workaround was to read 0.15.1/skills/release-planning/SKILL.md off disk and apply it by hand — which works, but only because the skill was asked for by name.

Ask

• Resolve to the newest installed version (or make the pinned version visible so a stale pin is diagnosable rather than invisible).
• Consider pruning superseded versions on update.

Related: the methodology gap filed alongside this one — a skill that is installed but unreachable is the same shape as a gate that is defined but unenforced.

[avrabe]

Confirmed on disk, and staying open — with a precise note on what is and isn't ours to fix.

Reproduced: three versions cached, and the skill counts match your report exactly.

~/.claude/plugins/cache/pulseengine-eu/pulseengine-claude
  0.1.0    7 skills
  0.13.0  14 skills
  0.15.1  15 skills   (now 16 at v0.16.1 — gate-potency)

Disposition — this splits in two:

1. The resolution bug is upstream, not ours. "Pin at session start, resolve to the oldest, don't follow updates" is Claude Code plugin-loader behaviour. Nothing in this repo can fix it; it needs reporting to the harness. Your framing of the ask is the right one to carry over: resolve to the newest installed version, or make the pinned version visible so a stale pin is diagnosable rather than invisible. The invisibility is the real defect — an agent silently loses capability and falls back to ad-hoc behaviour, with no error until a skill is named explicitly.

2. The local mitigation is ours and is one command. Pruning superseded versions removes the ability to resolve wrong:

   rm -rf ~/.claude/plugins/cache/pulseengine-eu/pulseengine-claude/{0.1.0,0.13.0}

   Caveat worth stating: do it between sessions. A session that already pinned an older version would lose its skills mid-flight.

remaining: report the resolution/pinning behaviour upstream to Claude Code; prune the stale cache dirs locally. Not closing until at least the first is filed, since the workaround does not prevent recurrence on the next machine or the next update.

Your closing line is worth keeping in the methodology, and it is exactly why #144 and #146 landed the way they did: a skill that is installed but unreachable is the same shape as a gate that is defined but unenforced. Defined ⇒ enforced is now a named check in gate-potency; this issue is that principle applied to the tooling layer rather than to CI.

[avrabe]

Update: after /plugin update + /reload-plugins, the count went to zero

Same session, live sequence:

/plugin           -> ✔ Updated pulseengine-claude. Run /reload-plugins to apply.
/reload-plugins   -> Reloaded: 5 plugins · 6 skills · 6 agents · 9 hooks

0.16.1 is now on disk and is structurally fine — valid .claude-plugin/plugin.json, well-formed skill frontmatter, identical layout to 0.15.1, 16 skills including the new gate-potency and repo-hygiene.

But in this session:

Skill(pulseengine-claude:repo-hygiene) -> Unknown skill: pulseengine-claude:repo-hygiene

and the available-skills listing now contains no pulseengine-claude:* entries at all. Before the update this session had 7 (the stale 0.1.0 set). So the update made in-session capability go 7 → 0, and the 6 skills the reload reports come from other plugins.

Disk state:

$ ls ~/.claude/plugins/cache/pulseengine-eu/pulseengine-claude
0.15.1   0.16.1        # 0.1.0 and 0.13.0 were pruned by the update — good

So the pruning half worked; the registration half did not. Presumably a fresh session picks up 0.16.1 — that cannot be confirmed from inside this one.

Why this is worth hardening beyond the pin bug

Both the update and the reload reported success while the actual capability dropped to zero. Nothing in the output distinguishes "reloaded 6 skills, all yours included" from "reloaded 6 skills, yours contributed none."

Two cheap asks:

1. Report per-plugin skill counts on reload (pulseengine-claude: 16 skills), so a plugin contributing 0 is visible rather than hidden inside an aggregate.
2. Warn when a plugin registers 0 skills but has a non-empty skills/ directory on disk — that combination is always a defect.

This is the same shape as the class we have been fixing in rivet/spar this week: a green status line over a capability that isn't there. Filed alongside pulseengine.eu#144.