Sign in Subscribe

Day 11: What Slash Commands Are and Your First Custom One

Learn what slash commands are in Claude Code and create your first one. Save repeated prompts as shortcuts, use them with one line. Setup takes 2 minutes.

Day 11: What Slash Commands Are and Your First Custom One

Hey, it's G.

Day 11 of the Claude Code series. New track: Slash Commands.

I was typing the same long prompts over and over in Claude Code.

Every session. "Review this file for TypeScript errors and suggest fixes without changing the logic."

Every. Single. Time.

Today I learned that slash commands let you save any prompt as a shortcut and call it with one line.

It's one of those features that feels small until you start using it daily.

Let me show you what changed.

The Problem (Repeating Myself Every Session)

Here's what I was doing before slash commands:

Monday:

> Review this file for TypeScript errors and suggest fixes 
> without changing the logic

Tuesday:

> Review this file for TypeScript errors and suggest fixes 
> without changing the logic

Wednesday:

> Review this file for TypeScript errors and suggest fixes 
> without changing the logic

You get the idea.

Same prompt. Different files. Over and over.

Other prompts I kept repeating:

  • "Look at today's git log and write a standup update"
  • "Find all TODO comments in this file and list them"
  • "Explain what this function does in simple terms"
  • "Check if this component follows our naming conventions"

Each one was:

  • 20-50 words to type
  • Easy to mess up slightly
  • Annoying to copy-paste from previous sessions

There had to be a better way.

The Concept (Slash Commands Are Reusable Prompt Shortcuts)

Slash commands are saved prompts you can call with one line.

Instead of typing the same long prompt every session, you:

  1. Save it once as a markdown file
  2. Call it with /command-name whenever you need it

That's it.

They live in a .claude/commands/ folder at the root of your project.

Each command is just a markdown file. The filename becomes the command name.

Example:

.claude/commands/review.md → /review
.claude/commands/standup.md → /standup
.claude/commands/explain.md → /explain

Two types of slash commands exist:

Project Commands

  • Location: .claude/commands/ inside your project
  • Availability: Only when working in that project
  • Good for: Project-specific workflows

Personal Commands

  • Location: ~/.claude/commands/ on your machine
  • Availability: Every project you work on
  • Good for: Workflows you use everywhere

Think of them like keyboard shortcuts for your most repeated Claude Code prompts.

You define them once. Use them forever.

How To Create Your First Slash Command

Step 1: Create the Commands Folder

For project-specific commands:

mkdir -p .claude/commands

For personal commands (available everywhere):

mkdir -p ~/.claude/commands

I recommend starting with project commands first. Once you find yourself using the same command across multiple projects, move it to personal commands.

Step 2: Create Your First Command File

Let's create a code review command:

touch .claude/commands/review.md
code .claude/commands/review.md

The filename becomes the command name.

review.md → you'll call it with /review

Step 3: Write Your Prompt Inside the File

Inside .claude/commands/review.md:

Review the current file for the following issues:
- TypeScript errors or unsafe types
- Logic bugs or edge cases not handled
- Any violation of our coding conventions in CLAUDE.md
- Performance issues

Do not make any changes. Just report what you find 
and suggest fixes for each issue you spot.

That's the entire file. Just your prompt as plain text markdown.

Step 4: Use It Inside Claude Code

cd ~/projects/my-app
claude

> /review

Claude Code runs your saved prompt instantly.

No retyping. No copy-paste. Just /review and done.

Step 5: Commit It So Your Team Gets It Too

git add .claude/commands/
git commit -m "add claude code slash commands"

Now everyone on your team can use /review.

Real Example (My Actual First Command)

Folder Structure After Setup

resiboko/
├── .claude/
│   └── commands/
│       └── review.md    ← my first command
├── CLAUDE.md
├── app/
├── components/
└── ...

Inside .claude/commands/review.md

Review the current file for the following:

1. TypeScript errors or unsafe `any` types
2. Logic bugs or edge cases not handled  
3. Violations of our CLAUDE.md coding conventions
4. Performance issues or inefficient patterns

Do not make any changes to the code.
Just report what you find and suggest fixes for each issue.

Using It

cd ~/projects/resiboko
claude

# Open a component file
> view components/ExpenseForm.tsx

# Run the review command
> /review

Claude responds:

Reviewing components/ExpenseForm.tsx:

Issues found:

1. TypeScript: Line 45 uses `any` for formData parameter
   Fix: Replace with proper type: FormData

2. Logic bug: Line 89 doesn't validate amount is positive
   Fix: Add validation: if (amount <= 0) return error

3. CLAUDE.md violation: Line 12 uses default export
   Fix: Change to named export

4. Performance: Line 34 creates new array on every render
   Fix: Move to useMemo hook

No changes made. All issues reported above.

Perfect. Exactly what I needed. Zero typing.

Personal Commands (The Real Unlock)

Project commands are great for project-specific workflows.

But personal commands are available in every project.

My Favorite Personal Command: Standup

Create it once:

touch ~/.claude/commands/standup.md

Inside the file:

Look at the git log for today and summarize what was 
accomplished in 3-5 bullet points. 

Write it in the format of a daily standup update:
- What was done
- What's next
- Any blockers

Keep it concise and action-oriented.

Use it every morning:

