【Claude Code】カスタムSlash Commandの作り方とコマンド例を紹介する

投稿日: 2025年6月21日

この記事は人力で作成しました。誤字脱字の検出のみAIを使用しました。
Claude Code v1.0.31の内容です。

Oikonです。外資系企業でITエンジニアをしています。

5月22日のAnthropic社のエンジニア向けの発表があって以降、Claude Codeが話題になっています。多くの方がClaude Codeの使い方の試行錯誤をしている過渡期にあると個人的に感じています。

今回はカスタムSlash Commandについて、私の個人的な試行錯誤を共有したいと思います。先日𝕏にポストしたカスタムSlash Commandの詳細版です。

@tweet

また、いくつかリプライや引用ポストで他の方のカスタムSlash Commandをシェアしていただいたので、そちらも紹介したいと思います。

カスタムSlash Commandについて

Slash Command概要

Claude Codeは入力の際に/(スラッシュ)を打つことで、あらかじめ割り当てられた操作を実行できる**Slash Command（スラッシュコマンド）**が存在します。

以下はよく使う代表例です。

/init：CLAUDE.mdを作成
/clear：コンテキストウィンドウの初期化
/model：モデルの切り替え
/resume：会話履歴の復帰（最近追加された）
/release-note：リリースノートの表示

Slash Commandのそれぞれの概要は以下の記事で紹介しているのでよかったら読んでみてください（※v1.0.6の情報です）

Claude Codeの/ (スラッシュ)コマンドを全部試したので解説する

zenn.dev

このSlash Commandは独自コマンドを自分で作成することもでき、それをカスタムSlash Commandと呼びます。

カスタムSlash Commandの作り方

カスタムSlash Commandの作り方はとても簡単です。本当に簡単。

ディレクトリ.claude/commands/または~/.claude/commands/を作成
$COMMAND_NAME.mdを作成（$COMMAND_NAMEは自分で命名）
mdファイル内に指示を記述。

以上です！簡単！

ディレクトリcommands/のPathによる違いは、ProjectコマンドかPersonalコマンドかの違いです

.claude/commands/：Project固有コマンド。(project)
~/.claude/commands/: Personalコマンド。全てのprojectに反映。(user)

それぞれDescriptionに(project)もしくは(user)という文字が表示されます

公式コマンドのサンプル

公式ドキュメントに記載されたカスタムSlash Commandsのサンプルを紹介します。

optimize.md:

"Analyze this code for performance issues and suggest optimizations:"

security-review.md:

"Review this code for security vulnerabilities:"

カスタムSlash Commandは$ARGUMENTSで引数を取ることができます。

fix-issue.md

Fix issue #$ARGUMENTS following our coding standards

上記のようなfix-issue.mdはissue内容をコマンド実行時にIssue番号を指定して呼び出します。

/fix-issue 123

以下が公式ドキュメントです。内容が若干古くてprefixはv1.0.31では存在しません。

Extend Claude with skills - Claude Code Docs

Create, manage, and share skills to extend Claude's capabilities in Claude Code. Includes custom slash commands.

docs.anthropic.com

ちなみに完全に余談でオススメはしませんが、日本語名のカスタムSlash Commandは作成できます。コマンドの中身自体は日本語でもいいと思います。

OikonのカスタムSlash Commandの例

ここからはカスタムSlash Commandを掘り下げて、いくつかの例を見ていきたいと思います。

/bugfix

バグ修正用のコマンドです。バグの詳細を引数で渡してClaudeに解決を試みさせます。

問題再現をして原因を考察する
MCPサーバーとWeb Searchを複数のsub-agentsに実行させ、エラーに関する最新情報を取得し問題解決を行う
エラーが直らない場合、1と2を繰り返す
バグのレポートを記述する

# Fix bug from user provided bug description: $ARGUMENTS

## Goal

Recreate the issue and fix the bug

## Steps (obey strictly)

Bug description user provided: $ARGUMENTS

Step 1: Understand the bug description and think the root cause. Try to recreate the issue.
Step 2: Fix the error. Use `context7` and `brave-search` MCP tools to understand the error.
These MCP tool search should be done by multiple subagents. Also use native Web search subagent for issue investigation.
Step 3: If there is another error, always repeat this debugging process from Step 1 and Step 2.
Step 4: Report root cause and the solution.

/explain-project

