Skillの実体はただのフォルダです。特別な配布形式は要らず、zipで送ってもGitで共有してもそのまま動きます。チームで使うなら、プロジェクトの.claude/skills/をリポジトリに含めるのが最も手間のない方法です。

1本のSkillを自分だけで使っているうちは、置き場所を気にする必要はありません。しかし成果が出てくると、次に考えるのは「これをチームの他のメンバーにも使わせたい」「別のプロジェクトでも使いたい」という展開の問題です。この章では、Skillを配る方法と、展開したあとに崩れないための最低限のルールを整理します。

Skillはフォルダなので配布方法を選ばない

SkillはSKILL.mdと付随ファイルが入ったただのフォルダです。特殊なパッケージ形式ではないため、配布方法は既存の手段がそのまま使えます。

  • zipで送る。フォルダごと圧縮してチャットやメールで渡すだけで、受け取った側は所定の場所に展開すれば使えます。1回限りの共有や、社外の相手に渡す場合に向いています。
  • Gitで共有する。リポジトリに含めてクローンさせる方法です。継続的に更新するSkillや、複数人が同時に使うSkillはこちらが基本になります。

どちらの方法でも、渡す実体は同じフォルダです。配布形式によってSkillの中身を書き換える必要はありません。

チーム展開の基本は.claude/skills/をリポジトリに含める

1つのプロジェクトに閉じたSkillであれば、プロジェクトの.claude/skills/配下に置いてそのままリポジトリにコミットするのが最も確実です。リポジトリをクローンした時点で全員が同じSkillを持つため、配布の手順そのものが不要になります。

project/
├── .claude/
│   └── skills/
│       ├── article-draft/
│       │   └── SKILL.md
│       └── deploy-check/
│           └── SKILL.md
├── src/
└── README.md

この構成にしておけば、Skillの追加や改訂もプロジェクトの他のコード変更と同じレビュー、同じコミット履歴の中で扱えます。誰が何を変えたかが後から追えるという点で、Skillだけを別ルートで配る方法より事故が少なくなります。

複数プロジェクトで使うSkillはプラグイン化かテンプレート化する

1つのプロジェクトに閉じない、組織として横断的に使うSkillも出てきます。この場合は.claude/skills/に置く方式では、プロジェクトごとにコピーが増えて版がずれていきます。対処法は2つあります。

1. プラグイン化する

共通で使うSkillをまとめて1つのプラグインとして切り出し、プロジェクト側からはそのプラグインを参照するだけにする方法です。改訂は元のプラグイン側で1回行えば済み、各プロジェクトへの反映も参照の更新だけで完了します。

2. テンプレートリポジトリ化する

新規プロジェクトを立ち上げるたびに、共通Skillをまとめたテンプレートリポジトリから複製する方法です。プラグインほど密結合にしたくない場合や、プロジェクトごとにSkillを一部カスタマイズしたい場合に向いています。ただしこの方式は複製した時点で版が分岐するため、後述の版管理を怠ると同じSkillの古い版が各所に残り続けます。

導入手順書を添える

Skillを配布するときは、SKILL.md本体だけでなく導入手順書(README)を必ず添えます。受け取った相手が迷うのは大抵、置き場所とフォルダ名です。

# article-draft Skill 導入手順

1. このフォルダを `.claude/skills/article-draft/` に配置する
2. フォルダ名は変更しない(呼び出し名と一致させるため)
3. `/article-draft` で呼び出せることを確認する

## 前提
- 参考資料として `references/` 内のスタイルガイドを同梱。削除しない

手順書に書くのは、フォルダの置き場所、フォルダ名を変えてはいけない理由、同梱ファイルの役割の3点で十分です。長い説明は不要で、迷いをなくすことだけを目的にします。

版管理はGitで行い、改訂点を1行で記録する

Skillも本文と同じコードなので、Gitで版を追うのが最も確実です。特別な運用は要らず、コミットメッセージに何を変えたかを1行で書くだけで十分機能します。

git commit -m "fix: article-draft Skillに文字数上限の判定基準を追加"
git commit -m "docs: deploy-check Skillの手順から廃止したコマンドを削除"

この1行の記録があるだけで、「いつから挙動が変わったか」「なぜ変えたか」を後から追えます。第5章で扱う改訂の作法は、この版管理の土台があって初めて機能します。

なお、当メディアの運営元では117名規模のAI社員組織でSkillを運用しており、各社員のSkillもリポジトリ管理の対象にしています。人数が増えても仕組み自体は本章で書いた内容と変わらず、フォルダをリポジトリに含めて版を追うという基本を維持しているだけです。

← 第3章へ 記事一覧へ戻る 第5章へ →