毎朝同じ呪文を 1 行に圧縮する ─ Claude Code Skills の「手動 invoke」入門

毎朝 Claude Code を開いて、毎回同じ呪文をタイプしていませんか？

git status を打って、npm test を打って、git diff HEAD~5 -- src/ を打って、最後に「で、変更点まとめて」と日本語で打つ。手は覚えていますが、頭は別のことを考えていて、3 回に 1 回はどこかでタイポします。タイポに気づくのは出力が変だった時で、また打ち直して、また待ちます。

ChatGPT のタブに毎回「あなたはシニアソフトウェアエンジニアです。日本語で答えてください。コードは…」という前置きを 8 行コピペしている人と、構造はまったく同じです。毎回手で打っている操作は、毎回ロスを生んでいます。

このロスは、Claude Code 側ですでに解決されています。Skill を /morning-check のような名前で手で叩く仕組みです。

まず仕様変更の整理から

シリーズ #04 Skills 入門 では「Skill とは何か」と「Claude が auto-discovery で呼ぶ自動 invoke」を中心に書きました。本記事はその続編で、自分が /name で叩く手動 invoke に振り切ります。

この記事を書くにあたって 1 つだけ整理しておくことがあります。Custom Slash Commands は Skills に統合されました。公式 docs（Extend Claude with skills） の Note にこう書かれています。

“Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way.”
「カスタムコマンドはスキルに統合されました。.claude/commands/deploy.md と .claude/skills/deploy/SKILL.md のどちらも /deploy を作り、同じように動作します。」

つまり「.claude/commands/ に Markdown を置く」やり方は今も後方互換で動きますが、新規に作るときの推奨は .claude/skills/<name>/SKILL.md です。理由は単純で、Skill のほうが frontmatter が拡張されており、補助ファイル同梱（template、scripts、reference）や subagent 連携（context: fork）など、後で効いてくる機能が一通り使えるからです。

以降この記事では、新規作成を前提に Skill 側で書きます。

Skill には 3 つの呼ばれ方がある

Skill の話で最初に押さえておきたいのは「呼ばれ方が 3 つある」点です。

flowchart LR Human["私"] Skill["SKILL.md<br/>1 ファイル"] AutoSkill["Claude<br/>(auto-discovery)"] Sub["Subagent<br/>独立コンテキスト"] Skill -. "デフォルト挙動<br/>(両方 invocable)" .- Both["呼び出し経路は 3 つ"] Both --> P1["1. 私が /name で叩く<br/>(手動 invoke)"] Both --> P2["2. Claude が会話の流れで呼ぶ<br/>(auto-discovery)"] Both --> P3["3. context: fork で<br/>subagent に prompt として渡る"] Human --> P1 AutoSkill --> P2 P3 --> Sub

公式 docs（Configure skills > Control who invokes a skill） のとおり、デフォルトでは私も Claude も同じ Skill を呼べます。/name と手で叩いてもいいし、私が日本語で「PR レビューして」と頼んだときに Claude が description を見て自動で発火してもいい。

性格付けは frontmatter の 2 行で切り替えます。

#04 で扱った「Claude が呼ぶ」用途は 2 行目を消しただけのデフォルト挙動です。本記事で深掘りするのは 1 行目、disable-model-invocation: true を付けた「私が叩く専用」の Skill です。

公式の built-in と bundled の違い

自作の前に、Claude Code にはじめから入っているスラッシュコマンドの全体像を整理します。ここで混同しがちなのは「built-in commands」と「bundled skills」の違いです。

公式の commands リファレンス で「Purpose」列を眺めると、Skill とマークされている行と、無印（固定ロジック）の行があります。

• built-in commands（固定ロジック）: /clear /compact /rewind /help /login /logout /permissions /context /agents /skills /plan /model などのアプリ機能。Claude Code のバイナリ側に C/TS で書かれていて、内容を読み替えられない
• bundled skills（Skill 機構で動く）: /simplify /batch /debug /loop /claude-api などのプロンプトベース skill。SKILL.md として実装されており、Claude が指示を読み解いて自分のツールで実行する。自作 skill とまったく同じ仕組み

