Claude Code Skills を自分で作る — SKILL.md 一枚でエージェントに新しい道具を授けるハンズオン (2026, 日本語)

プロローグ — 「またこの手順を貼り付けてる」と気づく瞬間

Claude Code を一、二か月使うと、誰もが同じ気づきにたどり着く。

毎回同じ指示をチャットに貼り付けている。「PR を作るときは conventional commits で」「リリースノートはチームの形式で」「テストとビルドが通ってからしかマージしない」。最初の二回はコンテキストに入れておけばよかった。だが同じ手順を五回目に書いたとき、ふと疑問が湧く — これを毎回入力するのが本当に正解か?

CLAUDE.md に書けばいい、という反論が来る。半分正しい。だが CLAUDE.md はグローバルで常時ロードされるコンテキストで、すべてのタスクに手順が乗ってくる。トークンが惜しいだけでなく、目下の作業と関係のない手順がモデルの注意をそらすのがより大きな問題だ。PR を作るときだけ要る 70 行のチェックリストが、一行のタイポ修正セッションでも毎回メモリに常駐する。

Anthropic は 2025 年 10 月にこの問題に答えを出した。Agent Skills。名前は大きいが本質は小さい — ディレクトリ一つに SKILL.md 一枚。フロントマターに description を書けば、モデルが「この作業にこの Skill が合うか」を自分で判断して invoke する。常時ロードではなく、必要なときだけメモリに乗る。同じディレクトリを git にチェックインすれば、チーム全体で共有できる。

2025 年 12 月、Anthropic はさらに一歩を踏み出した。Skills をオープン標準として開放した。同じ SKILL.md 形式が Claude.ai、Claude Code、Agent SDK、API のどこでも動き、OpenAI Codex CLI や一部のサードパーティツールも同じ仕様を採用した。事実上、Markdown と YAML で表される「エージェント能力の単位」の共通語になった。

2026 年 5 月現在、回っているチームは 30 から 50 個の Skill カタログを抱えている。配布は git push か plugin マーケットプレイス経由。本稿は Skill を初めて書く人のために、何がどう動いているかをきちんと開く — SKILL.md の全フィールド、起動モデル、ディレクトリレイアウト、配布、そして release-notes-from-git-log Skill を空のディレクトリから動く Skill まで作り切るハンズオンまで。

1 章 · Skill とはいったい何か

一行の定義: YAML フロントマター + マークダウン指示文の SKILL.md 一枚と、その横に任意で置かれるスクリプト/リファレンスファイルの束。

最小の Skill はこんな見た目だ。

---
name: pr-summary
description: 現在の PR の変更を要約し、リスクを洗い出す。ユーザーが PR をレビューしたい、マージ前に確認したい、と言ったときに使う。
---

## タスク

現在の PR diff を読み、次の形式で要約せよ:

1. 変更の意図 (2〜3 文)
2. 追加された依存や設定
3. リスク領域 — エラー処理漏れ、ハードコード、更新が必要なテスト

最後に「マージしてよい / 要レビュー / 保留推奨」の一行結論を出す。

これで全部だ。~/.claude/skills/pr-summary/SKILL.md に保存すれば、次のセッションからユーザーが「PR ちょっと見て」と言ったときに、Claude が description を読んで自動で invoke する。ユーザーが /pr-summary と直接打っても同じ結果。

Skill が解いてくれること

• 繰り返される手順のカプセル化。同じ指示を毎回貼らなくてよい。
• 遅延ロード。description だけが常時カタログにあり、本文は invoke 時にだけコンテキストに入る — トークンが安い。
• 名前による明示呼び出し。/skill-name でユーザーが決定論的にトリガーできる。
• 共有可能性。git にチェックインすれば、全員が同じ手順で動く。

Skill ではないもの

• MCP サーバーではない。外部プロセスでも JSON-RPC でもない。ただのテキストファイル。
• モデルのファインチューンではない。モデルはそのままで、コンテキスト注入の仕方だけが変わる。
• ハードコードされた関数ではない。本文は自然言語の指示で、モデルが解釈する。同じ Skill が呼ばれるごとに少し違う挙動を見せうる。

