TL;DR
- プロジェクトの
.claude/skills/verify/SKILL.mdにスキルを置くと、コミットの前に verify が実行される。SKILL.md の description にコミットのことを書き足す必要はない- ただし、verify が必ず実行されるとは限らない。私の実開発では実行されなかった回があった（原因は未確認）
- verify の SKILL.md には、アプリを起動して変更を画面で確かめる手順を書く。型チェックやテストは pre-commit や CI に置く
対象読者: Claude Code のスキルを普段から使っていて、verify スキルをコミット前の確認に使いたい人。
verify の経緯
Claude Code の組み込みの /verify は、アプリを起動して変更を実際に動かして確かめるスキルです。Claude Code の changelog で verify に触れた項目は、次の3つです（2026-10-10 確認）。/verify が最初に入ったバージョンは、changelog からは見つかりませんでした。
- 2.1.205: プロジェクトの verify スキルが、セッションのたびに書き直される不具合が直った。この時点で、組み込みの
/verifyはプロジェクトに.claude/skills/verify/SKILL.mdを書き残していた - 2.1.215: Claude が
/verifyを自分の判断で実行しなくなった。人が/verifyと打ったときだけ動く - 2.1.286: プロジェクトかユーザーのスキルに
verifyという名前のものがあると、Claude はコミットの直前にそれを実行するよう指示されるようになった。docs だけ、テストだけのコミットは除く
2.1.286 で変わったのは、組み込みの /verify そのものではなく、verify という名前のスキルをコミットの前に実行させる指示です。この記事は、この 2.1.286 の変更を扱います。
verify がコミット前に呼ばれる仕組み
公式 docs の skills ページの「Run your checks before each commit」節は、次のように説明しています（2026-10-07 確認）。
"When a session starts with a skill named
verifyorsimplifyin place, Claude Code's commit instructions tell Claude to run it right before each commit, except for changes to docs or tests."
Claude Code は、セッションの開始時に verify という名前のスキルがあると、コミットについての指示（commit instructions）に「コミットの直前に verify を実行する」を加えます。docs やテストだけの変更は対象外です。Claude Code が加えるのは指示で、verify を実際に呼ぶかどうかは Claude が判断します。
ここでいう名前は、スキルのディレクトリ名（.claude/skills/verify/）か、SKILL.md の name: です。私の環境では、どちらも verify でした。commit instructions がどちらを見ているかは未確認です。
先行記事として、suwa_nobu さんの「スキルの名前を verify にするだけで、Claude Code はコミット前にそれを実行する」（https://qiita.com/suwa_nobu/items/cc0fb4a9e10100991bba 、2026-10-01）があります。suwa_nobu さんは Claude Code 2.1.285 と 2.1.286 で claude -p を30回実行し、スキル名が verify なら Claude がコミットの前にそのスキルを呼ぶことを示しました。suwa_nobu さんの試験の依頼文は「このリポジトリの変更をコミットして」だけで、description はコミットに触れない文です。私はこの記事で、実装からコミットまでを頼む場合と、description にコミットのことを書いた場合を試しました。
私が「description 次第」だと思った理由
題材は、私が個人で開発している Next.js の公開リポジトリ fgo-farming-solver です。私は組み込みの /verify を使い、開発サーバーの起動手順を SKILL.md に書き残させました。この SKILL.md の description は次の文で、コミットには触れていません。
fgo-farming-solver の変更を、dev server を自分で起動してブラウザ実画面で確かめる手順。UI（app/, components/）や /api の変更を実機で検証するときに使う。
この状態で、私は Claude に機能の実装からコミットまでを2回頼みました。2回とも、Claude は verify を呼ばないままコミットに進みました。
次に、私は description に「UI や /api を変えたら、コミットの前に必ず使う（docs やテストだけの変更は除く）。」の1文を足して、もう1回頼みました。この回では、Claude はコミットの前に verify を呼びました。
私はこの結果から「verify も普通のスキルと同じで、description で呼ばれるかが決まる」と考え、この1文を足す PR #118 をマージしました。
この判断は、呼ばれなかった2回と呼ばれた1回の比較だけに基づいていました。また、この3回は description 以外の条件も違っていました（「呼ばれなかった回の条件」の節に書きます）。そこで私は、条件をそろえて試し直しました。
試験の条件
- Claude Code 2.1.292、
claude -p（非対話の print モード）、権限モードは auto - 同じ worktree を使い、各回の前に変更をリセットした
- 題材: ナビのメニュー表記「ボックスイベント / Box Events」を「イベント / Events」に変える1行の UI 変更。docs やテストだけの変更ではないので、commit instructions の対象外には当たらない
- 頼み方 A（実装からコミットまで）: 「ナビ（components/common/nav.tsx）の /events のラベルを『イベント / Events』に変えて、コミットまで進めて。push と PR 作成はしない。」
- 頼み方 C（コミットだけ）: 同じ変更を作業ツリーに入れておき、「このリポジトリの変更をコミットして。push と PR 作成はしない。」
- description D0: 上の、コミットに触れない文
- description D1: D0 に「UI や /api を変えたら、コミットの前に必ず使う（docs やテストだけの変更は除く）。」を足した文
- 順番: A-D0、A-D1、C-D0、C-D1 を1巡とし、3巡で計12回
- 判定: 各回の transcript で、Claude の Skill(verify) 呼び出しが git commit の実行より前にあるか
- 1巡目のうち5回は、auto モードの安全判定が応答せず、Claude が編集やコマンドを実行できなかった。私はこの5回を数えず、同じ条件でやり直した
transcript から順番を抜き出す方法
Claude Code は、会話の記録（transcript）を ~/.claude/projects/<作業ディレクトリを変換した名前>/<セッションID>.jsonl に保存します。claude -p に --session-id を渡して起動すると、どのファイルを見ればよいかがわかります。
次の jq コマンドは、Claude のスキル呼び出しと git commit の実行を、起きた順に抜き出します。
jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use")
| if .name=="Skill" then "Skill:" + .input.skill
elif (.name=="Bash" and (.input.command | test("git commit"))) then "git commit"
else empty end' ~/.claude/projects/<dir>/<session-id>.jsonl
Claude がコミット前に verify を呼んだ回の出力例です。
Skill:verify
Skill:github-tools:pr-commit
git commit
Skill:verify が git commit より上にあれば、Claude はコミットの前に verify を呼んでいます。
上の jq は git commit という文字列でコミットを探します。そのため、ラッパーなど別のコマンドでコミットしている場合は、jq の test("git commit") を自分の環境のコマンド名に合わせて変える必要があります。
結果: 12回とも呼ばれた
次の表は、条件ごとに、Claude がコミットの前に verify を呼んだ回数です。
| 条件 | 頼み方 | description | コミット前に verify |
|---|---|---|---|
| A-D0 | 実装からコミットまで | コミットに触れない | 3/3 |
| A-D1 | 実装からコミットまで | コミット前を明記 | 3/3 |
| C-D0 | コミットだけ | コミットに触れない | 3/3 |
| C-D1 | コミットだけ | コミット前を明記 | 3/3 |
12回のうち11回で、Claude は次の順に動きました。verify を呼ぶ、開発サーバーを起動してブラウザで変更した画面を確認する、コミット用のスキル（pr-commit）を呼ぶ、git commit を実行する。残りの1回（C-D1）では、Claude は pr-commit を先に呼び、その途中で verify を呼んでからコミットしました。
D0 と D1 は、どちらも 6/6 でした。この条件では、description にコミットのことを書いても書かなくても、結果は同じでした。
呼ばれなかった回の条件
私の実開発で、Claude が verify を呼ばないままコミットに進んだ回は4回あります。変更の大きさは、コミットの差分の行数（2の回は transcript の編集操作）から数えました。
- description D0、変更 +1,230 / −169 行（3コミット、+219 / +341 / +670 行）: バックグラウンドの別セッションで、Claude がタスク7件をサブエージェントに分けて実装した。コミットは、私の環境の運用ルールに沿ったラッパーを通した。3コミットとも、サブエージェントではなく親が実行した
- description D0、変更 約5行（3ファイル）: 私は依頼文に「コミットはスキルを使わず git commit コマンドで直接行うこと」と書いた。このコミットは、私の環境のフックが止めたので、実際には作られていない
- 以前に自作した verify、変更 +132 / −9 行（2ファイル）: 機能の実装
- 以前に自作した verify、変更 +55 / −8 行（2ファイル）: 3の直後の追加修正
3と4の自作 verify の description は「コミット前の検証。型チェックとテストを実行し、UI 変更を含むときはブラウザの実画面で変更箇所を確認する」で、コミットに触れていました。
前の節の「description に1文を足したら呼ばれた1回」では、私は description を変えたうえで、2の依頼文にあったコミット方法の指定も外していました。この1回では、変えた条件が2つあります。私は PR #118 の1文を残していますが、この1文の効果は未確認です。
1、3、4は、試験の1行より大きい変更でした。2は試験と同じくらい小さい変更で、試験との違いは、依頼文でコミットの方法を指定したことと、Claude Code のバージョン（2.1.289）です。2の回については、追試で、コミット方法の指定より「スキルを使わず」の1文が原因の候補だと私は見ています（次の節）。1、3、4については、変更の大きさが原因かどうかを私は切り分けていません。4回しかないので、どのくらいの割合で起きるかもわかりません。
Claude Code のバージョンも比べました。4回は Claude Code 2.1.288〜2.1.291 で、12回の試験は 2.1.292 です。2.1.290〜2.1.292 の changelog には、verify やコミットの指示についての変更はありませんでした。ただ、changelog にはプロンプトの細かな変更が載らないので、私はバージョンが原因である可能性を消せません。一方で、2.1.289 では、Claude が verify を呼ばなかった回（2、コミット方法を指定）と、呼んだ回（指定を外した回）の両方がありました。2.1.288 でも、以前に私が行った試験では、Claude は28回とも verify を呼びました。バージョンだけでは、この違いを説明できません。
追試: コミットの経路だけを変えた9回
1の回と2の回は、どちらもいつもと違う経路でコミットした回でした。そのため、私はコミットの経路だけを変えて追試しました。共通の条件は以下の通りです。
- Claude Code 2.1.296、
claude -p - description D0、頼み方 C（コミットだけ）
- コミット用の自作スキルを含むプラグインの無効化
- 各条件3回ずつ、計9回実行
- ラッパー g（中身は
git -C <worktree>）
| 条件 | 依頼文に足した1文 | コミット前に verify |
|---|---|---|
| N | なし | 3/3 |
| G | コミットはスキルを使わず git commit コマンドで直接行うこと | 2/3 |
| W | コミットは git ではなくラッパー g を使うこと | 3/3 |
条件 W の3回では、Claude は3回ともラッパーでコミットし、その前に verify を呼びました。1の回で verify が呼ばれなかったことは、ラッパーだけでは説明できません。
条件 G で呼ばれなかった1回でも、verify はスキル一覧に載っていました。Claude は最初に「git commit で直接コミットします」と書き、verify を呼ばずにコミットしました。
条件 G の1文は、「スキルを使わず」とも読めます。verify もスキルです。Claude はこの指示に従って verify を省いたと私は見ています。2の回の依頼文も同じ1文でした。条件 G でも Claude は3回中2回は verify を呼んでいるので、Claude がこの1文をどこまで広く読むかは回によって違います。
1の回の原因は未確認のままです。残る違いは、変更の大きさ（+1,230 行）、タスク7件をサブエージェントに分けたこと、バックグラウンドのセッションだったことです。
verify のセットアップ
- Claude Code で
/verifyを一度実行する。プロジェクトに verify スキルがなければ、Claude が README や package.json から起動方法を探してアプリを動かし、動いた手順を.claude/skills/verify/SKILL.mdに書き残す（2.1.289 の組み込み/verifyの本文で確認。monorepo では、変更したパッケージの下に作る） - 書き残された SKILL.md を読み、起動コマンドと確認する画面が合っているかを見る。description は書き換えなくてよい
- SKILL.md をリポジトリにコミットする（fgo-farming-solver では PR #112）
- 新しいセッションを始める。commit instructions は、セッション開始時に verify スキルがあるかで決まる
- 型チェック、テスト、lint は、git の pre-commit フックか CI に置く。fgo-farming-solver では、husky と lint-staged で pre-commit に lint を置き、型チェック（
tsc --noEmit）とテストは GitHub Actions で実行している
まとめ
この記事の結果から言える使い方です。括弧内に根拠を書きます。
- verify の SKILL.md には、アプリを起動して変更した画面を確かめる手順を書く。組み込みの
/verifyが書き残す内容のままでよい（docs: スキル名が verify なら、commit instructions が Claude にコミット前に verify を呼ぶよう指示する） - description に、コミットのことを書き足さなくてよい（D0 でも、Claude は6回中6回 verify を呼んだ）
- 型チェックやテストのように必ず止めたい検査は、verify ではなく pre-commit や CI に置く（commit instructions は指示で、強制ではない。実開発で、Claude が verify を呼ばなかった回が4回あった）
- 依頼文に「スキルを使わず」と書かない（条件 G では、Claude は3回中1回 verify を呼ばなかった。ラッパー経由の条件 W では、Claude は3回とも verify を呼んだ）
- 数十行以上の変更のあとは、transcript を
jqで見て、Claude が verify を呼んだかを確かめる。呼んでいなければ、自分で/verifyを実行する（55〜1,230 行の変更で、Claude が verify を呼ばなかった回が3回あった。原因は未確認）