Claude Codeのスキルの作り方

《 Claude完全ガイド目次へ》

10秒でいうと

繰り返す手順を、SKILL.md 1枚で部品にできます。
使うときだけ読み込まれるので、長い手順を書いても普段の文脈を圧迫しません。

No.38で「CLAUDE.md に手順を書かない」と書きました。手順の置き場所がスキルです。

CLAUDE.mdとの違い
作り方
置き場所
本ガイドで作ったもの
組み込みのスキル
つまずきポイント
まとめ
次に読む

CLAUDE.mdとの違い

違いは1つだけです。読み込まれるタイミング。

CLAUDE.md は毎回読まれます。スキルは使うときだけ読まれます。

だから公式ドキュメントはこう書いています。長い参照資料をスキルに入れておいても、使うまではほとんどコストがかかりません。

作るべきタイミングも明快です。

同じ指示や手順を、何度も貼っている
CLAUDE.md のある節が、事実ではなく手続きに育ってきた

2つ目が実感に近い。「〜する手順」と書き始めたら、それはスキルです。

作り方

ディレクトリを1つ作って、SKILL.md を置くだけです。

mkdir -p ~/.claude/skills/summarize-changes

---
description: 未コミットの変更をまとめ、危ういところを指摘する。変更内容を聞かれたとき、コミットメッセージを求められたときに使う
---

## いまの変更

!`git diff HEAD`

## 手順

上の差分を2〜3点にまとめ、そのあと気づいたリスクを挙げてください。
エラー処理の漏れ、ハードコードされた値、更新が要るテストなど。
差分が空なら、未コミットの変更はないと答えてください。

ディレクトリ名がそのままコマンド名になります。この例なら /summarize-changes で呼べます。

要点が2つ。

description が呼ばれ方を決めます。Claudeはこの説明を読んで、いま使うべきか判断します。どういう場面で使うかを書くのがコツで、機能の説明だけでは自動で呼ばれません。

! で始まる行はコマンドの実行結果が埋め込まれます。上の例だと、Claudeが読む前に git diff HEAD の結果がプロンプトに入ります。推測ではなく実物を見せられる。

置き場所

場所	範囲
`~/.claude/skills/`	自分の全プロジェクト
`.claude/skills/`	このプロジェクト（Gitで共有）

チームで共有したいものはプロジェクトへ。CLAUDE.md と同じ考え方です。

なお、以前の「カスタムコマンド」はスキルに統合されました。.claude/commands/deploy.md も .claude/skills/deploy/SKILL.md も、どちらも /deploy になります。既存のファイルはそのまま動きます。

本ガイドで作ったもの

実例として、このガイドの制作で作った検査を挙げます。

第2章を書いているとき、太字の書式ルールを同じ日に3回破りました。CLAUDE.md の書き方を2回直しても守れませんでした。

そこで手順のほうを部品にしました。太字の末尾の句読点を外に出す修正ツールと、投稿前にそれを検査する処理です。前者は繰り返す手順なのでスキルの発想、後者は必ず走らせたいので検査プログラムに組み込みました。

2回破ったら注意力の問題ではなく仕組みの問題、というのがこのときの結論です（No.25）。

組み込みのスキル

Claude Codeには最初から入っているスキルがあります。/doctor /code-review /debug /loop など。自分で作る前に、あるものを見てください。

/doctor は設定の点検、/code-review は差分のレビュー。どちらも日常的に使えます。

やってみよう：繰り返している指示をスキルにする（5分）

Claude Codeに何度も貼っている指示を1つ選んでください。

プロンプト
“`
私が繰り返し貼っている次の指示を、スキルにしてください。

・~/.claude/skills/ の下に作る
・description は「どういう場面で使うか」が分かる書き方で
・コマンドの実行結果を埋め込めるなら埋め込む
・作る前に、ファイルの中身を見せてください

指示：（ここに貼る）
“`

中身を確認してから作らせ、/スキル名 で呼んでみてください。

期待される結果：スキルができ、コマンドで呼べる。

うまくいかないとき：自動で呼ばれないなら description が機能の説明になっています。「〜のときに使う」を足してください。