一週間で四度目、同じ 200 字のプロンプトを入力している自分に気づいた。「ステージ済みの変更に対してコンベンショナルコミットメッセージを書いてください。最初の行は 72 文字以内、ブランチ名に issue 番号があればそれを本文で参照してください……」毎。回。この瞬間こそ、手を止めてスラッシュコマンドを作るタイミングだ。Claude Code のスラッシュコマンドとスキルを設定して、二度と同じことを書かないようにしよう。
どちらの機能も基本的には同じことをする――指示をパッケージ化して再利用できるようにする――が、目的は異なる。スラッシュコマンドは自分がトリガーするものに使う。スキルは、タスクが必要としたときにClaude が自動的に呼び出すものに使う。この違いを押さえれば、あとは簡単だ。
スラッシュコマンド：自分だけのショートカット
スラッシュコマンドは保存したプロンプトで、/名前 で呼び出す。プロジェクト内の .claude/commands/ にマークダウンファイルを置けば作れる。ファイル名がそのままコマンド名になる。
コミットメッセージのプロンプト問題に決着をつけよう。.claude/commands/commit.md を作成する：
現在ステージ済みの変更に対してコンベンショナルコミットメッセージを書いてください。
ルール：
- 最初の行は 72 文字未満、命令形（"Add" であり "Added" ではない）。
- タイププレフィックス：feat、fix、refactor、docs、test、または chore。
- ブランチ名に issue 番号が含まれている場合は、本文で参照する。
- メッセージを見せてください。自分で git commit を実行しないこと。
まず `git diff --staged` を実行して変更内容を確認してください。
これでどのセッションでも /commit と入力するだけで Claude がすべてやってくれる。200 字の代わりに 7 文字。ファイルそのものがコマンドだ――その中身が、呼び出したときに自分のプロンプトとして送信される。
引数を渡す
入力を受け取れるようにするとコマンドがさらに便利になる。$ARGUMENTS をプレースホルダーとして使う。以下は .claude/commands/explain.md：
このコードベースで $ARGUMENTS がどのように機能するか説明してください。
定義されている場所を見つけ、使われ方を追跡し、簡単な平易な日本語で要約してください。
会話がファイルの中身で埋まらないよう、検索にはサブエージェントを使ってください。
そうすると /explain 認証フロー と入力するだけで「認証フロー」がその場所に入る。コマンド一つ、使い方は無限。今では /test、/review、/changelog など十数個を持っており、日々のボイラープレート作業がそっくり消えた。
スキル：Claude が自分で呼び出す指示
スラッシュコマンドは自分が何をしたいかわかっているときに便利だ。でも、タスクの途中で Claude に自動的に専門知識を適用してほしいとき――何かを呼び出すことを覚えていなくても――がある。それがスキルだ。
スキルは SKILL.md ファイルを持つフォルダだ。ファイルの冒頭にはスキルがいつ適用されるかが記述されている。Claude はその説明を念頭に置き、タスクが一致したとき、自分で完全な指示を読み込む。コマンドを入力する必要はない。自然に起きる。
チームがデータベースマイグレーションの書き方について厳格な決まりを持っているとしよう。.claude/skills/migrations/SKILL.md を作成する：
---
name: migrations
description: このプロジェクトでデータベースマイグレーションを書く方法。
マイグレーションファイルを作成・編集・レビューするときに使用。
---
マイグレーションは db/migrations に置き、UTC タイムスタンプのプレフィックスで命名する。
各マイグレーションは必ず：
- 可逆にする――up と down の両方を含める。
- 書き込みを停止したのと同じマイグレーションでカラムを削除しない。
2 回のデプロイに分ける。
- スキーマ変更をトランザクションで囲む。
書く前に、スタイルを合わせるために直近の 3 つのマイグレーションを読むこと。
これで Claude に「新しい archived_at カラムのマイグレーションを追加して」と頼むと、タスクがスキルの説明と一致することに気づき、このルールを読み込んで従ってくれる――「スキル」という言葉を言わなくてもだ。これが魔法だ。知識は必要なときにだけ現れ、それ以外は邪魔をしない。
どちらを作ればいい？
自分が使っているシンプルな基準を紹介する。
スラッシュコマンドを作るのは、自分がいつ実行するかを決めるとき。コミットメッセージ、変更履歴の生成、特定レビューの開始――これらは意図的なアクションだ。自分で呼び出す。
スキルを作るのは、Claude が判断すべきとき。コーディング規約、ドメインルール、フォーマット基準――一致するタスクが来たとき自動的に適用されるべきもの。データベースに触れるたびに /migrations を入力することを覚えていたくない。ルールはただそこにあってほしい。
良い判断基準：文が「Claude が X をするときはいつでも、それをすべき……」で始まるなら――それはスキル。「ときどき自分は……したい」で始まるなら――それはコマンド。
description が荷重を担う部分
スキルにとって特に description の行はすべてだ。Claude がスキルを適用するかどうかをここで判断する。曖昧な説明では、スキルは永遠に発動しない。トリガーについて具体的に書こう：「マイグレーションファイルを作成・編集・レビューするときに使用」は、Claude にいつ起動すればいいかを正確に伝える。「データベース系のもの」では通じない。
これはツールの説明文をうまく書くのと同じエネルギーだ。今まさに「これは関係あるか？」を判断しなければならないエージェントのために書いている。明確な yes/no を与えよう。
一番煩わしいものから始める
一度に二十個作ろうとしないこと。本当に必要なものを間違えてしまう。代わりに、摩擦を感じるまで待つ――四度目の同じ入力、何度も説明するあのルール――そしてそれを作る。その瞬間に。二分でできて、効果は即座だ。
自分のコレクション全体がそうやって育ってきた、一つの苛立ちから次へと。コミットコマンドはコミットプロンプトを繰り返し入力することから生まれた。マイグレーションスキルは同じマイグレーションミスを二度犯したことから生まれた。それぞれが、具体的に指摘できる実際の問題を解決した。
だから、これが宿題だ。次に以前入力したプロンプトを入力している自分に気づいたら、止まること。.claude/commands/ を開き、ファイルを作り、プロンプトを貼り付ける。今この瞬間、あの二分間のすべての将来のコピーを取り戻した。それを十回やれば、Claude Code のセットアップがありきたりに感じなくなり、自分のもののように感じ始める。