Bug: native Claude Code skills missing from /<skill> autocomplete in claude agents dispatch input

Summary

In the claude agents view dispatch input, the /<skill> autocomplete is incomplete: it surfaces repo-local project skills (from the targeted repo's .claude/skills/) but omits native Claude Code skills (/release-notes, /diff, /config, etc.).

The skill resolver knows how to dispatch native skills inside an @<repo> mention prompt — typing the full name and submitting works correctly. Only the autocomplete suggestion list is filtered to one source.

Per the doc

Per the Agent view doc:

/<skill> — Suggest [skills](/en/skills) to dispatch as the prompt

"Skills" — plural, no source qualifier. The current behavior fails this contract by hiding native skills from the suggestion list.

Repro

In claude agents dispatch input, with an @<repo> mention prefixing a slash-skill prefix:

1. Repo-local skill — autocomplete works ✓

Typing @ghost /po surfaces the /post skill (from ghost's .claude/skills/post/) with its description, as expected:

!@ghost /po — /post (repo skill) appears in autocomplete

2. Native Claude Code skill — autocomplete silent ✗

Typing @ghost /rel produces no suggestions — the picker drops to the empty-state enter to create · esc to clear footer. /release-notes is a native Claude Code skill and is invisible to the autocomplete here:

!@ghost /rel — no suggestions, even though /release-notes exists

3. But the same native skill executes fine when typed in full ✓

Submitting @ghost /release-notes opens the release-notes UI correctly with the 294-version picker — proving the dispatch path knows how to resolve native skills inside an @<repo> mention. The gap is only in the suggestion list:

!@ghost /release-notes dispatched — native skill executes successfully

Expected

The /<skill> autocomplete in the claude agents dispatch input should surface both sources, merged into one suggestion list:

1. Repo-local / project skills from the targeted (or default) repo's .claude/skills/
2. Native Claude Code skills (/release-notes, /diff, /config, /agents, /model, etc.)

Ordering can prefer one source over the other, but native skills should not be invisible.

Why this matters

claude agents is positioned in the docs as a primary entry point — "you can use claude agents as your primary entry point instead of claude". If native skills are autocomplete-invisible there, users have to either (a) memorize the full names of every native skill, or (b) leave the agent view to find them. Both undercut the "primary entry point" framing.

It also creates a confusing mental model: discoverability suggests native skills don't exist in this context, but Image 3 proves they do — that mismatch between "what autocomplete shows" and "what actually works" is the worst kind of UX gap because nothing tells the user to even try.

Fix shape (suggested)

Wherever the dispatch input's /<skill> suggestion query is built today (presumably scanning the targeted repo's .claude/skills/), also scan the native skill registry (the same one that powers /<skill> autocomplete in a regular claude session) and merge the results.

Thanks!