Skill picker should distinguish custom-authored skills from plugin/core skills

Resolved 💬 1 comment Opened May 27, 2026 by emikysa Closed Jun 27, 2026

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)
  1. 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)
  1. 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.
  2. Section grouping in the picker - custom skills surface first, then plugin skills (grouped by namespace), then core skills. Within each section, alphabetical.
  3. Filter shortcut to constrain the picker by source - e.g. /my:create shows only user-authored matches, /plugin:create shows 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 frontmatter name: 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 the name: 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 the description: 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 -em to 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

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