[FEATURE] Add /reload-skills command to refresh skill discovery mid-session

Status Fixed / completed
Maintainer reply ✓ Yes — claude[bot]
Activity 6 comments · opened May 13, 2026 · closed May 27, 2026
💡 Likely answer: A maintainer (claude[bot], contributor) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Currently, skills are scanned and listed only at session start. If a skill is created or modified in another terminal during an active session, the only way to pick up the change is to start a new session.
A /reload-skills command (or equivalent) would re-scan the skills directories and update the available skills list without requiring a new session. This would be especially useful when working across
multiple Claude Code terminals simultaneously.
Current behavior: New/modified skills are only visible after starting a new session.
Expected behavior: /reload-skills rescans ~/.claude/skills/ and project-local .claude/skills/ and makes changes available immediately.

Proposed Solution

Add a /reload-skills slash command that re-scans ~/.claude/skills/ and all project-local .claude/skills/ directories and updates the available skills list in the current session without requiring a restart.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/20507
  2. https://github.com/anthropics/claude-code/issues/14314
  3. https://github.com/anthropics/claude-code/issues/23385

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

yacb2 · 3 months ago

I hit this same thing across multiple terminals and built https://github.com/yacb2/claude-session-handoff as a stopgap. It's a wrapper + SessionStart hook that closes the current session and opens a fresh one seeded with a handoff prompt, so the new process picks up any skills added in another terminal without losing context. It doesn't add a /reload-skills command — skills are still only scanned at session start — it just makes the restart fast enough that it's tolerable until the real feature lands.

Diego-BV · 3 months ago

Thank you, I'll close this since I didn't find a topic but looks like there was already.

Kaelz1 · 3 months ago

+1, and I think the argument is stronger than the issue body suggests.

The pushback I've heard against hot-reloading is "it invalidates the prompt cache, which makes every following turn slower and more expensive." That explains why it's not free — it doesn't explain why it shouldn't be allowed.

A /reload command is opt-in. The user is explicitly choosing to pay the cache cost in exchange for not losing their session. That's a tradeoff they're qualified to make.

Also worth scoping wider than just skills:

  • Skills — re-scan ~/.claude/skills/ and <project>/.claude/skills/
  • MCP servers — re-read config, reconnect new servers (cleanly disconnect removed ones)
  • Hooks — already on-disk, but the registered handlers are session-cached
  • Statusline — trivially hot-reloadable today (script is re-executed every prompt), no work needed

If the scope feels too broad, splitting it into /reload-skills, /reload-mcp, /reload-hooks is fine — what matters is that the user gets the option without having to throw away their session context.

The current "restart your session" UX directly conflicts with the agent's stated value prop of being a long-running collaborator that builds up context. It's friction that doesn't need to exist.

---
Comment written and submitted by Claude (Sonnet) on behalf of the account holder, with explicit authorization.

claude[bot] contributor · 3 months ago

This issue was fixed as of version 2.1.152.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.