Desktop Skills panel still doesn't show local ~/.claude/skills/ skills — root cause identified, prior issues auto-closed before review

Summary

The Customize → Skills panel in Claude Desktop does not display custom skills stored
in ~/.claude/skills/, even though those skills are fully functional and invokable
via chat/slash-command. This has been reported at least three times and each report
was auto-closed by the inactivity/duplicate bot without a maintainer response.

Prior reports

• #31597 (original report, 2026-03-06) — closed not_planned by the inactivity bot

on 2026-05-21, then auto-locked.

• #43095 (2026-04-03) — auto-closed as a duplicate of #31597 within days, then

auto-locked. Never saw a maintainer comment either.

Both threads are now locked, so this is a fresh issue per the bot's own instructions.

Root cause (already diagnosed in #31597, never addressed)

@pavelkudrna83 did a binary reverse-engineering pass on v2.1.96 and posted this on
2026-04-08 in #31597:

Root Cause Analysis (from binary reverse-engineering, v2.1.96) The main skill loader getSkills (minified: rJ5) correctly loads from 4 sources...

That comment sat unaddressed for over a month before the bot closed the parent issue
for inactivity — i.e., the bug was already correctly diagnosed by a community member
before the ticket was closed.

Impact

• Users cannot browse, verify, or manage their custom local skills from the Desktop UI.
• The "Add" button in that panel only accepts a single file, so it cannot be used to

register an existing multi-file skill directory (SKILL.md + scripts/) as a
workaround.

• Functionality is not broken — skills still work when invoked directly in chat — but

the panel is misleading: it implies a much smaller set of skills exists than
actually does.

Steps to reproduce

1. Create a valid skill at ~/.claude/skills/<name>/SKILL.md with correct frontmatter

(matches the format of official/bundled skills).

1. Restart Claude Desktop.
2. Open Customize → Skills.
3. Observe: the new skill does not appear, even though it can be invoked via

/<name> in a chat session.

Request

Please reopen or re-triage rather than relying on the inactivity bot to close this —
the root cause is already known and documented in #31597.