Claude Code の中での位置

Claude Code には以前から複数の拡張機構があった — Custom Commands (スラッシュコマンド)、Subagents (.claude/agents/)、MCP サーバー、Plugins、CLAUDE.md。Skills は Custom Commands を吸収しながら登場し、今は最もよく使われる拡張単位だ。.claude/commands/foo.md と .claude/skills/foo/SKILL.md はどちらも /foo を作る — 同じスロットを取り合う。Skill のほうが豊富な機能 (専用ディレクトリ、自動 invoke、スクリプト同梱) を持つので、新規は Skill で書く。

2 章 · SKILL.md 形式 — 全フィールドを開く

最も混乱しやすい箇所なので、全フィールドを一度に並べる。すべてのフィールドは任意だが、実用上 description だけは必須だ。

---
name: my-skill
description: この Skill が何をするか、いつ使うかを一文で。
when_to_use: description で足りないとき、追加のトリガー文や例示要求を書く。
argument-hint: "[issue-number]"
arguments: [issue, branch]
disable-model-invocation: false
user-invocable: true
allowed-tools: Read Grep Bash(git *)
model: inherit
effort: high
context: fork
agent: Explore
paths: ["src/**/*.py", "tests/**/*.py"]
shell: bash
hooks:
  PreToolUse:
    - matcher: "Bash"
      command: "echo running bash"
---

ここからは自由なマークダウン本文。invoke 時に本文丸ごとがコンテキストに入る。

各フィールドの意味:

description の書き方 — 一番大事な一行

description はユーザー発話と照合される検索キーだ。良い description の性質:

1. 何をするか — 「PR の変更を要約しリスクを表示する」
2. いつ使うか — 「ユーザーが変更内容を尋ねる、コミットメッセージを求める、diff レビューを頼むとき」
3. ユーザーが実際に発しそうなキーワード — 「PR」「変更」「diff」「レビュー」

悪い例: description: 便利なツールです。モデルがいつ呼ぶか分からない。 良い例: description: conventional commit 規則に従ってコミットする。ユーザーが「コミット」「commit」「変更を保存」と言ったときに使う。

description と when_to_use を合わせて 1,536 文字までカタログに露出する。打ち切りに耐えるよう 要点キーワードは先頭に。

文字列置換 — $ARGUMENTS とその仲間

本文中に動的な値を差し込む置換子がいくつかある。

• $ARGUMENTS — invoke 時の引数文字列全体。
• $ARGUMENTS[0] または $0 — 最初の位置引数。
• $name — arguments: [name] で宣言された名前付き引数。
• ${CLAUDE_SESSION_ID} — 現在のセッション ID。
• ${CLAUDE_EFFORT} — 現在の effort レベル。
• ${CLAUDE_SKILL_DIR} — この SKILL.md があるディレクトリ。同梱スクリプトを参照するとき必須。

動的コンテキスト注入 — モデルが読む前にシェルを走らせる

本文中のインラインコードが ! で始まると、Claude が読む前にシェルが実行され、その出力が本文にインラインされる。複数行は ! 付きのコードフェンス。

## 現在の変更
!`git diff HEAD`

## PR 情報
```!
gh pr view --json title,body,labels
gh pr diff --name-only
```

## タスク
上記情報をもとにリリースノートを作る。

これは非常に強い — モデルが「diff を見せて」とツール呼び出しをする必要がなく、常に事実から始まる。invoke 時点の実際の状態が本文に入るからだ。

3 章 · 起動モデル — Claude はいつ Skill を呼ぶのか

最頻出の質問。答えは二つの経路だ。

経路 1: ユーザーの明示呼び出し。/skill-name [args]。メニューから選ぶのも同じ。この経路はいつでも動く。

