Jan 10, 2026

Claude Code has been shipping at a blistering pace. But buried in the recent 2.1.x releases is a fundamental shift in how the tool thinks about extensibility. The changes to skills, slash commands, and subagents might look incremental, but they’re pointing toward something bigger: these three abstractions are merging into one.

Let me explain what’s happening and where I think this is headed.

The Three Abstractions (And Why They Exist)

Claude Code currently has three different ways to extend its capabilities. Each came about at different times, solving different problems.

Slash Commands are the simplest. You have a prompt you use often. Instead of typing it every time, you save it to a file and invoke it with /command-name. That’s it. A saved prompt with a shortcut.

Skills evolved from slash commands. The key difference: a skill isn’t just a markdown file—it’s a folder. That folder contains your prompt (skill.md) plus supporting resources: code snippets, HTML templates, whatever the skill needs. This lets you build capabilities that go beyond text, like parsing PDFs or generating Word documents.

Subagents do two things. First, they let you define a persona: “You are an expert code reviewer. Here’s how you do reviews.” Second—and this is the important part—they run in their own context window. They don’t fill up your main conversation.

Here’s how invocation used to work:

• Slash commands: Explicit. You type /command and it runs.
• Skills: Auto-discovered. The model sees your intent, checks its skills folder, and pulls in relevant ones. Only the name and description load initially—the full skill loads on-demand.
• Subagents: Run in their own context window, spawned when needed.

But reading the above you can probably already see the cracks appearing. Even though each abstraction had a good reason to exist at the time it was introduced, now that you have all three it makes choosing one not entirely straightforward. If you want to give the model a new capability there is a fair bit of head-scratching involved. Which abstraction best fits what I want to do? They all overlap with each other to some extent.

What Changed

The recent releases blur all these lines.

Skills can be invoked as slash commands. Skills now appear in the / menu. You can explicitly invoke them. They still auto-discover, but explicit invocation is now an option. The physical difference in how skills and commands were invoked is now gone.

Skills can run in their own context. A new front matter field, context: fork, lets a skill run as a subagent—in its own context window. This was subagents’ whole reason for existing.

Skills can declare agent dependencies. The agent field in skill front matter lets you specify which agents (explore, plan, etc.) a skill can use. The semantics here are honestly confusing. I can’t wrap my ahead around what it means for a skill to use a generic agent like “plan”.

These changes take three abstractions that already overlapped and brings them much closer together. I’d be surprised if all three didn’t collapse into one neat, easy-to-understand abstraction soon.

A Unified Abstraction

What could that unified abstraction look like?

These three abstractions conflate two orthogonal concerns:

Concern 1: How to encode knowledge.

There are two types of knowledge:

Conceptual knowledge: Abstract domain expertise. “You are a security engineer. Here’s what great security engineers look for.” This is persona-style knowledge—the stuff you’d put in a subagent.

Procedural knowledge: Step-by-step processes. SOPs. Code snippets that manipulate PDFs. Scripts that generate documents. This is what skills are good at.

Concern 2: Where to execute.

Do you run in the main context window, or fork into your own? This used to be a subagent-only feature. Now skills can do it too.

When you mix orthogonal concerns into the same abstractions, you get the muddy situation we have now.

Where This Is Headed

The folks at Anthropic are probably already thinking along these lines. The changelog hints suggest they are. Here’s what I think the endgame looks like:

One abstraction: Skills.

Skills are already a superset of the other two:

• They can contain just a markdown prompt (like a command)
• They can contain resources (their original purpose)
• They can encode personas (conceptual knowledge)
• They can run in their own context (like subagents)

One switch: Context mode.

A simple front matter field: context: main or context: fork. That’s it. You decide whether your skill runs in the main conversation or gets its own context window.

Composition through references.

Skills can reference other skills. This is already possible and works naturally with auto-discovery. A skill referencing another is just an emphasized hint—“when running this, keep these other skills in mind.”

Invocation becomes uniform.

Everything is /skill-name. Auto-discovery still works for capabilities the model decides to pull in. No mental overhead about “is this a command or a skill?”

The Simplified Model

That’s it. One primitive. One switch for context behavior. Composition through references. Uniform invocation.

Everything else—the distinction between commands and skills, the separate concept of subagents—becomes unnecessary.

Why This Matters

If you’re building workflows with Claude Code today, you’re navigating three overlapping abstractions with unclear boundaries. Do you make this a command or a skill? Should it be a subagent? The decision tree is more confusing than it needs to be.

A unified model means one question: “What knowledge am I encoding?” Write it as a skill. If it needs its own context, flip the switch in YAML frontmatter.

I hope we see this simplification in the next few releases. The changes in 2.1.x are clearly headed this direction.