[FEATURE] Confusing naming: .claude/skills/ and .claude/commands/ are both called "skills" internally

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

The Claude Code harness surfaces two structurally and behaviorally distinct things under the same name — "skill":

1. .claude/commands/ — markdown files, user-triggered slash commands
2. .claude/skills/ — YAML + shell scripts, invoked autonomously by Claude

These are meaningfully different:

• Different file formats
• Different invocation models (user-driven vs autonomous)
• Different directory names

Yet both are referred to as "skills" in the system prompt and via the Skill tool. This is confusing because:

• The directory literally named skills and the one named commands are treated as the same concept
• The name "skill" doesn't reflect the user-facing term "command" that most users will reach for
• Claude itself gets confused and gives incorrect explanations about the distinction

Suggestion: Use distinct terminology internally that maps to the directory names — "commands" for .claude/commands/ and "skills" for .claude/skills/ — so the abstraction isn't leaky and
Claude can give accurate answers about how they work.

Proposed Solution

Use distinct terminology that maps to the actual directory names:

• Refer to .claude/commands/ entries as "commands" — they are user-triggered slash commands defined in markdown
• Refer to .claude/skills/ entries as "skills" — they are autonomously-invocable capabilities defined in YAML + shell

Concretely:

1. Update the system prompt to use "command" when referencing .claude/commands/ entries and "skill" when referencing .claude/skills/ entries
2. Rename the Skill tool (or add a separate Command tool) so the invocation mechanism reflects the distinction
3. Update documentation to clearly define both terms and when to use each

This way the terminology is self-documenting — a developer looking at their .claude/ directory can immediately map the folder name to the concept name, and Claude can give accurate
answers about how they differ.

Alternative Solutions

_No response_

Priority

Low - Nice to have

Feature Category

CLI commands and flags

Use Case Example

A developer has this setup:

.claude/
commands/
deploy.md # slash command: user types /deploy to trigger a deployment
skills/
run-tests/ # skill: Claude autonomously runs this after writing code
skill.yaml
run.sh

With the current naming, Claude describes both as "skills" — so when the developer asks "what's the difference between my commands and skills directories?", Claude either gives a wrong
answer or a confusing one.

Another example of confusion caused by inconsistent naming

Developer asks Claude:

▎ "Can you run /write-integration-tests for me after you finish implementing this feature?"

Claude responds:

▎ "I'll run the write-integration-tests skill automatically after I finish."

Developer now wonders:

• Is Claude going to run this on its own, or do I need to type /write-integration-tests?
• Is this something Claude controls, or something I control?
• Why is Claude calling it a "skill" when it's in my commands/ folder?

Additional Context

_No response_