[FEATURE] Please bring back Commands

Resolved 💬 3 comments Opened Jan 25, 2026 by mindplay-dk Closed Mar 1, 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

Custom slash commands have been merged into skills

https://code.claude.com/docs/en/skills

<img width="1494" height="393" alt="Image" src="https://github.com/user-attachments/assets/62f3840d-e444-4690-b530-7282d4d71558" />

This merge doesn't make any sense.

As users have pointed out on reddit:

Commands were prompt templates called directly, and skills are injected automatically.
They should absolutely be different. There was a good semantic reason for the separation, and now the semantics are muddy for no good reason. > Agreed. Slash always runs the prompt, prompting for the skill... doesn't.

Larger workflows such as this one wouldn't make any kind of sense if all the commands were suddenly skills - the directory structure would be a huge mess, you'd have to read every file and look for disable-model-invocation: true to learn which skills are actually commands in disguise.

The kind of prompting you'd use in a skill vs a command are fundamentally different - attempting to erase this difference doesn't make any sort of sense.

The whole point of skills is the agent decides when to load or use them - the point of commands is the user decides when to issue them.

I do recognize that yes unifying the schema between skills and commands makes sense - the front-matter options can absolutely be the same.

And yes you can have a feature that lets users explicitly invoke a skill to make sure it gets used - that's just a convenient UI feature, but this doesn't need to lead to any conceptual change.

So no, semantically (in practice) attempting to call everything a "skill" doesn't make any sense - a workflow is going to consist of user-issued commands, as well as agent-selected skills.

This conceptual separation made sense.

The files can have identical schema, but conceptually the distinction is really important.

I don't know why anyone would want a complex workflow where "everything is a skill", including all the commands that drive the workflow? Needing to hunt through every file to learn what is and is not a command? Besides the confusion this creates, it's just impractical.

Adding the disable-model-invocation: true property to a skill effectively says "this is a command and not a skill" - but then why would you put it in a file named SKILL.md? You wouldn't.

Proposed Solution

Since .claude/commands is still supported, this is not at all too late: please reconsider this decision and preserve documentation and support for Commands proper.

These concepts are well established in the agentic coding community already - the distinction is useful, relevant, important, and necessary, if not at least because commands contain instructions, and skill contain useful information and rules that agents can reuse across commands.

When learning to write command prompts, having the mindset of "this is a skill" is really unhelpful.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

For reference, you can look at popular workflows such as this one:

https://github.com/buildermethods/design-os

When you look at how these are structured, it should be apparent that commands drive the workflow, while the skills cut across commands and provide rules for implementing actual design.

Additional Context

Another popular workflow:

https://github.com/buildermethods/agent-os

This doesn't even have any skills - it's all commands.

Refactoring everything to SKILL.md files in subfolders, and adding the disable-model-invocation: true flag to every single file, would be really counter productive and confusing. Nothing in this workflow is a "skill".

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