体感で覚える価値があるのは次の 8 個前後です。

/clear /compact /rewind /context /skills /plan あたりが使用頻度高めです。残りは「困った時に思い出す」程度で十分。

実機の最新リストは /help で確認するのが確実です。バージョンが上がるたびに増減します。コミュニティ集計は数字がずれることがあるので、断定の数字は実機の /help か 公式 commands リファレンス を一次ソースにしてください。

自作 Skill の最小構成 — 8 行で終わる

自作 Skill は .claude/skills/<name>/SKILL.md を 1 つ置くだけで増えます。

frontmatter なしの 1 行でも動きますし、推奨は frontmatter に description を 1 行書いて、本文に何をしてほしいかを書く形です。

最小例を貼ります。.claude/skills/morning-check/SKILL.md の中身：

---
description: 朝イチ起動して、前日からの差分と CI 状況をまとめる
disable-model-invocation: true
allowed-tools: Bash, Read
---
直近 5 コミットの差分概要と、未コミットの変更ファイル一覧、現在の CI 状況をまとめてください。
!git log --oneline HEAD~5..HEAD!git status -sb!gh pr checks 2>/dev/null || echo "no PR for this branch"

これだけです。保存した瞬間から /morning-check で呼べるようになります。公式 docs（Live change detection） のとおり、.claude/skills/ 配下の追加・編集・削除はセッション中にも有効になります。再起動は不要です。

ポイントは 3 つ。

1. disable-model-invocation: true を付けている — Claude が空気を読んで勝手に走らせる挙動を切ります。/morning-check と私が叩いたときだけ動きます。朝のチェックは私のリズムで呼びたいので、Claude の auto-discovery は要りません
2. allowed-tools で Bash と Read を絞っている — この skill が active な間に許可なく使えるツールを宣言します。Bash と Read だけ許可しているので、勝手に Write したり Web 検索したりしません。誤爆を防げます
3. !<shell command> ブロックでシェルを実行 — 行頭の ! プレフィックスが「この backtick はコードサンプル表示ではなく shell として実行せよ」と CLI に伝える記号です。backtick 内のシェルコマンドが skill 実行時に走り、その出力が本文に展開されてから Claude に渡ります。git status を Claude に叩かせる必要すらありません。結果がもう手元に来ている状態でスタートします

/morning-check を打つと、Claude は git log と git status と gh pr checks の出力を眺めながら、「直近 5 コミットの差分概要と…」という指示を実行する、という流れになります。

起動から実行までのフロー

/morning-check を打った瞬間、内部では何が起きているのでしょうか。

sequenceDiagram participant U as 私 participant CLI as Claude Code CLI participant FS as .claude/skills/<br/>morning-check/SKILL.md participant Shell as Shell<br/>(Bash) participant LLM as Claude (LLM) U->>CLI: /morning-check 入力 CLI->>FS: ファイル読込 FS-->>CLI: frontmatter + 本文 CLI->>Shell: !git log ... 実行 Shell-->>CLI: コミット一覧 CLI->>Shell: !git status -sb 実行 Shell-->>CLI: 変更ファイル一覧 CLI->>Shell: !gh pr checks 実行 Shell-->>CLI: CI ステータス CLI->>LLM: 本文 + シェル出力を統合して送信 LLM-->>CLI: まとめ生成 CLI-->>U: 整形して表示

CLI 側で !<shell> ブロックを先に実行し、その出力を本文に差し込んでから Claude に渡しています。Claude は「シェル結果を見ながら、本文の指示を実行する」流れになります。

allowed-tools: Bash, Read を指定しているので、Claude 側は Bash と Read 以外のツール（Write、Web 検索など）を勝手に使えません。誤爆防止の効果はここに出ます。

手動 invoke で効く Frontmatter 6 個

Skill の frontmatter は 公式 docs（Frontmatter reference） に 15 個ほど一覧されています。実用上は次の 6 個で 9 割の用途を満たせます。

引数を扱う例も貼っておきます。.claude/skills/pr-review/SKILL.md：