最近はOSSプロジェクトをCloneして、Claude Codeに中身を聞くことが個人的に増えたので、プロジェクトの概要説明のコマンドを用意しています。

アーキテクトの役割を明示的に与えて説明させています。

リポジトリ解析
プロジェクト概要の作成
Markdownファイルに出力

Mermaid graph TDを指定すると作成してくれます。

# Explain project high-level architecture

You are a senior software architect and technical writer. You can use multiple subagents to analyze the repository.
You should not run the project but get/read it.

## Goal

Produce a thorough explanation of how this project works and its high‑level architecture.

## Generation steps (obey strictly)

Step 1. Analyse the repository to capture:
   - project name & purpose
   - runtime entry points
   - primary modules/services
   - data flow
   - external dependencies
   - infrastructure
   - deployment specifics

Step 2. Create Markdown with these sections exactly in order:

   1. Project Name – bold text
   2. Overview – concise paragraph (≤ 160 words)
   3. Architecture Diagram – Mermaid `graph TD` block covering major components and their interactions
   4. Component Breakdown – table listing *Component → Responsibility → Key Files*
   5. Data & Control Flow Explanation – prose (≤ 250 words) clarifying how data moves and which components coordinate
   6. Tech Stacks – bullets on build, provide the tech stacks overview

Step 3. No hard word limit, but keep writing purposeful; avoid fluff.

Step 4. Output Markdown only, no extra commentary beyond the sections above.

/feature-log

機能作成後にログをとるコマンドです。これはドキュメントの記録と後にContextに放り込むために作っています。

./log/feature/を明示しておけば、コマンド実行したときにlogが全てそこに記録されます。ディレクトリがなければ作る指示も加えています。

Markdownの中でログのフォーマットに関するMarkdown記述もできるのが特徴的だと思います。（Zennへの記述の関係で”““表記にしています）

# Create log file for feature, feature description: $ARGUMENTS

You are a meticulous release engineer.

## Goal

Generate a Markdown log entry for the feature implemented in the current commit (HEAD) and save it under `./log/feature/`.

## Behaviour specification (follow in order)

Step 1. Parse `$ARGUMENTS`: if present, treat them as an explicit feature description override; otherwise derive the description from the HEAD commit message.
Step 2. Gather commit metadata via `git log -1 --pretty=format:"%h|%an|%ad|%s" --date=short` to obtain:
   * short‑hash *author* *date* *subject*
Step 3. Identify changed files with `git diff-tree --no-commit-id --name-only -r HEAD`.
Step 4. Ensure the folder `./log/feature/` exists (create if missing).
Step 5. Create the log file `./log/feature/<date>-<feature>.md` (e.g. `2025-06-18-create-button.md`).
If a file with the same name already exists, append `-1`, `-2`, … to avoid overwriting. `<feature>` should be less than 20 characters.
6. Write Markdown content as follows:

   ``markdown
   # <subject or $ARGUMENTS>

   Commit: `<hash>`
   Author: <author>
   Date: <date>

   ## Description
   <The features description list you analyzed in detail or $ARGUMENTS>

   ## Modified Files
   - file/path/one
   - file/path/two
   ...
   ``

7. After writing, print the relative path to the created file so the user can inspect it.

/plan-to-checklist

Planモードの内容をチェックリストにしてもらうコマンドです。

Planモードができた時に、もう少し自分でPlanに手を加えたいなと思ってチェックリストに変換してもらうコマンドです。引数でファイル名を指定できます。

明示的にStepとチェックリスト[ ]を使ってもらい、このドキュメントをToDoリストとして使用してもらうようにしています。

# Convert Plan to Checklist document, document title: $ARGUMENTS

Step 1: Check the plan you created and convert it into a checklist in Markdown format. Copy it exactly.
Step 2: The task list should use checklist syntax `[ ]`. Begin each task phase with the word “Step.”
Step 3: Save the file to `./docs/plan/` with the filename `<$ARGUMENTS>.md`. If $ARGUMENTS is not provided, choose a filename you recommend that is fewer than 15 characters.

/test-report

テスト実行とテストレポート作成するコマンドです。

エラーログを含むTextファイルと要約のMarkdownファイルを、./log/testに出力してもらいます。

若干助長気味なので、もう少し簡略化した方が使いやすい気もしています。

# Run test and create report in ./log/test/

You are a senior test‑automation engineer.

## Goal

Execute the project’s entire test suite, collect coverage metrics, and save a concise, human‑readable report under `./log/test/`.

