スキルは Claude に渡す「再利用可能な手順書」です。まず同梱スキルを使い、手順の繰り返しに気づいたら自作へ。
スキルは Claude Code に同梱されている「専門手順書」です。/ に続けて名前を打つだけで、レビュー・検証・調査などをその型で実行します。
同梱スキルは prompt-based — 固定の処理を実行する組み込みコマンドと違い、Claude に詳細な手順を渡して、Claude が自分の道具を使って進めます。だから同じスキルでもプロジェクトごとに動きが変わります。
🔴 v2.1.215 以降、/verify と /code-review は「あなたが呼んだ時だけ」動きます (以前は Claude が自分で実行することがありました)。時間とトークンを使う長い処理なので、発動の主導権が手元に戻された形です。
全部を無効にしたい時は settings.json の disableBundledSkills。ただし /doctor だけは残ります (壊れた時の最後の入口なので)。
レビュー・品質
手元の差分を読んで、バグと整理すべき箇所を挙げる。effort を上げるほど広く深く見る (ultra は多エージェントでの徹底レビュー)。
返ってくるもの: 指摘の一覧 (ファイル・行・理由)。--fix を付けると指摘をそのまま修正まで適用する。--comment で GitHub PR にインラインコメントとして投稿。
/code-review high --fix
使いどころ: コミット前の習慣に。まず effort なしで呼び、見落としが気になる時だけ high 以上へ
🔴 --fix はコードを書き換える。最初は付けずに指摘だけ見るのが安全。v2.1.215 以降は自分で呼ばないと動かない。
差分をセキュリティ脆弱性の観点で点検する。
返ってくるもの: 脆弱性の指摘 (公式には出力形式の記載なし)。
使いどころ: 認証・決済・外部公開・ユーザー入力を扱うコードを触った時。/code-review とは見る観点が違うので両方通す価値がある
GitHub の PR を 1 回読み切って要点を返す。**読み取り専用**と明記されている。
返ってくるもの: PR の要約とレビュー所見。
使いどころ: 他人の PR を数分で把握したい時。手元の差分ではなく PR が対象という点が /code-review との違い
挙動を変えずにコードを読みやすく整理する。
返ってくるもの: 整理後のコード (書き換える側)。
使いどころ: 実装が通った直後。動く前に呼ぶと、動かないコードを綺麗にするだけになる
公式は /code-review との関係のみ記載で、単独の詳細仕様は未記載。動いた後の掃除に使う位置づけ。
アプリを実際にビルドして起動し、変更が意図通り動くかを確かめる。**テストや型チェックに逃げない**のが設計思想。
返ってくるもの: 実際に動かした結果の報告。加えて、うまくいった手順を .claude/skills/verify/SKILL.md に記録することがある (v2.1.200 以降)。
使いどころ: 「テストは通った。で、本当に動くのか?」に答えたい時
記録ファイルは「手順を誤った時だけ」更新されるので、毎回の差分は出ない (コミットしても荒れない)。v2.1.215 以降は自分で呼んだ時だけ動く。
対象コードのテストを書いて実行する。
返ってくるもの: テストコード + 実行結果 (書き換える側)。
使いどころ: テストが薄い箇所の補強。動作確認そのものは /verify の担当
アプリを動かす 3 点セット
公式が「3 つで 1 組」と明示している唯一のグループ。テストでなく実物で確かめるための組み合わせ。
アプリを起動して実際に触り、変更が効いているかを見る。
返ってくるもの: 起動と操作の結果。
使いどころ: 「動いてるところを見たい」時
セットアップ不要で動くが、DB・env ファイル・GUI・多段ビルドが要るプロジェクトでは推測が外れやすい。その時は /run-skill-generator を先に。
(上記と同じスキル) ビルド + 起動で変更を確認する。
使いどころ: 変更の正しさを実物で確かめたい時
クリーンな環境からアプリを起動し、うまくいった手順 (install コマンド・env・起動スクリプト) を .claude/skills/run-<名前>/ に記録する。
返ってくるもの: プロジェクト専用のスキルファイル。以後 /run と /verify、他のエージェントもこの手順に従う。
使いどころ: 起動が複雑なプロジェクト。毎回 AI に環境を推測させるのをやめる時
プロジェクトごとに 1 回。ビルドや起動方法が変わったらもう 1 回。
コード以外の仕事
目的 (性能・可読性など) を指定してリファクタする。
返ってくるもの: 書き換えられたコード。
使いどころ: 「速くして」「読みやすくして」と狙いが言える時。狙いなしで呼ぶと方向が定まらない
コードベースを読んで README を生成・更新する。
返ってくるもの: README ファイル (書き換える側)。
使いどころ: ドキュメントが無い/古いリポジトリ
GitHub の PR を取得して要約・分析する。
返ってくるもの: PR の内容の整理。
使いどころ: レビューまでは要らず、中身を把握したいだけの時
GitHub ブランチの変更を作業ディレクトリに同期する。
使いどころ: リモートの進みを取り込む時
プロジェクトを解析して CLAUDE.md (プロジェクト説明書) を生成する。
返ってくるもの: CLAUDE.md ファイル (作成・更新)。
CLAUDE_CODE_NEW_INIT=1 claude
使いどころ: 新しいリポジトリで最初にやること。以後の精度が変わる
環境変数 CLAUDE_CODE_NEW_INIT=1 を付けると、スキル・フック・個人メモリまで案内する対話フローになる。
調べる・作る
ウェブ検索を並列に展開し、複数のソースを取得して突き合わせ、**出典付きのレポート**に統合する。
返ってくるもの: 出典リンク入りの調査レポート。
/deep-research 日本の生成AI研修市場の価格帯
使いどころ: 調べ物を丸ごと任せたい時。一次情報の裏取りまで含めてほしい場合
グラフ・ダッシュボードの設計指針を読み込ませる。データに合う図の形を選び、色を役割で割り当て、**色覚多様性とコントラストを同梱スクリプトで検証**し、描画・操作・アクセシビリティの規則を適用する。
返ってくるもの: 設計指針に沿ったチャート実装。
使いどころ: チャートを作らせる前に呼ぶ。呼ばずに作らせると色と形が場当たりになる
Claude Code v2.1.198 以降が必要。
デバッグログを有効にして問題を調査する。
使いどころ: 挙動がおかしい時の深掘り
コードベース横断の大規模な変更を並列で回す。
使いどころ: リネーム・一括移行など、同じ変更を多数のファイルに施す時
Claude API のリファレンス資料を、プロジェクトの言語向けに読み込む。
使いどころ: Claude API を使うアプリを書く前に
管理・トラブル時
セットアップを診断し、問題があれば修復まで提案する。
使いどころ: 動きがおかしい時の最初の一手
🔴 同梱スキルを全部切っても **/doctor だけは残る** (v2.1.205 以降)。壊れた時の最後の入口として意図的に残されている。完全に隠すには環境変数 DISABLE_DOCTOR_COMMAND。
使えるスキルの一覧・有効/無効の切り替え。
使いどころ: 何が入っているかの確認
マーケットプレイスから追加のスキル・プラグインを導入する。
使いどころ: 同梱にない専門機能が欲しい時
settings.json の設定。同梱スキルを全部無効化する (/doctor を除く)。
"disableBundledSkills": true
使いどころ: 素の状態で使いたい時・組織で機能を絞る時
どれを使うか迷ったら
レビュー系 3 つの使い分け
| スキル | 対象 | 書き換え | こう使う |
|---|---|---|---|
| /code-review | 手元の差分 | --fix 付きなら書き換える | コミット前に毎回 |
| /review | GitHub の PR | 読み取り専用 | 他人の PR を数分で把握 |
| /security-review | 手元の差分 | 記載なし | 認証・決済・公開系を触った時に追加で |
「動くか」の確かめ方 2 つ
| スキル | 確かめ方 | こう使う |
|---|---|---|
| /test | テストを書いて走らせる | テストが薄い箇所の補強 |
| /verify | アプリを実際にビルドして起動する | 「テストは緑なのに本番で壊れる」を潰す |
ファイルを書き換えるか否か
| 書き換える | 見るだけ |
|---|---|
| /refactor · /simplify · /readme · /init · /test | /review · /security-review · /pr · /deep-research |
| /code-review --fix ← フラグ次第で書き換える側に回る | /code-review (フラグなし) |