チームでスキルを配る：gh skill でピン留め、apm でマニフェスト化、出自で置き場所を分ける
Agent Skills はエージェントへの命令書そのものなので、パッケージと同じく「バージョン固定・改ざん検知・入れる前に読む」が要る。GitHub CLI の gh skill（2026-04 公開）か Microsoft の apm を使い、自作・他人・案件の3種類で置き場所を分けると、更新の巻き戻り事故も防げる。
どんな場面で使う？
- 公開スキルを
npx skills addで入れているが、配布元が書き換わったら気づけない - チームでスキルを共有したいが、全員に全スキルを配るのは避けたい
- リポジトリを clone したら同じスキル・MCP 構成が揃う状態にしたい
gh skill（GitHub CLI v2.90.0 以上、public preview）
bash
gh skill search mcp-apps # 探す
gh skill preview OWNER/REPO SKILL # 入れる前に SKILL.md を読む
gh skill install OWNER/REPO SKILL --agent claude-code --scope user
gh skill install OWNER/REPO SKILL --pin v1.2.0 # タグかコミットに固定
gh skill update --dry-run # 更新があるかだけ確認
gh skill update --all
gh skill publish --fix # 自作スキルを仕様チェックして公開--agentは claude-code / cursor / codex / gemini / antigravity（省略時は Copilot）。各エージェント本来のディレクトリ（Claude Code なら~/.claude/skills/）にコピーされる。npx skillsは~/.agents/skills/を正にして symlink を張る方式なので、両方を混ぜない- インストール時に
SKILL.mdの frontmatter のmetadataにgithub-repo/github-ref/github-tree-shaが書き込まれる。ファイルを別プロジェクトにコピーしても由来と更新判定がついて回る updateはタグ名ではなくディレクトリの tree SHA で差分を判定するので、タグを付け替える force push にも気づける。--pinしたものはupdateで飛ばされるpublishは agentskills.io 仕様（名前とディレクトリ名の一致、name/descriptionの有無、allowed-toolsが文字列か等）を検査し、tag protection・secret scanning・code scanning・immutable releases の有効化も勧めてくる
GitHub はスキルの中身を検証しない。プロンプトインジェクションや隠し命令は preview で読んで判断する（読むこと自体をスキル化するのも手）。
apm（Agent Package Manager）
スキルだけでなく、指示・プロンプト・hooks・プラグイン・MCP サーバーを apm.yml に宣言し、apm install で各エージェントへ展開する。clone した人が同じ構成になるのが利点。
yaml
# apm.yml
name: your-project
version: 1.0.0
targets:
- copilot
dependencies:
apm:
- anthropics/skills/skills/frontend-design
- microsoft/apm-sample-package#v1.0.0
mcp:
- name: io.github.github/github-mcp-server
transport: httpapm.lock.yamlに解決結果とハッシュを記録。apm auditで隠し Unicode の検査や、手編集による差分（ドリフト）を検出できる- 組織では
apm-policy.ymlで「許可するソース・スコープ」を決められる - @mizchi さんはチームでの共有に採用したが、使い方を知らないモデルのために「apm の使い方」スキルを書く羽目になったとのこと。新しいツールを入れたら、その利用者向けスキルもセットで用意する（よく使う CLI の「利用者向けリファレンス」をスキルにして持たせる）
置き場所は「出自」で分ける（@kamo__shika さんの運用）
| 出自 | 例 | 管理 |
|---|---|---|
| 自作 | 自分のワークフロー | 自分の dotfiles（chezmoi の dot_claude/skills/） |
| 他人の公開スキル | skills.sh / GitHub のもの | gh skill や skills CLI |
| 案件固有 | デプロイ手順・チケット運用 | プロジェクトの .claude/skills/ にコミット |
- 同じスキルを2つの仕組みで管理すると、片方の update をもう片方の apply が古い内容で上書きする
- チーム共通リポジトリに集めず、各自の dotfiles を source of truth にして欲しい人が pull する形にすると、不要なスキルを配らずに済み、メンテナーにも負荷が集中しない
- この運用ルール自体を
skill-managementスキルにして配ると、「スキル追加して」と言った時点でエージェントが分類を確認してくれる - GHE 上のスキルは skills CLI の
skills updateが何も言わずにスキップする（api.github.com固定のため）。同じ URL でskills addを再実行して上書きするのが回避策 - 社内 private リポジトリのスキルは、Claude Code のプラグイン経由なら git の認証だけで入る。npm で配ると
.npmrcのトークンが要って面倒（@syun_blue さん）
注意点
- 入れすぎると description だけでもコンテキストを食う: AIコーディング: skills を入れすぎない → 「skill-selector」だけ常駐させ、リポジトリごとに明示的に入れる
gh skillは public preview なので、コマンドやオプションが変わる可能性がある