## Behaviour specification (follow strictly)

Step 1. Detect tech stack by reading config files:
   • JavaScript/TypeScript → Jest
   • Python → pytest
Step 2. Derive the test command and coverage flags (e.g. `--coverage`, `pytest --cov`, `go test -cover`).
Step 3. Ensure the folder `./log/test/` exists (create if necessary).
Step 4. Run tests in a clean environment (no watch mode, no interactive prompts) and capture:
   - exit code
   - console output
   - coverage summary (lines %, branches %, functions % where available)
Step 5. Save artifacts:
   - Raw console output → `./log/test/<date>-<hash>.txt`
   - Markdown summary → `./log/test/<date>-<hash>.md`
Step 6. Markdown summary must contain sections in order:
   1. `# Test Report (<date> – <hash>)`
   2. Summary – total tests, passed, failed, skipped, duration
   3. What kinds of tests you run
   4. Coverage – table with metric → percentage (omit if unavailable)
   5. Failed Tests – collapsible list (`<details>` blocks) with name & error snippet (max 20 lines each)
   6. Next Steps – bullet suggestions (retry, refactor, increase coverage)
Step 7. After writing files, print the relative paths to both artifacts.

他の方々の自作コマンド

𝕏（旧Twitter）で他の方のカスタムSlash Commandを聞いてみたら、いくつか自作コマンド例をいただいたので、勝手ながら紹介します。

コムテさん: blog記事作成

@tweet

技術ブログ記事を自動生成する/blogコマンドです。

個人開発者がプロダクト登録や技術記事を投稿できるizanami.devを運営しているコムテさんらしい自作コマンドだと思いました！

コマンドの中身も公開されていたので、この記事でも共有させていただきます。（Zennへの記述の関係で”““表記にしています）

# /blog

## 概要

最近の実装内容や技術的な取り組みを基に、技術ブログ記事を自動生成します。

## 実行内容

1. **実装履歴の分析**

   - 最近の git コミット履歴を確認
   - `_docs/`ディレクトリの実装ログを分析
   - 変更されたファイルとその内容を調査

2. **記事構成の生成**

   - 技術的な課題と解決方法
   - 実装のポイントと学び
   - コード例とベストプラクティス
   - 他の開発者への応用可能なナレッジ

3. **ブログ記事作成**
   - Markdown 形式で技術記事を生成
   - SEO を意識したタイトルと構成
   - 実際のコード例を含む実践的な内容
   - `_docs/blog/`ディレクトリに保存

## 記事テンプレート

- **タイトル**: 実装内容から魅力的なタイトルを生成
- **概要**: 何を解決したか、何を学んだか
- **技術スタック**: 使用した技術・ツール
- **実装内容**: 具体的な実装方法とコード例
- **学んだこと**: 失敗や改善点も含めた学び
- **まとめ**: 他の開発者への応用可能性

## 対象内容

- React/Next.js のコンポーネント開発
- TypeScript での型安全な実装
- テスト駆動開発（TDD）の実践
- パフォーマンス最適化
- ユーザー体験の改善
- 開発ツールの活用

## 出力例

``
_docs/blog/2025-06-19_Jestテスト環境の構築と包括的テストスイート.md
``

## 使用例

``
/blog
``

akirameiさん: fix-issueの改良

@tweet

公式のfix-issueに加えて、チケットとブランチの作成を明示的に指示しています。

やはりバグ修正系は高頻度で活用するのでカスタムコマンド化しておくのが良さそうですね。

こちらもMarkdownの中身を紹介させていただきます。

Find and fix issue #$ARGUMENTS. Follow these steps:

1. **FIRST** check if issue is open: `gh issue view $ARGUMENTS --json state -q .state` (must be "OPEN")
2. **IMMEDIATELY** create branch: `git checkout -b fix-issue-$ARGUMENTS` (DO THIS BEFORE ANY OTHER WORK!)
3. Now read issue details: `gh issue view $ARGUMENTS` to understand the issue
4. Locate the relevant code in our codebase
5. Implement a solution that addresses the root cause
6. Add appropriate tests if needed
7. Commit changes with proper commit message
8. Push the branch and create a PR using `gh pr create`
9. Prepare a concise PR description explaining the fix

**CRITICAL**: Always create the branch (step 2) immediately after confirming the issue is open. This prevents accidental commits to main branch.