Skills added mid-session (e.g. via `git switch` to a branch that adds `.claude/skills/<name>/`) are registered for the Skill tool but never appear in the slash-command menu; `/reload-skills` reports "no changes" and does not fix it

Summary

When a repo-local skill directory (.claude/skills/<name>/SKILL.md) becomes present during a session - most commonly by switching to a git branch that adds it - the skill is picked up by the backend skill registry (the model can invoke it via the Skill tool, and it appears in the model's available-skills list), but the slash-command autocomplete never learns about it. Typing /<name> yields No matching commands.

/reload-skills does not repair this. It reports Reloaded skills: N skills available (no changes) - "no changes" because the registry it inspects was already correct. The two views are out of sync, and the user-facing one is the stale one.

Environment

• Claude Code in the VSCode extension
• Windows 11 Enterprise 10.0.22631
• Skills are version-controlled inside the repo at .claude/skills/, so which skills exist depends on the checked-out branch

Steps to reproduce

1. Open a session in a repo while on branch A, which does not contain .claude/skills/foo/.
2. Mid-session, git switch B, where branch B adds .claude/skills/foo/SKILL.md (valid frontmatter: name: foo, plus a description).
3. Observe that the model's available-skills list now includes foo - it is invocable via the Skill tool.
4. Type /foo in the input box.

Expected

/foo resolves in the slash-command menu, like any other repo skill.

Actual

The autocomplete shows No matching commands (screenshot in a comment below). Running /reload-skills returns 74 skills available (no changes), and the menu still cannot resolve /foo.

Evidence that this is specifically about mid-session appearance

In my repo, .claude/skills/ holds 45 skill directories. Running git ls-tree --name-only <branch> .claude/skills/ against the branch the session started on versus the branch I switched to shows exactly two directories that are new on the new branch - and those two are precisely the two skills that (a) appeared in the model's available-skills list mid-session and (b) cannot be resolved from the slash-command box. The other 43 skills, which were on disk when the session started, autocomplete normally.

So the discriminator is not anything about the SKILL.md contents - it is "was this skill on disk at session start."

Workarounds

• Ask the model to invoke the skill in plain language - the Skill tool path works fine.
• Start a new session / reload the window after the branch switch.

Suggested fix

Have /reload-skills also re-sync the slash-command menu - or have the menu read from the same registry the Skill tool uses - so the two views cannot drift.