使い方
呼び方: /名前 と引数、自動発動、プラグインの名前空間
スキルはメッセージの先頭に /名前 と打って呼びます。名前の後ろに続けた文字がそのまま引数になり、スキル本文の $ARGUMENTS に展開されます。/code-review high 1234 の high と 1234 がその例です。
もう1つの入口は自動発動です。各スキルの description が常にコンテキストに載っていて、話題が合うと Claude が自分で本文を読み込みます。標準スキルでは、/claude-api はコードが anthropic や @anthropic-ai/sdk を import していると自動的に有効になり、/artifact-capabilities と /workflow-authoring は通常 Claude が自分で読み込む、と公式に書かれています。逆に /verify と /deep-research は自分が呼んだときだけ動きます。
プラグインのスキルは /plugin-name:skill-name の形で名前空間付きになり、同名の自作スキルと衝突しません。claude.ai から同期されたスキルは /名前 でも /anthropic-skills:名前 でも呼べますが、他のコマンドが短い名前を使っていると長い名前だけになります。
v2.1.199 以降は /skill-a /skill-b 引数 のように先頭に最大6個まで並べられ、末尾の文字が各スキルの引数として渡ります。ただし forked subagent として走る /code-review のようなスキルで並びは打ち切られます。いま読み込まれているスキルの一覧は /skills で見ます。
打ち方の例
/code-review high 1234 # 標準スキルに引数
/loop 20m /review-pr 1234 # スキルの引数に別のスキル
/my-plugin:review # プラグインのスキル
/anthropic-skills:pdf # claude.ai から同期されたスキルの完全名
/write-tests /fix-issue 123 # 2つ並べて 123 を両方に渡す
標準スキルを止める・隠す: disableBundledSkills と skillOverrides
標準スキルと同梱ワークフローをまとめて外すには settings.json に disableBundledSkills: true を書きます。/init のような組み込みコマンドは自分では打てたままで、Claude からは見えなくなります。プラグイン・.claude/skills/・.claude/commands/ のスキルには影響しません。
/doctor だけは disableBundledSkills でも打てたままです(v2.1.205 以降)。隠したいときは環境変数 DISABLE_DOCTOR_COMMAND か、skillOverrides で doctor を off にします。
1つずつ扱うなら skillOverrides です。値は on(名前と説明を Claude に見せる)、name-only(名前だけ)、user-invocable-only(Claude には隠し自分は打てる)、off(両方から隠す)の4つ。/skills 画面で Space を押して切り替えると .claude/settings.local.json に書かれます。プラグインのスキルは対象外で、/plugin で管理します。
ユーザー・プロジェクト・ローカルの settings では別名は見ません。review と書いても /code-review の別名としては効かず、review という名前のスキルに当たるだけです。managed settings と --settings で渡したファイルでは、checkup のような別名でも本体の /doctor に適用されます(v2.1.260 以降)。
settings.json の断片
{
"disableBundledSkills": false,
"skillOverrides": {
"doctor": "off",
"dataviz": "user-invocable-only",
"legacy-context": "name-only"
}
}自作スキルの作り方: SKILL.md の最小例と frontmatter
スキルは <場所>/<name>/SKILL.md の1ファイルから始まります。先頭行から --- で囲んだ YAML frontmatter、その後ろに Claude に読ませる Markdown の手順です。frontmatter のフィールドはすべて任意ですが、description だけは書いておくのが推奨です。Claude はこれを見て自動発動するか決めます。
コマンド名はディレクトリ名、または frontmatter の name です。本文の !`コマンド` の行は、Claude が読む前に Claude Code がそのコマンドを実行して出力に置き換えます(dynamic context injection)。
主なフィールド: name(/ メニューに出る名前)、description(何をするか・いつ使うか。when_to_use と合わせて 1,536 文字で切られます)、disable-model-invocation: true(自分だけが呼べる。デプロイやコミットのような副作用のある手順向け)、user-invocable: false(Claude だけが呼ぶ背景知識向け)、allowed-tools(そのスキルを呼んだターンの間だけ、列挙したツールを承認なしで使える。次のメッセージで消える)、context: fork(別のサブエージェントで実行。agent で種類を選び、background: false で結果を待つ)、arguments(名前付き引数。$issue のように本文で使う)、argument-hint(補完時のヒント)、paths(一致するファイルを扱うときだけ自動発動)、model(そのターンの残りだけ上書き)、effort(スキルが有効な間、セッションの effort を上書き)。
一度読み込まれた本文は会話に残り続け、Claude Code はファイルを読み直しません。毎ターンのコストになるので本文は簡潔に、重要な指示は上に置き、長い参考資料は同じディレクトリの別ファイルに逃がして本文からリンクします。
frontmatter の YAML が壊れていてもスキルは読み込まれますが、フィールドは空になり自動発動しなくなります。claude plugin validate .claude/skills で構文を確かめられます(v2.1.233 以降)。
.claude/skills/nest-module/SKILL.md の最小例
---
name: nest-module
description: NestJS のモジュール一式(module/controller/service/spec)を足す。ユーザーが「〜モジュールを作って」と言ったときに使う。
arguments: [module]
argument-hint: "[module-name]"
allowed-tools: Bash(npx nest g *)
---
## 既存の構成
!`ls src`
## 手順
1. `npx nest g module $module` を実行する
2. `npx nest g controller $module --no-spec` と `npx nest g service $module --no-spec` を実行する
3. 生成された service に対する spec を書く
4. app.module.ts に import が追加されたことを確認する
置き場所と優先順位: 同名のときどれが勝つか
置く場所で読み込まれる範囲が決まります。enterprise(managed settings のディレクトリ内 .claude/skills/、組織の全マシン)、personal(~/.claude/skills/、このマシンの全プロジェクト)、project(.claude/skills/、そのリポジトリ。コミットしてチームに配る)、nested(<subdir>/.claude/skills/、そのサブディレクトリ以下で始めたセッション。上から始めた場合はそこのファイルを触ったときに読み込まれる)、additional directory(--add-dir で渡したディレクトリ)、plugin(<plugin>/skills/、/plugin-name:skill-name として)、claude.ai account(サインインしたセッションに同期)。
同じ名前が複数あるときの順位: enterprise > personal > project です。~/.claude/skills/deploy と .claude/skills/deploy が両方あれば /deploy は personal のほうを走らせます。
自作スキルと標準スキルが同名なら自作が勝ちます。組み込みコマンドとの同名も、ローカルのターミナルセッションでは自作が勝ちます。ただし別名までは奪えません。project に code-review を置けば /code-review は自作になり、/review は依然として標準のものを呼びます。.claude/commands/deploy.md と .claude/skills/deploy/ が両方あればスキルが勝ちます。
両方生きる組み合わせもあります。project 直下と nested の同名スキルは両方読み込まれ、/deploy は直下、/apps/web:deploy は nested を指します。プラグインのスキルは名前空間が別なので常に共存します。claude.ai から同期されたスキルは最も弱く、短い名前を他のどれかが使っていれば /anthropic-skills:名前 でしか呼べません。
personal のスキルは Cowork やクラウドセッション(routines を含む)では読まれません。そちらで使いたいなら claude.ai のアカウントで有効にするか、リポジトリの .claude/skills/ にコミットします。
置き場所の一覧
/etc/claude-code/.claude/skills/<name>/SKILL.md # enterprise(managed settings 内。Linux の例)
~/.claude/skills/<name>/SKILL.md # personal
.claude/skills/<name>/SKILL.md # project
apps/web/.claude/skills/<name>/SKILL.md # nested → /apps/web:<name>
<plugin>/skills/<name>/SKILL.md # plugin → /<plugin>:<name>
~/.claude/skills/synced/ # claude.ai から同期(手で編集しない)
.claude/commands/<name>.md # 旧形式。今も動く
/skill-doctor でコストを見る
スキルの一覧(名前と説明)は、使う・使わないに関係なく毎ターンのコンテキストに載ります。予算はモデルのコンテキストウィンドウの1%で、あふれると呼ばれる回数が少ないスキルから説明文が落とされ、Claude が自動発動の判断に使う手がかりが消えます。
/skill-doctor は、各スキルのコンテキストコストと呼ばれた回数を出し、一度も呼ばれていないものをどこで切れるかまで示します。対話セッションでは /plugin の Stats タブに開き、-p では文字で出ます。標準スキルと enterprise スキルは対象外で、最近使っていないプラグインも列挙されます。
減らす順番は、公式の案内どおり「切れる場所が示されたもののうち、コストの高いものから」です。切り方は skillOverrides で off か name-only、プラグインなら /plugin で無効化。一覧全体のコスト見積もりは /doctor でも出ます。
必要な版は v2.1.252 以降で、feature flag を取得できるセッションに限ります。Remote Control 経由(スマホやブラウザ)では使えないので、セッションが動いているマシンのターミナルで打ちます。
見てから切るまで
/skill-doctor # コストと使用回数を見る
/skills # Space で name-only / user-only / off を切り替え、Esc で保存
/context # Skills 行で一覧の実サイズを確認
/run・/verify・/run-skill-generator は3つで1組
/run はアプリを起動して変更が動く様子を見せ、/verify はビルドして起動し、変更が意図どおりか観察で判定します。どちらも設定なしで動き、プロジェクトの種類や README、package.json、Makefile から起動方法を推測しますが、DB や env ファイル、複数段のビルドが要るプロジェクトでは推測が外れます。
/run-skill-generator はその推測を手順に置き換えます。クリーンな環境からアプリを立ち上げ、通ったインストールコマンド・環境変数・起動スクリプトを .claude/skills/run-<name>/ にプロジェクト用スキルとして保存します。以後は /run も /verify も他のエージェントもこの手順に従います。プロジェクトごとに1回、起動手順が変わったらもう1回です。
/verify 自身も手順を残します。記録が無い状態でビルドと操作に成功すると、.claude/skills/verify/SKILL.md(モノレポなら触ったパッケージの中)に書き出し、リポジトリ直下のそれは標準の /verify を置き換えます(v2.1.200 以降)。Claude がこのファイルを編集するのは、コマンドが失敗したなど自分の手順が間違っていたときだけなので、セッションごとの差分が出ずにコミットできます(v2.1.205 以降)。
さらに v2.1.286 以降、セッション開始時に verify または simplify という名前のスキルが enterprise / personal / project / --add-dir の場所にあると、ドキュメントとテストの変更を除く各コミットの直前に Claude がそれを実行する指示を受けます。/verify が直下に残した記録はプロジェクトスキルなので対象で、標準の /verify と /simplify そのものや、プラグイン・claude.ai 同期のものは対象外です。disable-model-invocation: true を付けたスキルや includeGitInstructions を切った環境でもこの指示は出ません。
初回と2回目以降
# 初回(起動に DB や env が要るプロジェクト)
/run-skill-generator # → .claude/skills/run-<name>/SKILL.md ができる
# 2回目以降
/run # 記録した手順で起動して見せる
/verify # 記録した手順で起動し、変更を判定する
# 記録が無ければ .claude/skills/verify/SKILL.md に残す版の注意: 「Requires v2.1.xxx」を読む
Claude Code の公式ドキュメントは機能ごとに「Requires Claude Code v2.1.xxx or later」や「Before v2.1.xxx, ...」と書かれています。このページで扱った中では、/skill-doctor が v2.1.252、/workflow-authoring が v2.1.248、/design と /slides が v2.1.265、/doctor prompt-audit が v2.1.283、コミット前の verify/simplify 自動実行が v2.1.286、claude.ai スキルのターミナル同期が v2.1.273 です。
自分の版は claude --version で確かめます。このページを書いた時点の手元は 2.1.288 で、上の条件はすべて満たしています。ある版で挙動が変わった機能(たとえば /review は v2.1.223 より前(v2.1.222 以前)は別物、/fork は v2.1.212 より前(v2.1.161〜v2.1.211)は forked subagent の起動)は、古い版では説明と違う動きになります。
版ごとの変更点はセッション内の /release-notes で見られます。表示はトランスクリプトに出るだけで Claude の会話には入らないので、気軽に開けます。/doctor はリリースチャネル上の新しい版があるかも確認します。
確認の手順
$ claude --version # 手元の版を確認
# セッション内で
/release-notes # 版を選んで変更点を読む
/doctor # 新しい版の有無も含めて健診