---
description: 指定した PR をローカルでレビュー（fork 実行）
argument-hint: [PR番号]
arguments: pr_number
disable-model-invocation: true
allowed-tools: Bash, Read, Grep
context: fork
agent: code-reviewer
---
PR 番号 $pr_number をローカルで見て、優先度ごとに指摘をまとめてください。
!gh pr checkout $pr_number!gh pr view $pr_number --json title,body,author!git diff main...HEAD --stat

/pr-review 1234 と打つと、$pr_number が 1234 に置き換わって実行されます。context: fork を指定しているので、レビュー用の独立コンテキストが立ち、私のメイン会話の context は汚れません。agent: code-reviewer で code-reviewer Subagent に投げています（自作 Subagent の作り方は #05 Subagents 入門 で扱いました）。

引数の置き換え方は他にもあります。$ARGUMENTS で全引数を一括で受ける、$0 $1 で位置指定する、${CLAUDE_SESSION_ID} で現在のセッション ID を取り込む、など。詳細は 公式 docs（Available string substitutions） を参照してください。

#04 で扱った「Claude が呼ぶ」用途との切り分け

ここで #04 Skills 入門 との関係を整理します。

#04 では disable-model-invocation を付けないデフォルト挙動の Skill を扱いました。Claude が会話の流れから description にマッチする skill を見つけ、auto-discovery で本文をロードします。/summarize-changes のような名前で私が叩くこともできますが、本来は「PR レビューして」と日本語で頼んだら自動で動いてほしい性格の skill です。

本記事で扱う手動 invoke (発動) 型 skill は、auto-discovery を切って「私が呼ぶ瞬間まで動かない」性格にしたものです。違いは frontmatter 1 行（disable-model-invocation: true）だけです。

副作用がある skill（デプロイ、Slack 送信、git push など）は必ず disable-model-invocation: true を付けてください。コードが整って見えたら Claude が勝手にデプロイした、では困ります。

Subagent との連携 — context: fork がブリッジ

#05 Subagents 入門 で扱った Subagents との関係も整理しておきます。

skill の frontmatter に context: fork と agent: <type> を指定すると、その skill は「独立コンテキストで指定した Subagent を起動する」動作になります。私のメイン会話とは分離されたコンテキストで Subagent が走り、結果だけが私の側に返ってきます。

これが効くのは、メインの会話で議論しながら、別の専門家（Subagent）にレビューや調査を投げたい場面。/code-review /security-check /db-schema-validate のように、Subagent への投げ口を skill として固定しておくと、起動が 1 回のキー入力で済みます。

「同じロールを 3 回呼んだら自作 Subagent」というルールは #05 で書いた通りですが、もう一段上の運用として「自作 Subagent を 1 回のキー入力で呼べる skill を併せて作る」ところまで来ると、コマンドラインの操作が劇的に短くなります。

ハマる罠 4 つ

ここまでで仕組みは押さえられました。次は私が実際にハマった、または周りで見た罠です。

罠 1: 公式で足りるのに自作してしまう

公式 commands リファレンス にある built-in（/review /init など）と bundled skills（/simplify /debug /loop /claude-api）で足りないかを、自作する前に確認してください。

判断軸は「3 回以上、同じ用途で呼ぶか」。1 回しか呼ばないシェル操作は skill にする価値がありません。

罠 2: 副作用のある skill に disable-model-invocation を付け忘れる

/deploy /git-push /send-slack-message を frontmatter 設定なしで作ると、Claude が「今がそのタイミング」と判断して勝手に走らせます。

公式 docs の該当セクション に書かれている通り、こういう skill には必ず disable-model-invocation: true を付けます。これだけで「私が /deploy と打ったときだけ走る」状態になります。

罠 3: フラグだらけで覚えられない

引数を 5 つも 6 つも持つ skill を作ると、初回利用時に「どの順番で何を渡せばいいんだっけ」となります。

argument-hint で入力ヒントを 1 行で表示するか、arguments: で名前付きにして $pr_number $base_branch のように本文側で展開する形にします。位置引数だけだと、3 ヶ月後の自分が読めなくなります。

