Skills loaded from ~/.claude/skills/ and .claude/skills/ are indistinguishable from internal (binary) skills in permission prompts

Description

When Claude Code surfaces available skills to the model via the system-reminder, skills loaded from user/project directories (~/.claude/skills/, .claude/skills/) appear with bare names identical to Anthropic-internal skills compiled into the binary (e.g., keybindings-help). Plugin skills, by contrast, are namespaced (plugin-name:skill-name).

The Gap

There is no label, prefix, or other signal in the permission prompt or system-reminder that tells the user (or the model) whether a skill originates from:

• The Claude Code binary (Anthropic-authored, tamper-resistant)
• A file the user placed in ~/.claude/skills/
• A file someone else placed in .claude/skills/ in a project

Why It Matters

If a developer clones a repository containing a malicious .claude/skills/<name>/SKILL.md, that skill is injected with the same apparent trust level as an Anthropic-built skill. The user has no visual signal to prompt them to audit it.

Suggested Mitigations

1. Show skill source (binary / user / project / plugin) in the permission/invocation prompt
2. Apply a namespace prefix to non-binary skills, similar to how plugin skills use plugin-name:skill-name
3. Warn on first invocation of any skill loaded from .claude/skills/ in a newly cloned/unfamiliar repo

Steps to Reproduce

1. Create ~/.claude/skills/test-skill/SKILL.md with any content
2. Start a new Claude Code session and observe the system-reminder — test-skill appears identically to keybindings-help (a binary-internal skill) with no distinguishing label