経路 2: モデルの自動呼び出し。セッション開始時にすべての Skill の name + description (+ when_to_use) がカタログとしてモデルのコンテキストに入る。ユーザーが何かを言ったとき、モデルはカタログを走査して合致する Skill を発火させる。

自動 invoke が成立する条件:

1. Skill に disable-model-invocation: true がついていないこと。
2. description がユーザーの発話と意味的に合致すること。
3. paths が設定されている場合、作業中ファイルがパターンに合うこと。

「Skill が呼ばれません」のデバッグ

最も多い悩み。チェックリスト:

• description にユーザーが言いそうなキーワードはあるか?
• What skills are available? でカタログに見えているか?
• カタログが budget overflow で切れているか? /doctor で確認。
• 他の Skill がこの発話でより高いスコアを取っていないか?
• 名前が古い .claude/commands/ のファイルとぶつかっていないか?

「Skill が頻繁に呼ばれすぎます」

逆の問題も同じくらいよくある。description が一般的すぎるとあらゆる発話で候補に上がる。

• description をより具体的に。
• 副作用のあるコマンドは disable-model-invocation: true で塞ぐ。
• paths でトリガー範囲を絞る。

4 章 · ディレクトリレイアウトと住居

Skill はディレクトリ一つが単位だ。住居は四種類。

名前が衝突したら Enterprise > Personal > Project の順で優先。Plugin Skill は plugin-name:skill-name 名前空間で隔離されるので、他とは衝突しない。

ディレクトリの中のファイル

最小の Skill は一ファイル。本文が長くなったり補助資料が必要になったりすれば、同じディレクトリに置ける。

release-notes/
├── SKILL.md              # 必須。エントリーポイント。
├── template.md           # 出力テンプレート。SKILL.md が参照。
├── examples/
│   ├── good.md           # 出力例 1
│   └── bad.md            # 出力例 2 (反面教師)
├── references/
│   └── changelog-spec.md # Keep a Changelog 規約など詳細リファレンス
└── scripts/
    └── collect.sh        # SKILL.md から呼ぶシェルスクリプト

本文から他ファイルを参照するときは、モデルにそのファイルの中身と読みどころを知らせるため明示的に書く。

## 補助資料

- 出力形式の全体は `template.md` を参照。
- 良い例は `examples/good.md`、避けるべき例は `examples/bad.md`。
- 変更ログ規約の詳細は `references/changelog-spec.md`。

## データ収集

```!
bash ${CLAUDE_SKILL_DIR}/scripts/collect.sh
```

ポイント: SKILL.md は 500 行以内に保ち、長い資料は references/ に出す。一度 invoke された SKILL.md の本文はセッション中ずっとコンテキストに留まる — 毎ターンのトークンコストだ。

5 章 · ハンズオン — release-notes-from-git-log Skill を作る

ここで実物を一つ作る。目標は明快 — 直近の git タグ以降のコミットを見て、Keep a Changelog 形式のリリースノートを生成する Skill。PR 要約より一段深く、引数処理・動的コンテキスト・補助スクリプト・テンプレートまで一度に扱える。

ステップ 1: ディレクトリ作成

mkdir -p ~/.claude/skills/release-notes/{scripts,references,examples}
cd ~/.claude/skills/release-notes

ステップ 2: 補助スクリプト — 直近タグ以降のコミットを集める

scripts/collect.sh に保存。

#!/usr/bin/env bash
set -euo pipefail

LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")

if [[ -z "$LAST_TAG" ]]; then
  echo "## 直近タグなし — 全ログ"
  git log --pretty=format:"- %h %s (%an)" --no-merges
else
  echo "## 直近タグ: $LAST_TAG"
  echo ""
  echo "## それ以降のコミット"
  git log "${LAST_TAG}..HEAD" --pretty=format:"- %h %s (%an)" --no-merges
  echo ""
  echo "## それ以降のマージコミット"
  git log "${LAST_TAG}..HEAD" --merges --pretty=format:"- %h %s"
  echo ""
  echo "## 変更ファイル概要"
  git diff --stat "${LAST_TAG}..HEAD" | tail -1
