[BUG] /reload-plugins does not re-inject available-skills context into the active conversation after plugin upgrade

Summary

When a plugin publishes a new version that adds a new skill, running /reload-plugins in an active Claude Code conversation does not cause the new skill to become discoverable to the model in that conversation. The model's available-skills <system-reminder> block — the context block that lists which skills can be invoked via the Skill tool — is established at session start and is not re-emitted on /reload-plugins. A fresh session is required.

Related existing issues

• #46435 — the "0 skills" count in the /reload-plugins output is a labeling bug (command_count mislabeled as "skills") and is NOT evidence that skills failed to load. An earlier draft of this report leaned on that count; that part is retracted.
• #55008 — /reload-plugins does not reload hook scripts in the active session. Structurally similar pattern (on-disk update succeeds, in-session behavior is stale) but for hooks. This filing covers the same pattern for skills, specifically the model-facing available-skills context block.

Environment

• Claude Code on macOS (darwin 25.2.0, zsh)
• Model: claude-opus-4-7

Reproduction

1. Install a plugin that exposes skills — e.g., my-repo-skills@0.1.0.
2. Start a Claude Code session. The plugin's existing skills appear in the available-skills <system-reminder> block injected into the model's context.
3. Upstream plugin publishes a new version (0.2.0) that adds a new skill (call it skill-B).
4. In the same active session, run /reload-plugins.

Expected

skill-B is invokable via the Skill tool in the current conversation — i.e., the available-skills <system-reminder> is re-emitted with the new entry.

Actual

The plugin upgrade itself succeeds on disk:

• ~/.claude/plugins/installed_plugins.json correctly updates version to 0.2.0 and installPath to the 0.2.0/ cache directory, with a current lastUpdated timestamp.
• ~/.claude/plugins/cache/<plugin>/<plugin>/0.2.0/<skill-B>/SKILL.md exists with valid frontmatter.

But:

• The available-skills <system-reminder> the model sees still lists only the pre-upgrade skill set. skill-B is absent.
• Calling the Skill tool with the new skill name is not possible — the model has no record of it.
• Starting a brand-new Claude Code session resolves it (skill-B appears in the available-skills block immediately).

Per #46435, the /reload-plugins numeric output cannot be used to confirm or deny that the internal skill registry was refreshed — the tally there is mislabeled. So this report is scoped specifically to the model-facing context block, not to the underlying registry. The underlying registry may or may not be refreshed by /reload-plugins; either way, the symptom that matters for users is that the model cannot invoke the new skill until the next session.

Impact

• Plugin authors who add a new skill cannot roll it out to teammates' active sessions — everyone has to restart.
• For a workflow that depends on a long-running conversation (debugging session, deep review, etc.), discovering mid-session that you need a newly-published skill means losing context to a restart.
• This silently undermines the primary value proposition of /reload-plugins for the most common plugin change.

Suggested fix

After /reload-plugins updates the plugin install records and re-binds agents/hooks/MCP/LSP, re-emit the available-skills <system-reminder> block into the active conversation with the current enabled set. This is the same block already produced at session start, and the existing re-bind paths for agents/hooks/MCP/LSP show the harness already supports mid-session context updates for other component types.

Notes

Surfaced while a plugin author bumped a private skills plugin from 0.1.0 → 0.2.0 to ship a new skill. Verified the install layer worked correctly (on-disk version, install records, SKILL.md presence). The gap is purely between the on-disk plugin state and the model's view of available skills in the active conversation.

I have not yet verified whether starting a fresh session immediately surfaces the new skill (vs. requiring a further refresh). If a maintainer wants that data point I can confirm — it would localize the bug to "context re-emit on reload" vs. "registry refresh on reload" cleanly.