Slash commands and skills

After a few weeks of using Claude Code, you'll notice you keep explaining the same multi-step workflow over and over. "Read the diff. Write a tasteful commit message. Run the tests. If they pass, push." Every time. Typing the same paragraph each session is silly when there's a built-in way to capture it.

That built-in way is slash commands and skills. They're cousins. Both let you save a reusable instruction and invoke it with a short trigger.

Slash commands: the simple version

A slash command is a Markdown file with frontmatter that becomes invokable inside Claude Code with /the-name. When you type it, the contents of the file are sent to Claude as if you had typed them yourself.

A minimal slash command looks like this:

---
description: Wrap up the current branch — diff, commit, push
---

Look at the git diff for the current branch. Write a concise commit
message describing the change. Stage everything, commit with that
message, and push to the remote.

Before committing, run "npm run lint" and "npm run test" and only
proceed if both pass. If either fails, stop and tell me.

Save that file as .claude/commands/ship.md in your project. Then in a Claude Code session, type /ship and press Enter. Claude runs the workflow exactly as written.

Where slash commands live

• Project commands — .claude/commands/ inside the project. Available only when working in that project.
• Global commands — ~/.claude/commands/ in your home folder. Available in every project.

Project commands belong in git, so the whole team gets them. Global commands are your personal toolbox.

Built-in slash commands you should know

• /help — quick reference for slash commands.
• /init — generate a starter CLAUDE.md (you met this last lesson).
• /exit — end the session cleanly.
• /clear — reset the conversation context without quitting.
• /config — open the settings interface.

Type /in any session and you'll see the full list of available commands, both built-in and the ones you've added yourself.

Skills: the powerful version

Skills are slash commands' bigger, more structured siblings. They live in .claude/skills/ and have extra capabilities:

• Explicit tool allowlists.A skill can declare which tools it's allowed to use — "read-only," "may edit but not run shell commands," etc.
• Trigger hints.A skill can describe what user requests it's suitable for, and Claude will surface it when relevant — not just when typed explicitly.
• Sub-files and resources. A skill is a folder, not a single file. It can include templates, examples, and helper scripts the skill instructions reference.

A minimal skill looks like this:

---
name: code-review
description: Run a careful review of the current branch's changes
allowed-tools: Read, Grep, Glob, Bash(git diff:*)
---

You're reviewing code changes on the current branch. Follow these
steps:

1. Run "git diff main...HEAD" to see what changed.
2. For each changed file, read the surrounding context.
3. Look for: logic bugs, missing error handling, unsafe assumptions,
   test gaps, and style inconsistencies with the existing codebase.
4. Group findings by severity (blocker / nit) and write them as a
   short report with file references.

Do not make any edits. This is a read-only review.

That goes in .claude/skills/code-review/SKILL.md. Now whenever you ask Claude to "review the current branch," this skill is offered. It's read-only, so you can't accidentally have it editing files; the allowlist enforces that.

Slash command or skill — which?

Rule of thumb:

• Slash commandwhen the only thing that matters is the instructions. Short, scrappy, "I want a paragraph saved."
• Skill when you want structure: tool restrictions, supporting files, automatic surfacing on the right user request.

Start with slash commands. Upgrade to skills only when you find yourself wanting one of the things skills add. Don't over-engineer.

Sharing with a team

Project-level commands and skills live in .claude/ and are committed to git. Anyone who clones the repo gets them automatically. This is how teams converge on shared workflows without anyone having to set up tooling on their own machine.

If your team has a code-review style, a deploy procedure, or a common debugging recipe, encoding it as a skill turns the institutional knowledge into something a new hire (human or AI) can use on day one.