fi

実行権限を付ける。

chmod +x scripts/collect.sh

ステップ 3: 出力テンプレート

references/template.md に保存。Keep a Changelog 1.1 に沿った骨格。

## [VERSION] - YYYY-MM-DD

### Added
- 新機能。外部から見える追加のみ。

### Changed
- 既存機能の変更。互換破壊でなければここ。

### Deprecated
- 次のメジャーで削除予定。

### Removed
- 今回削除されたもの。

### Fixed
- バグ修正。影響範囲を一行で。

### Security
- セキュリティパッチ。CVE があればリンク。

ステップ 4: 良い例 / 悪い例

examples/good.md。

## [1.4.0] - 2026-05-10

### Added
- OAuth2 デバイスフロー対応 (#234)。
- 環境変数 `RATE_LIMIT_PER_MIN` でトークンバケットを調整。

### Fixed
- 同時 1 万接続でのメモリリーク (#241)。
- Windows でのパス区切り処理の不具合。

### Security
- `axios` を 1.7.0 にアップグレード (CVE-2025-12345)。

examples/bad.md。

## v1.4.0

- いろいろ修正。
- バグ修正。
- 性能改善。
- リファクタリング。
- コード整理。

ステップ 5: SKILL.md — 本体

エントリーポイントを書く。これまでの資源を全部つなぐ。

---
name: release-notes
description: 直近の git タグ以降のコミットとマージを分析し、Keep a Changelog 形式のリリースノートを書く。ユーザーがリリースノート・チェンジログ・changelog・release notes の作成を依頼したときに使う。
when_to_use: 「次のリリースノート書いて」「今回の changelog 作って」「v1.5.0 リリースノート」のような発話でトリガー。
argument-hint: "[version]"
arguments: [version]
allowed-tools: Bash(git *) Read
effort: high
---

# Release Notes — Keep a Changelog

ターゲットバージョン: `$version` (未指定なら次の妥当な SemVer を推定)。

## 入力データ

```!
bash ${CLAUDE_SKILL_DIR}/scripts/collect.sh
```

## 出力形式

`${CLAUDE_SKILL_DIR}/references/template.md` の骨格に従う。カテゴリは
Added / Changed / Deprecated / Removed / Fixed / Security の六つのみ。

良い例: `${CLAUDE_SKILL_DIR}/examples/good.md`
避けるべき例: `${CLAUDE_SKILL_DIR}/examples/bad.md`

## 分類規則

1. conventional commit プレフィックスがあれば優先的に信頼する:
   - `feat:` は Added
   - `fix:` は Fixed
   - `refactor:` / `perf:` / `chore:` は外部可視の変化があれば Changed
   - `security:` / `sec:` は Security
2. プレフィックスがない、または曖昧なときはメッセージと差分統計で推定。
3. 純粋なリファクタ・テスト変更・CI 変更は **外部可視の影響がなければ除外**。

## トーンと長さ

- 各項目は一行。読み手が即座に何が変わったかわかること。
- 内部関数名やファイルパスは書かない。
- issue/PR 番号があれば末尾に `(#123)`。
- ASCII マークダウンのみ。絵文字禁止。

## 結果検証

書き終えたら次を確認:

- すべてのマージコミットがどこかに反映されているか?
- 「その他」「雑多な変更」のような分類を作っていないか?
- Security 項目に CVE リンクが抜けていないか?

不明な点があれば「このコミットはどのカテゴリにしますか?」とユーザーに問い、進める。

ステップ 6: テスト

セッションを開き、両方の起動経路を試す。

cd /path/to/your/repo
claude

# 1) 自動 invoke
> v1.5.0 のリリースノート作って

# 2) 明示 invoke
> /release-notes 1.5.0

どちらの経路でも同じ結果になるはず。呼ばれないなら description にキーワードが足りない、呼ばれすぎなら description を狭く。

ステップ 7: チームに共有

個人版で確認できたら、プロジェクトか plugin に移す。

# プロジェクト単位の共有
mv ~/.claude/skills/release-notes /path/to/repo/.claude/skills/
git add .claude/skills/release-notes
git commit -m "skill: add release-notes generator (Keep a Changelog)"

これで同じリポを clone した誰でも Claude Code を起動すればこの Skill を使える。

6 章 · パッケージングと配布

Skill を他人と共有する道は三つ。

6-1. Git 直接 — 最も単純

.claude/skills/ をリポにチェックイン。clone → claude 起動で完了。これで 90% のケースに答える。

長所: 別の基盤が要らない、バージョン管理が無料、コードレビューが自然に流れる。短所: 別リポでの再利用は copy-paste — plugin や dotfile 同期で補う。

6-2. Plugin — Skill・subagent・hook を束ねるとき

Claude Code Plugin は Skill、subagent、hook、command を一つのパッケージにまとめる単位だ。Plugin の中の Skill は <plugin>/skills/<name>/SKILL.md 構造で置く。Plugin はマーケットプレイス経由でインストールされる。

Plugin を選ぶとき:

• 関連 Skill 5 個以上を一緒に配布するとき。
• Skill に加えてカスタム subagent や hook も一緒に必要なとき。
• 外部利用者にワンコマンドインストールで届けたいとき。

6-3. Anthropic Skills Marketplace — 公開カタログ

2025 年 12 月に公開されたパートナー製 Skill ディレクトリ。Atlassian、Figma、Canva、Stripe、Notion、Zapier などが自社ワークフロー用 Skill を載せている。自分の Skill を公開配布したいならこの経路を検討。

セキュリティ留意

allowed-tools で権限を事前承認した Skill を git にチェックインすると、そのリポを clone した全員に同じ権限が与えられる。Claude Code は初回信頼時に workspace trust ダイアログを出すので一度はレビューの機会があるが、他人の Skill を無批判に有効化してはいけない。SKILL.md 本文、scripts/、allowed-tools を必ず読む。

7 章 · Skill vs MCP vs Subagent vs Plugin — 決定木

最も混乱しやすい箇所。四つは重ならない得意領域を持つ。

決定木

質問 1: 外部システムと通信する必要があるか? (DB、外部 API、特殊なファイルシステムツール)

• はい → MCP サーバー。新しい道具が要れば MCP。Skill は道具を作るのではなく、既存の道具の使い方を教える。
• いいえ → 質問 2。

質問 2: 別コンテキストで隔離して実行する必要があるか? (長い探索、別の権限)

• はい → Subagent、または context: fork 付きの Skill。
• いいえ → 質問 3。

質問 3: 複数の Skill・Subagent・Hook を一束で配布する必要があるか?

• はい → Plugin。単一の Skill でもマーケットプレイス配布なら plugin。
• いいえ → Skill。

具体例で見ると

要点: Skill は道具を作るのではなく、道具の使い方を教える。「新しい道具が要る」= MCP。「ある道具の使い方を毎回説明し直したくない」= Skill。

8 章 · 上級パターン

8-1. context: fork で subagent に委任

大きな作業はメインの対話コンテキストを汚す。context: fork を使うと、Skill 本文が新しい隔離コンテキストの task になり、結果だけがメインに戻る。

---
name: deep-research
description: 指定された主題をコードベースで深く調査する。ユーザーが「この機能はどこで実装されているか?」「なぜこう書かれているか?」と問うとき。
context: fork
agent: Explore
---

$ARGUMENTS をコードベースで深く調査:

1. Glob と Grep で関連ファイルを探す。
2. 主要ファイルを読み、呼び出しグラフを作る。
3. 発見を具体的な `file:line` 参照付きで要約する。

長所: メインの対話に 200 個のファイル全部が入ってこない。短所: 結果しか返ってこないので、途中に人が介在する余地が少ない。

8-2. allowed-tools で摩擦を減らす

「Bash 実行してもいい?」を毎回問わせないために事前承認する。ただし範囲は狭く。

allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)

Bash(*) ですべてのシェルを事前承認してはいけない。Skill が意図せず危険な命令を実行する余地ができる。

8-3. paths で自動 invoke 範囲を絞る

特定のファイルでだけ意味がある Skill は paths でトリガーを絞る。

paths: ["src/**/*.py", "tests/**/*.py"]

作業中ファイルがパターンに合わなければモデル自動 invoke の候補から外れる。ユーザーの明示 invoke は引き続き可能。

8-4. 動的コンテキストで事実から始める

最強パターンの一つ。invoke 時にシェル命令が実行され、出力が本文にインラインされる。

## 環境
```!
node --version
npm --version
git status --short
```

## 最近の変更
!`git log --oneline -10`

## タスク
上記環境で ...

モデルが「環境を見せて」とツールを呼ばなくてよく、常に実データで始まる。

8-5. hooks で決定論的に介入

Skill 有効中だけ動く hook をフロントマターに置ける。PostToolUse で lint を強制したり、PreToolUse で危険な命令を遮断したり。

8-6. ultrathink で深い推論を一度だけ

本文のどこかに ultrathink という単語を入れると、その Skill の間モデルがより深い推論モードに入る。複雑な意思決定が絡む Skill (例えば移行計画) で有用。全 Skill に乱用するとコストとレイテンシが跳ねる。

9 章 · 実例 — 人が作っている Skill たち

2026 年 5 月時点でよく見るパターン。

PR Summary — diff と PR 本文を受け取り、一画面要約 + リスク表示。最も多い Skill。

Conventional Commit — disable-model-invocation: true。/commit でだけトリガー。ステージ → メッセージ作成 → コミット。allowed-tools: Bash(git add *) Bash(git commit *)。

Release Notes — 先ほど作ったもの。会社ごとに形式が違うので自作の価値が高い種類。

Code Review Checklist — 自社コーディング規約に沿ったチェックリスト。references/ にセキュリティ・性能・アクセシビリティのガイドを置き、SKILL.md がエントリーポイント。

Runbook Executor — 運用手順の自動化。「デプロイをロールバックして」が入れば、正確な順序で helm rollback、Slack 通知、メモリ整理。

Bug Triage — issue 本文を読み、ラベル・優先度・担当者を提案。GitHub MCP とペア。

Migration Guide — コードベースの一部を React 16 から 19 に移すなど。arguments: [from, to, target]。

Content Drafting — ブログ草稿、ツイートスレッド、変更告知。会社のトーンガイドを references/ に。

Security Review — 新依存・新 API エンドポイントが入ったときのチェックリスト。CWE マッピング。

Database Migration — スキーマ変更手順。dry-run → diff → 承認 → デプロイ。PreToolUse hook で prod を保護。

Postmortem Drafter — インシデント後の振り返り草稿。5 whys、blameless トーン。

Docs Sync — コード変更後に README、API ドキュメント、変更ログを一緒に更新。paths を活用。

Cost Reporter — 直近 PR がクラウドコストにどう影響するかを推定。terraform plan + 価格表。

このリストはよく見る形にすぎない。最も価値があるのは自チームの実手順をカプセル化した Skill だ。「またこれ入力してる」が浮かぶたびに次の Skill の候補が一つ増える。

10 章 · アンチパターン — よくある壊れ方

数十個の Skill を作って見えた繰り返しの罠。

1. description が曖昧。「便利なツール」 — モデルがいつ呼ぶか決められない。
2. description が一般的すぎる。「コードを書く」 — ほぼ全発話に合致し、毎回 invoke される。
3. 本文が 500 行を超える。毎ターンのトークンコスト。references/ に出す。
4. allowed-tools: Bash(*)。全シェル命令を事前承認。事故の温床。範囲を絞れ。
5. 副作用のある命令に disable-model-invocation: false。モデルが勝手に /deploy を呼ぶ。副作用ありは常にユーザーのみ。
6. CLAUDE.md との重複。同じ指示を両方に書けば衝突と混乱。CLAUDE.md は常に当てはまる事実、Skill は状況別手順。
7. MCP で解くべきものを Skill で解く。外部 API 呼び出しをマークダウン指示で迂回。MCP サーバーを書け。
8. テストがない。Skill もコード。自動 invoke と明示 invoke の両方が動くか毎回確認。
9. バージョン管理なし。Skill を変えれば挙動が変わる。git の履歴が答え。
10. 名前衝突。Personal・Project・Plugin に同名 Skill。優先規則はあるが混乱を生む。衝突しない名前にする。

11 章 · Skill コンテンツのライフサイクル — トークンの内訳

見落としやすい細部。Skill が invoke されると、本文は一つのメッセージとしてコンテキストに入り、セッション終了まで留まる。毎ターン再読込されない。

自動コンパクションが走ると、最近 invoke された Skill が一部保持される。各 Skill の最初の 5,000 トークンまでが残り、全 Skill 合算で 25,000 トークン予算を直近のものから埋めていく。古い Skill はコンパクション後に丸ごと落ちることがある。

影響が消えたように見えたら — 本文はほぼ確実にコンテキストにあり、モデルが別の手段を選んだ可能性のほうが高い。description と本文の冒頭に行動を強制する表現 (must、never) を加える、または hook で決定論的に強制する。

エピローグ — Skill を意識する

Skill は「エージェントに何ができるか」を一行ずつ増やす最も安い方法だ。新しいモデルを待つ必要も、新しい MCP サーバーを書く必要もない。手順を一つのディレクトリに書き、git に push すれば、次のセッションからチーム全体がその手順を共有する。

9 項目チェックリスト

1. description は何・いつ・キーワードを揃えているか?
2. 本文は 500 行以内で、長い資料は references/ に出してあるか?
3. 副作用のある命令は disable-model-invocation: true か?
4. allowed-tools は狭く設定したか?
5. 動的コンテキスト (!) で事実から始まる作りになっているか?
6. 自動 invoke と明示 invoke の両方をテストしたか?
7. 名前は他の Skill や command と衝突しないか?
8. Personal / Project / Plugin の置き場を意識して選んだか?
9. 似た能力を MCP や Subagent で解くべきではないか?

アンチパターン早見

曖昧な description / 一般的すぎる description / 肥大した本文 / 広すぎる allowed-tools / 自動 invoke される危険命令 / CLAUDE.md との重複 / MCP で解くべきものを Skill で / テストなし / バージョン管理なし / 名前衝突。

次回予告

次の記事 — MCP サーバーを TypeScript SDK でゼロから 30 分で作る — 社内 API を露出させる が反対側の半分を埋める。Skill は手順をカプセル化し、MCP は新しい道具を作る。その次は plugin マーケットプレイスへの公開、そして Claude Code Hooks プレイブック — エージェントに大きな権限を渡すための決定論的なガードレール。

ここで作った release-notes Skill のような一枚のマークダウンが、チームの手順を永遠に変える。「またこれ入力してる」が浮かぶたびに、それが次の Skill の候補だ。

参考 / References

• Anthropic — Extend Claude with skills (Claude Code 公式ドキュメント)
• GitHub — anthropics/skills (公式サンプル Skill リポ)
• Anthropic — The Complete Guide to Building Skills for Claude (PDF)
• Agent Skills オープン標準サイト
• Anthropic — Subagents (Claude Code)
• Anthropic — Plugins (Claude Code)
• Anthropic — Hooks (Claude Code)
• Anthropic — Memory / CLAUDE.md
• Anthropic — Permissions
• The New Stack — Agent Skills: Anthropic's Next Bid to Define AI Standards
• VentureBeat — Anthropic launches enterprise Agent Skills and opens the standard
• Keep a Changelog 1.1 仕様
• Model Context Protocol 公式サイト