/skills prints "No changes" instead of the skill list, and misses skills added mid-session

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

/skills never prints the skill list when there is nothing to reload — it prints only No changes. Combined with the fact that /skills does not pick up skills added mid-session (while /reload-skills does), a user who has just created a skill is led to believe registration failed.

Observed sequence in a single session (Claude Code 2.1.237, macOS, CLI):

1. Created ~/.claude/skills/offload/SKILL.md and ~/.claude/skills/file-share/SKILL.md during the session.
2. /skills → nothing listed.
3. Restarted Claude Code → still nothing.
4. /offload → Unknown command: /offload.
5. /reload-skills → Reloaded skills: 19 skills available (2 added) — the two skills were there all along.
6. /skills again → No changes. Still no list.

A brand-new session does show the list, so the files and frontmatter were valid the whole time.

Two separate problems surface here:

A. /skills does not detect newly added skills, but /reload-skills does. At step 2 the skill files already existed on disk. /skills reported nothing; /reload-skills immediately found 2 added. If /skills performs a reload at all (its No changes output suggests it does), it is not seeing the same filesystem state that /reload-skills sees.

B. /skills prints No changes instead of the skill list. The command name reads as "show me my skills." When the answer is a bare No changes, there is no way to tell "the list is empty" from "the list is unchanged and I am not showing it to you."

Why this matters

This is a discoverability trap, not just cosmetics. The visible evidence — empty /skills, Unknown command, no change after a restart — all points at "my skill is not registered," when in fact it was registered and one command away from working.

I spent a long debugging session on this. I inspected ~/.claude.json, found tengu_skills_dashboard_enabled: false and claude_code_skills_dashboard_enabled_cli: false, and concluded the dashboard was disabled for this account. Wrong. I then concluded skills need a ~/.claude/commands/<name>.md wrapper to be reachable, and created one. Also wrong, and it added a file the user did not want. claude --help lists CLI flags only, so /reload-skills never surfaced there.

The fix that mattered was one command whose name I had no way to discover from inside the product.

What Should Happen?

1. /skills should list the skills, not just report reload status. If nothing changed, still print the current list.
2. If the on-disk skill set differs from the session's, /skills should either pick it up itself or say so explicitly — e.g. 2 skills on disk are not loaded in this session — run /reload-skills.
3. Ideally, Unknown command: /<name> could hint at this when a skill with that name exists on disk but is not loaded in the session.

Any one of these would have ended the confusion immediately.

Environment

• Claude Code 2.1.237 (native install, ~/.local/bin/claude)
• macOS (Darwin 25.5.0), Apple Silicon
• Skills at ~/.claude/skills/<name>/SKILL.md, personal scope, no plugins/marketplace involved
• ~/.claude.json: tengu_skills_dashboard_enabled: false, claude_code_skills_dashboard_enabled_cli: false (noted for completeness — a fresh session lists skills fine with these flags off, so they appear unrelated)

Related

• #74990 — compaction drops the Available skills reminder; /reload-skills recovers it
• #72631 — IDE palette does not index newly added skills until reload
• #80289 — /cd does not load project-scoped skills from the new directory

Those cover the reload mechanism itself. This report is about /skills not surfacing the list or the "needs reload" state to the user.