Saving your work as slash commands

From one-time task to permanent shortcut

In page 2, you learned the basic idea: do a task interactively, then ask Claude Code to save it as a slash command. That's the fastest path — and for many workflows, it's all you need.

But now that you've built up a toolkit of automation patterns (file operations, text processing, templates), it's worth understanding how slash commands work, where they live, and how to get the most out of them.

This page covers the mechanics: creating commands, organizing them, making them flexible with arguments, and sharing them with your team.

What a slash command actually is

A slash command is a text file. That's it.

It's a file containing the instructions you want Claude Code to follow, saved in a specific folder. The file's name becomes the command name. When you type /weekly-report, Claude Code finds the file called weekly-report.md, reads the instructions inside, and follows them.

There's no special syntax. You write the instructions in plain language, the same way you'd type them into a conversation. The only difference is that instead of typing those instructions every time, you type the command name.

Think of it like a recipe card in a box. Instead of explaining the recipe from memory each time, you pull out the card and hand it over.

Creating a slash command

You have two options.

Option 1: Ask Claude Code to create it (recommended).

After you've run a task interactively and the result looks right, tell Claude Code to save it:

That's exactly what I needed. Save this as a slash command called /feedback-summary so I can run it whenever I get a new batch of feedback files.

Claude Code writes the instruction file and puts it in the right folder. You don't need to touch anything.

Option 2: Create the file yourself.

If you want to write a command from scratch, or edit one Claude Code created, you can.

The file goes in your project's .claude/commands/ folder. If that folder doesn't exist, create it. The file is a plain text file with a .md extension.

For example, to create a /weekly-report command, you'd create a file at:

.claude/commands/weekly-report.md

Inside the file, write the instructions in plain language:

Read the CSV file provided as input. It contains this week's
support ticket data with columns for ticket_id, category,
created_date, resolved_date, and status.

Clean the categories (merge duplicates and fix typos).
Calculate: total tickets, tickets by category, average
resolution time, and tickets that took longer than 24 hours.

Save the cleaned data as cleaned-tickets.csv.
Save the summary as weekly-summary.md.

That's the entire file. No code, no special formatting. Just the instructions you'd normally type into the conversation.

Making commands flexible with arguments

Most useful commands need to work with different inputs each time. The weekly report needs this week's file, not last week's. The feedback summary needs to point at the right folder.

This is where $ARGUMENTS comes in.

When you type /weekly-report tickets_week14.csv, everything after the command name gets inserted wherever $ARGUMENTS appears in your instruction file. In this case, tickets_week14.csv replaces $ARGUMENTS.

Here's what the file looks like with arguments:

Read the file $ARGUMENTS. It contains this week's support
ticket data with columns for ticket_id, category, created_date,
resolved_date, and status.

Clean the categories (merge duplicates and fix typos).
Calculate: total tickets, tickets by category, average
resolution time, and tickets that took longer than 24 hours.

Save the cleaned data as cleaned-tickets.csv.
Save the summary as weekly-summary.md.

Now /weekly-report tickets_week14.csv processes that specific file, and /weekly-report tickets_week15.csv processes the next one.

If you don't include $ARGUMENTS in your file, the text you type after the command name is still passed along to Claude Code as part of the instructions. It still works, but putting $ARGUMENTS exactly where you want it gives you more control.

Where to save them

Slash commands can live in two places, and where you put them changes who can use them.

Project commands go in your project folder:

your-project/.claude/commands/weekly-report.md

These are available whenever you're working in that project. If you share the project folder with colleagues (or store it in a shared drive), they get the commands too.

Personal commands go in your home folder:

~/.claude/commands/weekly-report.md

Plain language: The ~/ at the beginning means "your home folder" — the main folder for your user account on your computer. On a Mac, that's usually /Users/yourname/.

Personal commands are available in every project you work on, but only for you. They don't get shared when you share a project.

Which one should you choose?

Use project commands when the workflow is tied to a specific project. A /weekly-tickets command that processes support data using your team's specific categories belongs with the project.

Use personal commands when the workflow is general-purpose. A /summarize-folder command that reads all files in any folder and creates a summary works anywhere — save it as a personal command.

Real examples from non-developers

Here are slash commands that people in non-technical roles have built, following the same pattern you've practiced in this module.

A content marketer created /headlines to take a block of text and generate five headline options with different angles. A product manager uses /competitive-research to search the project folder for notes on a given company, summarize what's known, and flag gaps. An operations manager runs /today every morning — it reads a task list and a calendar export, then generates a prioritized daily plan.

You've already seen two of these workflows in earlier pages. The Dan Shipper expense report from page 5 becomes /expense-report: drop transaction files in a folder, run the command, get a categorized HTML report. The feedback categorization from page 4 becomes /feedback-summary: point it at a folder of customer feedback files, get a report with counts and representative quotes.

Improving your commands over time

Slash commands aren't set in stone. They get better as you use them.

The first time you run /weekly-report, the output might be almost right but not quite. Maybe the formatting is off, or it calculates averages differently than you want.

You have two options:

Fix it in conversation. After the command runs, tell Claude Code what to change. Then say: "Update the /weekly-report command to include this fix." Claude Code edits the instruction file so the fix applies every time.

Edit the file directly. Open the .md file in any text editor, change the instructions, and save. Next time you run the command, it uses the updated version.

The first approach is easier. The second gives you more control when you want to make bigger changes.

Over time, your commands accumulate the lessons you've learned. Edge cases you ran into. Formatting preferences. The specific ways you want data categorized. A command you've refined over a few weeks is worth far more than the one-off version.

Testing a command

Before relying on a new command for real work, test it.

Run the command with a sample input. Review the output. Run it again with a different input to make sure it handles variation.

If you're sharing the command with colleagues, have someone else try it. Instructions that make sense to you might confuse Claude Code when someone else's files have a slightly different format. You wrote those instructions with your own context in mind.

A quick test: if you handed the instructions in the file to a colleague with no context, would they know what to do? If not, add more detail.

The skill creator shortcut

If you'd rather not write a command from scratch, there's a shortcut. You can ask Claude Code to interview you about what you want, then build the command from your answers.

I want to create a slash command for my monthly client reports. Interview me about what the command should do — ask me about the input files, what analysis I need, and how I want the output formatted. Then create the command.

Claude Code asks you a series of questions: What files does it work with? What should it calculate? What does the output look like? Where should it save results?

After the interview, it creates the command file. This works well when you know the general outcome you want but aren't sure how to describe every step upfront.

What's next

You now have the tools to create, organize, and share slash commands.

Next up: what to do when automation doesn't go as planned. Silent file overwrites, scope creep, permission fatigue, and the traps that catch non-developers most often.