If you’ve been using Claude Code for a while, you probably built up a collection of custom slash commands in .claude/commands/. They worked fine. They still do. But as of version 2.1.3, commands and skills have been merged into a single unified system, and the skills system is now the canonical way to extend Claude Code.

Here’s what that means in practice.

What Was the Difference Before?

Before the merge, you had two overlapping ways to add custom behavior to Claude Code:

Slash commands lived in .claude/commands/ as single markdown files. Simple to set up, invoked manually with a /name prefix. That was mostly it.

Skills lived in .claude/skills/ as directories, each with a SKILL.md entrypoint. More structured, but also more powerful.

The problem: both were triggered the same way, both used similar markdown-plus-frontmatter formats, and both served roughly the same purpose. The distinction confused developers and led to duplication.

What Changed in the Merge

The .claude/commands/ path still works. Your existing command files will not break. But the recommended location going forward is .claude/skills/ for project-level workflows and ~/.claude/skills/ for personal skills you want available across all your projects.

The REAL difference isn’t the folder. It’s what skills can do that commands never could.

Skills support supporting files. Each skill is a directory, so alongside your SKILL.md you can include templates for Claude to fill in, example outputs showing the expected format, and scripts Claude can execute. Reference these files from your SKILL.md and Claude knows what they contain and when to load them. With old-style commands, you had one markdown file and that was it.

Skills also support AUTO-INVOCATION. This is the feature that makes the merge worth paying attention to. When you write a skill’s description field in the frontmatter, Claude reads it and decides whether to invoke the skill automatically based on what you’re working on. You write a blog post and Claude triggers your brand-voice-check skill without you typing anything. Commands were always user-invoked. Skills can be both.

The Skill Format

Every skill needs a SKILL.md with YAML frontmatter and a body of markdown instructions. Here’s a minimal example:

---
name: explain-code
description: Explains how code works. Use when explaining a codebase or when the user asks "how does this work?"
---

When explaining code, always:

1. Start with a plain-English summary
2. Walk through the logic step by step
3. Call out any non-obvious gotchas

The name field becomes the /slash-command. The description is what Claude uses to decide whether to auto-invoke the skill. Vague descriptions fire too broadly. Specific ones (mentioning file types, directories, or action contexts) fire only when relevant.

When skills share the same name across levels, priority order is: enterprise > personal > project. If a skill and an old-style command share the same name, the skill wins.

Bundled Skills Ship Out of the Box

Beyond custom skills, Claude Code now ships with built-in bundled skills that are available in every session. Unlike hardcoded slash commands like /clear or /compact, bundled skills are prompt-based. They give Claude a detailed playbook and let it orchestrate the work using its tools, which means they can spawn parallel agents, read files, and adapt to your specific codebase.

You invoke them the same way as any custom skill: /skill-name. Run /skills to see everything available.

What You Should Actually Do

If you have files in .claude/commands/, leave them. They work. But when you create something new, use .claude/skills/. Structure it as a directory with SKILL.md as the entrypoint. Write a specific description field so Claude can auto-invoke it when relevant. Add supporting files if the skill is complex enough to need them.

The merge is mostly a simplification, not a breaking change. One system instead of two, with more capability than either had before.