Skill picker should distinguish custom-authored skills from plugin/core skills
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
Problem
When the skill picker is open (e.g. after typing /), it's impossible to tell at a glance which entries are user-authored (sitting in ~/.claude/skills/) versus plugin-provided versus Claude Code core. Plugin skills with a namespace prefix like vercel:bootstrap, engineering:debug, or anthropic-skills:pptx are clearly stock. But a sizable subset of stock skills are unnamespaced (verify, code-review, run, init, schedule, loop, claude-api, fewer-permission-prompts, update-config, keybindings-help, security-review, review), and they mix visually with the user's own unnamespaced custom skills. Scanning the picker requires mental effort to remember which is which.
This compounds with skills that share verb prefixes. Typing /create in my picker surfaces my custom create-record, create-presentation, create-invoice, create-handoff alongside stock data:create-viz, sales:create-an-asset. The namespaced ones are easy. The bare names blur together.
Proposed Solution
Suggested solutions (any of these would help)
- Source badge or icon per row in the picker:
- user-authored (loaded from
~/.claude/skills/) - plugin (loaded from
~/.claude/plugins/*/skills/) - core (built into Claude Code)
- Preserve case in the frontmatter
name:field so users can adopt Title-Case (e.g.Create-Record) or other capitalization patterns as a self-imposed marker. Matching can remain case-insensitive; only the display would honor the user's chosen case. - Section grouping in the picker - custom skills surface first, then plugin skills (grouped by namespace), then core skills. Within each section, alphabetical.
- Filter shortcut to constrain the picker by source - e.g.
/my:createshows only user-authored matches,/plugin:createshows only plugin matches.
Any one of these resolves the cognitive load. Source badging (option 1) is probably the lightest UX change.
Alternative Solutions
Workarounds tried (all unsatisfactory)
- Title-Case directory names (
~/.claude/skills/Create-Record/): the picker display follows the frontmattername:field, not the directory name. Directory case is preserved on disk but irrelevant for display. - Title-Case frontmatter
name:(name: Create-Record): Claude Code's skill loader auto-normalizes thename:field back to lowercase between turns. No configured hook does this - the harness itself enforces lowercase kebab-case. The intent is reasonable (consistent slugs across surfaces), but it forecloses any in-name visual marker. - Description prefix (e.g. leading
[ours]in thedescription:field): only renders in the picker's right preview pane, one at a time. Doesn't help when scanning the left-column list. - Renaming the unnamespaced stock skills to tag them instead: risky. Stock skills come from plugin manifests; renames would be overwritten on update and could break internal references the manifests use to wire trigger phrases.
- Filename-only suffix convention (e.g. appending
-emto user-authored skill names): possible but inelegant - it pushes the burden onto the user and breaks visual symmetry. I'm planning to do this for new skills as a gradual forward-going marker, but it's a coping mechanism rather than a fix.
Priority
Medium - Would be very helpful
Feature Category
CLI commands and flags
Use Case Example
Use case
I have custom skills representing months of work building automation around my personal workflows. The picker treats them as equivalent to plugin and core skills - which is the right neutral default - but it hides authorship at the exact moment I'm trying to choose. Authorship is a meaningful signal: my custom skills know about my files and conventions, plugin skills are general-purpose, core skills are Claude Code primitives.
Additional Context
Environment
- Claude Code CLI: 2.1.132
- Model: claude-opus-4-7
- Platform: macOS 26.5
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