cd ~/projects/any-project
claude

> /standup

Claude responds:

Daily Standup — March 11, 2026

What was done:
- Added Zod validation to expense form
- Fixed date formatting bug in utils/dates.ts
- Deployed v1.2.3 to production

What's next:
- Build subscription billing UI
- Add Stripe webhook handlers

Blockers:
- None currently

5 minutes saved. Every single day.

More Useful Personal Commands

Command: Explain

File: ~/.claude/commands/explain.md

Explain what the current file or function does in simple terms.

Break it down:
- What is the main purpose?
- What are the key steps or logic?
- What are the inputs and outputs?

Use plain English, avoid jargon.

Usage: When jumping into unfamiliar code.

Command: Todos

File: ~/.claude/commands/todos.md

Find all TODO, FIXME, and HACK comments in the current file.

For each one, list:
- Line number
- The comment text
- Suggested priority (high/medium/low)

Sort by priority.

Usage: Before committing or during code cleanup.

Command: Test

File: ~/.claude/commands/test.md

Look at the current file and suggest what tests 
should be written for it.

For each suggested test:
- What function or behavior it tests
- What the test case should cover
- Expected input and output

Do not write the tests — just suggest what should be tested.

Usage: When you know you need tests but don't know where to start.

Project-Specific Command Examples

Command: Conventions

File: .claude/commands/conventions.md

Check if this file follows all our CLAUDE.md conventions:
- Named exports only (no default exports)
- TypeScript strict mode (no `any` types)
- Tailwind utility classes only (no inline styles)
- Components under 150 lines

Report any violations found.

Usage: Before committing new files.

Command: Security

File: .claude/commands/security.md

Review this file for common security issues:
- SQL injection vulnerabilities
- XSS vulnerabilities
- Exposed API keys or secrets
- Insecure authentication patterns
- Missing input validation

Flag anything suspicious.

Usage: Before deploying to production.

Best Practices (What Actually Works)

1. Keep Commands Short and Focused

❌ Bad (tries to do too much):

Review this file for TypeScript errors, suggest performance 
improvements, check conventions, write tests, and also explain 
what the file does and create documentation for it.

✅ Good (one job per command):

Review this file for TypeScript errors only.
Report findings without making changes.

Then create separate commands for:

  • /perf → performance review
  • /conventions → convention check
  • /explain → explanation
  • /docs → documentation generation

2. Make Commands Reusable Across Files

❌ Bad (too specific):

Review components/ExpenseForm.tsx for TypeScript errors

This only works for one file.

✅ Good (works for any file):

Review the current file for TypeScript errors

Now it works for every file in your project.

3. Be Clear About Output Format

❌ Vague:

Find problems in this file

✅ Specific:

Find TypeScript errors in this file.

For each error:
- Line number
- What's wrong
- Suggested fix

Do not make changes — report only.

4. If You Edit a Command Every Time, Split It

If you find yourself editing a command before using it:

> /review
# Wait, actually I only want TypeScript errors this time...
# Edit the review.md file...
# Then run /review

That command is doing too much.

Split it:

  • /review → full review
  • /types → TypeScript errors only
  • /bugs → logic bugs only

How To Discover What Commands You Need

Don't try to plan your entire command library upfront.

Instead, notice your patterns:

Pattern 1: You Type the Same Prompt Twice

First time:

> Review this for TypeScript errors

Second time (same prompt, different file):

> Review this for TypeScript errors

→ Create /types command.

Pattern 2: You Copy-Paste From Previous Session

If you're scrolling back in your Claude Code history to find and copy a prompt you used before...

→ That prompt should be a command.

Pattern 3: You Have a Routine Task

Every morning: check git log, write standup
→ Create /standup command.

Before every commit: check conventions
→ Create /conventions command.

Before every PR: review for issues
→ Create /review command.

My Raw Notes (Unfiltered)

Why did I not know about this earlier. Been typing the same review prompt for months.

The personal commands folder (~/.claude/commands/) is the real unlock — one set of commands that works across every project.

The standup command alone saves me 5 minutes every morning.

Keep the command files short and focused — one job per command.

If you find yourself editing a command prompt every time you use it, it's too specific and needs to be broken into two commands.

Started with 3 commands. Now have 12. The library builds naturally as you notice patterns.

Tomorrow (Day 12 Preview)

Topic: Building a Slash Command Library — the commands every developer should have saved and how to build your personal collection.

What I'm sharing: My complete slash command library (12 commands), what each does, and the exact prompt text you can copy.

Following This Series

Phase 2 (Days 8-14): Getting Productive ⬅️ You are here

So far in Phase 2:

  • Day 8: CLAUDE.md structure and sections
  • Day 9: Writing rules Claude actually follows
  • Day 10: Evolving CLAUDE.md over time
  • Day 11: Slash commands basics (today)
  • Day 12: Building your command library (tomorrow)

G

P.S. - Create your first slash command today. Just one. Pick the prompt you type most often and save it as .claude/commands/[name].md. You'll use it within the hour.

P.P.P.S. - Personal commands (~/.claude/commands/) > project commands for most workflows. Start there unless the command is truly project-specific.

P.P.P.S. - The standup command is the single highest-ROI slash command I've created. 5 minutes saved every morning = 20+ hours per year.