個人でClaude Codeを使っている分には、SKILL.mdをローカルで管理するだけで十分です。しかしチーム開発になると話が変わります。「誰がいつスキルを更新したか」「この変更は全員に伝わっているか」「本番環境と開発環境でスキルが食い違っていないか」——こういった問いに答えられる体制が必要になります。
gh skill はそのインフラを提供するツールですが、それを本番品質で運用するには、設計の深さが求められます。ここでは私が実際のプロジェクトで試行錯誤しながら構築したマルチエージェント・スキル管理の設計パターンをお伝えします。
なぜスキル管理に「設計」が必要なのか
まず、よくある失敗パターンを共有します。
gh skillを使い始めた初期段階で、多くのチームがやりがちなのが「とりあえず一つのリポジトリに全部のスキルをまとめる」アプローチです。これは最初は便利に見えますが、すぐに問題が出ます。
バックエンドチームが追加したスキルがフロントエンドの作業を邪魔したり、AIエージェントが矛盾する指示を受け取ったりします。「このプロジェクトではTypeScriptを使う」と「JavaScriptを優先する」が同じスキルセットに共存するような状況です。
設計が必要な理由はここにあります。スキルにはスコープがあります。それを意識した構造にしないと、スケールしません。
スキルリポジトリの構造設計
本番運用に耐えるスキルリポジトリの構造を紹介します。
team-skills/
├── skill.yaml # メインメタデータ
├── README.md
├── CHANGELOG.md
├── .github/
│ └── workflows/
│ ├── validate.yml # スキルの自動検証
│ └── release.yml # バージョンリリース自動化
├── base/
│ ├── code-style.md # 全プロジェクト共通ルール
│ └── git-workflow.md # Gitフロー
├── frontend/
│ ├── react-patterns.md # Reactのパターン集
│ └── testing-frontend.md # フロントエンドテスト
├── backend/
│ ├── api-design.md # API設計規約
│ └── database-patterns.md # DBパターン
└── agent-overrides/
├── claude-code-specific.md # Claude Code専用の高度な設定
└── copilot-hints.md # Copilot向け補完ヒント
skill.yaml でこの構造を定義します:
name: team-skills
version: 2.1.0
description: "チーム共通コーディングスキル集"
maintainer: "platform-team@example.com"
agents:
- claude-code
- copilot
- cursor
- gemini-cli
# プロファイル: 役割別にスキルセットをグループ化
profiles:
frontend:
skills:
- base/code-style.md
- base/git-workflow.md
- frontend/react-patterns.md
- frontend/testing-frontend.md
agents: [claude-code, copilot, cursor]
backend:
skills:
- base/code-style.md
- base/git-workflow.md
- backend/api-design.md
- backend/database-patterns.md
agents: [claude-code, copilot, cursor, gemini-cli]
fullstack:
extends: [frontend, backend]
# エージェント固有の追加設定
agent_overrides:
claude-code:
append: agent-overrides/claude-code-specific.md
copilot:
append: agent-overrides/copilot-hints.mdプロファイルを使うことで、フロントエンドエンジニアは gh skill install team/team-skills --profile frontend、バックエンドエンジニアは --profile backend と使い分けられます。
セマンティックバージョニングとCHANGELOGの運用
スキルはコードと同様に、変更履歴を管理する必要があります。私はセマンティックバージョニングを採用しています。
- MAJOR(例:1.0.0 → 2.0.0): 既存のスキルを大幅に書き換えたり、削除したりした場合。AIの動作が大きく変わる可能性がある変更。
- MINOR(例:1.0.0 → 1.1.0): 新しいスキルや指示を追加した場合。既存の動作は変えありません。
- PATCH(例:1.0.0 → 1.0.1): 誤字修正、表現の改善など。機能的な変化なし。
CHANGELOG.md にはどのAIエージェントの動作が変わったかを明記します:
## [2.1.0] - 2026-04-15
### Added
- `backend/database-patterns.md`: PostgreSQL jsonb型の扱い方を追加
- Agents affected: Claude Code, Copilot, Cursor
- `agent-overrides/claude-code-specific.md`: PreToolUseフックの標準設定を追加
- Agents affected: Claude Code only
### Changed
- `base/code-style.md`: TypeScript strictモードを必須に変更
- Breaking change for agents: all
- Migration guide: tsconfig.jsonにstrict:trueを追加してください
## [2.0.0] - 2026-03-01
### Removed
- `frontend/vue-patterns.md`: プロジェクトのReact統一に伴い削除GitHub Actionsによる自動検証パイプライン
スキルファイルの品質を人間のレビューだけに頼るのは限界があります。CIで自動検証するパイプラインを組みます。
# .github/workflows/validate.yml
name: Validate Skills
on:
pull_request:
paths:
- '**.md'
- 'skill.yaml'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup gh skill
run: gh extension install github-actions/gh-skills
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Validate skill.yaml structure
run: gh skill validate
- name: Check for broken internal links
run: |
# スキルファイル間の参照整合性チェック
gh skill lint --check-links
- name: Verify agent compatibility
run: |
# 各エージェントへのデプロイシミュレーション
gh skill dry-run --agent claude-code
gh skill dry-run --agent copilot
gh skill dry-run --agent cursor
- name: Check CHANGELOG updated
run: |
# スキルの変更時にCHANGELOGが更新されているか確認
if git diff --name-only origin/main | grep -q "\.md$"; then
if ! git diff --name-only origin/main | grep -q "CHANGELOG.md"; then
echo "❌ スキルファイルが変更されましたが、CHANGELOGが更新されていません"
exit 1
fi
fiリリースの自動化も設定します:
# .github/workflows/release.yml
name: Release Skills
on:
push:
tags:
- 'v*'
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Create GitHub Release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ github.ref }}
release_name: Release ${{ github.ref }}
body_path: CHANGELOG.md
- name: Notify team via Slack
run: |
# チームへのSlack通知(スキルが更新されたことを知らせる)
curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
-d "{\"text\": \"🎯 team-skills ${{ github.ref }} がリリースされました。\ngh skill update team-skills で更新してください。\"}"エージェント別のスキル最適化
最も重要で、かつ見落とされがちな点が「エージェントによる解釈能力の差」です。
Claude Codeが最も深く解釈できること
Claude Codeは現時点で最もリッチなスキル解釈ができます。以下はClaude Code専用の高度な設定例です:
<!-- agent-overrides/claude-code-specific.md -->
## PreToolUseフック設定
以下のファイルへの書き込み前に必ず確認を取ること:
- `production.env`
- `database/migrations/`
- `src/auth/`
## ツール使用制限
本番環境(NODE_ENV=production)では以下のコマンドを実行しないこと:
- `npm run migrate`
- `git push --force`
- データベースへのDELETEクエリ
## ワークフロー定義
コードレビューを求められた場合、以下の順序で実行すること:
1. 型エラーのチェック(tsc --noEmit)
2. リントの実行(eslint src/)
3. テストの実行(npm test)
4. セキュリティスキャン(npm audit)GitHub Copilotへの指示の書き方
Copilotはより単純な指示しか解釈しません。「〜すること」「〜しないこと」という明確な命令文が効果的です:
<!-- agent-overrides/copilot-hints.md -->
## コードスタイル
- TypeScriptを使用する。anyは使わない
- 関数はアロー関数を優先する
- コメントは日本語で書く
- エラーハンドリングは必ずcatch節を含める
## 禁止事項
- console.logをそのままコミットしない
- ハードコードされたURLや認証情報を書かないCursorとの統合
Cursorは .cursorrules と SKILL.md の両方を参照できますが、gh skillがインストールするのはプロジェクトルートの .cursor/skills/ ディレクトリです。既存の .cursorrules と競合しないよう注意が必要です:
# Cursorユーザー向け:既存の.cursorrulesとの統合
gh skill install team/team-skills --agent cursor --no-override-rulesモノレポでのスキル管理
モノレポ環境では、パッケージごとに異なるスキルを適用したい場合があります:
monorepo/
├── skill.yaml # 共通スキル
├── packages/
│ ├── frontend/
│ │ └── skill.yaml # フロントエンド専用(共通スキルを継承)
│ └── backend/
│ └── skill.yaml # バックエンド専用
各パッケージの skill.yaml では親の設定を継承しつつ拡張できます:
# packages/frontend/skill.yaml
extends: ../../skill.yaml
name: frontend-skills
additional_skills:
- skills/react-specific.md
- skills/storybook-patterns.md実際に運用してわかったこと
半年ほどこの仕組みを使ってみて、印象的だったのは「AIへの指示の品質が可視化される」という点でした。SKILL.mdをPRレビューの対象にすることで、「この指示は曖昧すぎてAIが意図通りに動かない」という問題が議論の俎上に乗るようになりました。
コードのコーディング規約はlinterで自動チェックできますが、AIへの指示の品質はこれまで個人の感覚に委ねられていました。gh skillとGitフローを組み合わせることで、初めてそれが「チームの資産」として管理できるようになります。
スキルリポジトリのトップレベルに examples/ ディレクトリを作り、「このスキルを使ったときにAIがどう応答するか」のサンプルを置いておくと、新しいチームメンバーへのオンボーディングにも使えます。
設計は最初は大げさに見えても、チームが5人を超えたあたりから「あのときちゃんと作っておいてよかった」と感じる部分です。最初から完璧にしなくていいですが、少なくとも skill.yaml の構造とCHANGELOGの運用だけは最初に決めておくことをお勧めします。