Claude Code Commands

Commands are saved instructions stored as simple text files that you run by typing a forward slash followed by the command name. Type /morning and Claude reads your saved morning-briefing instructions and runs them. Type /backup and it commits your work and pushes it to GitHub. Think of commands as keyboard shortcuts for complex, multi-step tasks -- ones you do regularly and don't want to re-explain every time.

The key thing that makes commands useful: they run against your live workspace. A /status command doesn't give you a generic status update -- it reads your actual project files and tells you where things stand right now. Commands are dynamic. They're instructions, not static text.

Commands vs skills -- what's the difference?

Both commands and skills are text files that Claude runs when you type a slash. The convention that distinguishes them:

• Commands are operational sequences -- they change workspace state, generate briefings from live data, commit work, or run routine checks. Short names, frequent use. Examples: /day, /sync, /night, /status
• Skills are production workflows -- they create a deliverable: a document, a social post, a report, a proposal. Descriptive names, task-specific. Examples: /writing-proposals, /processing-pdfs, /linkedin

In practice, the distinction is a naming and organisational convention, not a technical one. A command is a simpler file with fewer sections; a skill may include reference documents, example outputs, and trigger patterns. Start with commands -- they're easier to build.

Where commands live

├── commands/
│   ├── day.md          ← /day
│   ├── sync.md         ← /sync
│   ├── night.md        ← /night
│   └── status.md       ← /status
└── skills/
    ├── linkedin/
    └── processing-pdfs/

Each file in .claude/commands/ becomes a slash command automatically. The filename becomes the command name -- morning.md becomes /morning, weekly-review.md becomes /weekly-review.

Three commands worth building first

/day -- morning briefing

A morning command reads your workspace state, checks what was left unfinished last session, and gives you a prioritised list of what to work on today. Once written, you open a session, type /day, and Claude gives you a structured briefing based on your actual live data -- no re-explaining the context, no guessing where you left off.

# /day -- Morning Briefing

## Steps
1. Read .claude/state/state.json -- identify active projects
2. For each in-progress project, read its detail file
3. Check what was stopped mid-session (stoppedAt field)
4. List: what's most urgent, what was in progress, what's blocked
5. Suggest the single best starting point for today

/sync -- save progress mid-session

A sync command commits your current work to version control (the system that keeps a history of every change you make to files) and pushes it to a remote backup. Run it whenever you complete a significant chunk of work. If something goes wrong -- a file gets corrupted, a change needs reversing -- you have a clean saved point to return to.

# /sync -- Save Progress

## Steps
1. Check git status -- list all changed files
2. Stage all modified files
3. Write a descriptive commit message summarising what changed
4. Push to origin remote
5. Confirm what was saved

/status -- project health check

A status command reads all your active projects and presents a structured overview: what's in progress, what's overdue, what's paused and why. Useful at the start of a week or before a planning session. Instead of trying to remember where everything stands, you type one command and Claude reads it from the files you've been maintaining.

How to create a command from scratch

1. Open your workspace and navigate to .claude/commands/ (create the folder if it doesn't exist)
2. Create a new file with the name you want to type: e.g. morning.md for /morning
3. Write a clear heading and list the steps Claude should follow
4. Save the file -- the command is immediately available in the next session

A good command file answers three questions: what is the purpose, what steps should be followed in order, and what should the output look like. You don't need special syntax -- plain numbered steps work well.

Passing information to a command

Commands can accept arguments -- extra information you type after the command name. Everything you type after the command name is available inside the file as $ARGUMENTS.

# User types:
/add-project "Johnson Consulting retainer"

# Inside the command file, $ARGUMENTS = "Johnson Consulting retainer"
# Claude uses it to create a new project with that name

This turns a general command into a specific action. A /add-project command with a name argument is more useful than a /add-project command that then asks you what to call it.

Built-in vs custom commands

Claude Code ships with a set of built-in system commands you can use immediately, without creating any files. These are reserved names -- creating your own file with the same name won't replace them:

Custom commands you create sit alongside these -- they don't interfere with each other as long as you don't reuse a reserved name.

Naming conventions

Keep command names short and action-oriented. Good command names read like verbs: /day, /sync, /review, /backup. Avoid names that clash with built-in commands (/help, /clear, /init). Use hyphens for multi-word names: /weekly-review, /end-of-month. No spaces, no underscores.