罠 4: 引数を持たせず固定値で埋めてしまう

npm test src/auth/ のように、特定のディレクトリを本文に直接書いてしまう例です。

最初は src/auth/ 1 個で済みますが、src/payment/ src/user/ と増えてきた瞬間、skill を 3 個に分岐させる羽目になります。$ARGUMENTS を使えば 1 個で済んだはずです。

---
description: 指定ディレクトリのテストだけ走らせる
argument-hint: [ディレクトリパス]
disable-model-invocation: true
---
!npm test -- $ARGUMENTS結果を見て、失敗箇所があれば原因を 3 行で説明してください。

$ARGUMENTS には呼び出し時の引数全体が入ります。/test-only src/auth/ でも /test-only src/payment/ --watch でも、そのまま展開されます。

今週やる 1 つ — /morning-check を 8 行で書く

具体的なアクションを 1 つだけ提示します。

.claude/skills/morning-check/SKILL.md を、上のサンプルそのままでいいので保存してください。8 行です。

---
description: 朝イチ起動して、前日からの差分と CI 状況をまとめる
disable-model-invocation: true
allowed-tools: Bash, Read
---
直近 5 コミットの差分概要と、未コミットの変更ファイル一覧、現在の CI 状況をまとめてください。
!git log --oneline HEAD~5..HEAD!git status -sb!gh pr checks 2>/dev/null || echo "no PR for this branch"

明日の朝、Claude Code を開いたら最初に /morning-check と打ちます。出力を眺めて、その日 1 番に取り組むべきタスクが明確になります。

3 日続けてみて、もし「もう少し情報が欲しい」と思ったら、!<shell> ブロックを 1 行追加するだけです。例えば直近のテスト結果を見たければ !cat .last-test-report.json 2>/dev/null を足す。プロジェクト固有の確認事項を追加するときも、SKILL.md を 1 ファイル編集するだけで全員に共有できます。

クロージング — Skill の本当の効用は「言葉になる」こと

私自身、/morning-check を 3 ヶ月使い続けて気づいたのは、「朝のキーボードショートカットを言葉にした瞬間、その『言葉』を後輩に渡せるようになった」ことでした。

それまで、新しくチームに入った人に「朝はこういう確認をしてから作業を始めるといいよ」と口頭で説明していたのが、.claude/skills/morning-check/ ディレクトリを渡すだけで済むようになりました。コードレビューの観点、リリース前のチェック項目、PR を出す前の準備、どれも .claude/skills/ の中に SKILL.md として溜まっていきます。

チームの Onboarding 資料が、いつの間にか .claude/skills/ ひとつになっていた。これが Skill の本当の効用かもしれません。

操作が「キーボードの動き」だったうちは、自分の頭の中にしか存在しませんでした。/morning-check という言葉になった瞬間、それは資産になりました。

TL;DR

• Custom Slash Commands は Skills に統合済み。新規は .claude/skills/<name>/SKILL.md で作る（.claude/commands/ は後方互換で動く）
• Skill は呼ばれ方が 3 つある: 私が /name で叩く ／ Claude が auto-discovery で呼ぶ ／ context: fork で subagent に prompt として渡る
• frontmatter 1 行で性格付け: disable-model-invocation: true で「私だけ型」、user-invocable: false で「Claude だけ型」
• 公式の built-in（/clear /compact 等）と bundled skills（/simplify /debug /loop /claude-api）は性質が違う。前者は固定ロジック、後者は Skill 機構
• 自作 skill は .claude/skills/<name>/SKILL.md を 1 ファイル置くだけ。保存即有効
• 手動 invoke で覚える frontmatter 6 個: description / disable-model-invocation / argument-hint / arguments / allowed-tools / context: fork + agent
• 罠: 公式で足りるのに自作 ／ 副作用 skill に disable-model-invocation 付け忘れ ／ 引数フラグで覚えられない ／ 固定値で埋めて拡張不能
• 今週やる 1 つ: /morning-check を 8 行で保存して明日朝に呼ぶ