What Are Custom Commands?

Create a .claude/commands/ folder inside your project and drop in a Markdown file.
The filename becomes a slash command — instantly, no configuration needed.

.claude/
    commands/
      commit.md   →  /commit
      blog.md     →  /blog

Type /commit and Claude runs whatever prompt you wrote in commit.md.
No more re-explaining. One command, done.

Two Commands I Actually Built

/commit — Auto-Draft Commit Messages

Writing commit messages after every change felt like unnecessary overhead.
So I made a command that reads the diff and drafts one for me.

.claude/commands/commit.md

Analyze the current git changes and write a commit message.

  1. Run `git diff HEAD` to review the changes
  2. Run `git status` to see which files changed

  Output in the format below. Do NOT actually commit.

  **Summary (one line)**
  Start with a verb. Capture the core change in one line.

  **Description**
  - Focus on what changed and why, not how
  - Keep it human-readable, not jargon-heavy
  - 10 lines max

Type /commit and Claude reads the diff, drafts the message, and shows it to you.
No auto-commit — you review and paste it yourself.

/blog — Turn Today's Work into a Dev Diary

Writing blog posts after coding sessions was always getting pushed off.
So I made a command that analyzes today's commits and writes the post for me.

.claude/commands/blog.md

Write a Korean developer diary blog post based only on today's
  commits.
  Wrap the entire output in a ```markdown ... ``` code block.
  Do not add any text outside the block — output must be copy-paste ready.

  Steps:
  1. Run git log --since="today" --oneline to find today's commits
  2. Run git show <hash> for each commit to understand the actual changes

  Structure:
  # [Date] Dev Diary — [one-line summary]
  ## Context
  ## What I Did (use ```swift blocks for code)
  ## Where I Got Stuck (skip if none)
  ## What's Next
  ## Wrap-up

  #tag1 #tag2 #tag3 #tag4 #tag5

Type /blog and Claude reads today's commits, writes the full post, and wraps it in a Markdown block ready to copy and publish.

Tips From the Community

1. Accept Input with $ARGUMENTS

Put $ARGUMENTS anywhere in your command file and it gets replaced with whatever you type after the command name.

# fix.md
  Analyze and suggest a fix for this issue: $ARGUMENTS

/fix Login button triggers twice on double-tap

$ARGUMENTS becomes "Login button triggers twice on double-tap" — no extra setup needed.

2. Project-level vs Personal Commands

Put personal workflows in your home directory. Put team conventions in the project.

3. Pre-approve Tools with allowed-tools

Add a YAML frontmatter block to pre-authorize specific tool calls.
Claude won't ask for permission every time it needs to run git.

---
  description: Analyze git changes and draft a commit message
  allowed-tools: Bash(git diff *) Bash(git status *) Bash(git log *)
  ---
  Your prompt here...

4. When to Create a Command

"If you've typed the same prompt twice, it belongs in a command file."

That's the signal. One-off requests stay in the chat.
Recurring workflows become commands.

5. Commands vs CLAUDE.md — Know the Difference

CLAUDE.md tells Claude how your project works.
Commands tell Claude what to do when you ask.

How to Get Started

Run this in your project root and you're set up:

mkdir -p .claude/commands
  touch .claude/commands/commit.md

Open Claude Code and type / — your new command will appear in the list immediately.

Wrapping Up

Custom commands are just saved prompts with a shortcut.
One Markdown file. One slash. No more repeating yourself.
Start with whatever you find yourself re-typing most — that's your first command.