Claude Code skills and slash commands, explained

Last updated: August 30, 2026

Claude Code skills are reusable instructions, stored as markdown files, that teach the agent how to perform a specific task your way. You invoke them as slash commands (like /deploy or /create-feature) inside a Claude Code session. Think of them as saved expertise: instead of re-explaining a workflow every session, you type one command and the agent follows the playbook.

Slash commands vs skills: the distinction

The terms get used interchangeably, and in practice they've converged. A slash command is the invocation: type / in Claude Code and you get a menu of everything available. A skill is the substance: a markdown file (with optional frontmatter describing when it applies) containing the instructions the agent follows when invoked. Built-in commands like /help ship with Claude Code; custom skills are ones you or your tools add.

How a skill works under the hood

A skill lives in a discoverable location (project-level under .claude/, or user-level in your home directory). At its simplest it's a markdown file whose body is a prompt template. When you type the command, Claude Code loads the file's instructions into the conversation and the agent executes them with all its normal abilities: reading files, running shell commands, editing code.

Three properties make skills more powerful than saved prompts:

• They compose with your codebase. A skill can say "read the existing routes before adding one," and the agent actually does it, so output matches your conventions.
• They encode process, not just phrasing. A skill can enforce ordering: write tests first, ask for approval before pushing, update the changelog after.
• They're shareable. Committed to the repo, every collaborator (and every future session) gets the same workflow for free.

Writing your first skill

A minimal custom skill is genuinely just a markdown file:

# .claude/skills/changelog/SKILL.md
---
name: changelog
description: Add an entry to CHANGELOG.md for the current change
---

Read the staged git diff. Summarize the change in one line,
imperative mood. Add it under the [Unreleased] heading in
CHANGELOG.md, creating the heading if missing. Do not commit.

Save it, type /changelog, and the agent does exactly that, every time, in any session. Good skills share a shape: state the inputs to read, the steps in order, and what done looks like. Vague skills produce vague behavior; skills written like a checklist for a new teammate work remarkably well.

Case study: four skills that run a whole planning loop

Skills scale past single tasks into full workflows. BuildBoard, our planning app for Claude Code, is built almost entirely on this mechanism. Installing it gives your Claude Code four skills that chain into a spec-driven development loop:

• /create-feature reads your product context and writes a requirements plan as markdown.
• /create-mock reads that plan and generates HTML mockups you can open in a browser.
• /create-plan reads the plan, the mockups, and your actual codebase, then writes a tech spec with an ordered build queue.
• /build-plan implements the feature story by story, with all three artifacts in context.

Each skill's output is the next skill's input, which is the property that makes the loop work: by the time /build-plan runs, the agent isn't guessing what you want because three approved documents say exactly what you want. The app's kanban board tracks each feature through the stages; the skills do the work. A full walkthrough is in how to plan features for Claude Code.

Practical tips

• Start from repetition. Anything you've typed into Claude Code three times is a skill candidate.
• Make outputs files. Skills that write artifacts (plans, specs, reports) beat skills that just answer, because files persist across sessions.
• Keep one skill per job. A skill that does five things does none reliably; chain small skills instead.
• Version them with the repo. Skills are code; review changes to them like code.