
複数リポジトリでClaude Codeのルール・スキルを一元管理する
はじめに
Claude Code を複数のリポジトリで使っていると、同じルールやスキルを各リポジトリにコピーしたくなります。
ただ、この運用は長く続けると負担が増えていきます。
- 共通ルールを更新するたびに、各リポジトリを修正する必要がある
- どこまでが共通で、どこからがリポジトリ固有なのかが曖昧になる
- スキルや運用手順が少しずつズレていく
そこで今回は、「チーム共通のルール・スキルは1か所で管理し、リポジトリ固有の内容は各 CLAUDE.md に残す」という構成を紹介します。
実現方法はシンプルです。
- 共通ルール・スキルは専用リポジトリで管理する
- 各リポジトリからはシンボリックリンクで参照する
- Claude Code の
SessionStartHook で、起動時に共通リポジトリのローカル clone を更新する
検証環境は macOS / Linux です。Windows 環境では動作確認していません。
共通ルールを使って実際にどんなワークフローができるかは、Claude Code と GitHub Projects で、チーム開発のコンテキスト共有とタスク管理を自動化する を参照してください。
この記事の方針
この記事で分けたいのは、次の 2 種類です。
- チーム共通のルール・スキル: タスク管理、PR レビュー観点、コミットメッセージ規約
- リポジトリ固有のルール: 技術スタック、ディレクトリ構造、コーディング規約、固有ラベル
共通の運用知識は専用リポジトリにまとめ、各プロジェクトの CLAUDE.md から参照します。
Claude Code では CLAUDE.md が起動時に読み込まれ、さらに @path/to/file 形式で他ファイルを import できます。相対パス・絶対パスのどちらも使えます。
全体像

やっていることは 3 つです。
- 共通ルール・スキルは専用リポジトリで管理する
- 各リポジトリからはシンボリックリンクで参照する
SessionStartHook で、Claude Code 起動時に共通リポジトリのローカル clone を更新する
なぜシンボリックリンクか
いくつかの方法を検討しました。
- コピー: 各リポジトリにファイルをコピーする。依存関係はないが、更新時は全リポジトリを修正する必要がある
- Git Submodule: 共通リポジトリを埋め込む。バージョン固定やディレクトリ構造の自由度は高いが、clone 時や更新時に専用コマンドが必要
- GitHub Actions: 共通リポジトリ更新時に各リポジトリへ PR を自動作成する。反映管理はしやすいが、構成がやや大掛かりになる
- シンボリックリンク: 共通リポジトリをローカルで参照する。設定が比較的シンプルで、ローカルの共通リポジトリが更新されれば参照先にもすぐ反映される。リンク自体は Git で追跡できる
Git Submodule には、バージョン固定や配置の自由度といった利点があります。
ただ、今回の用途では次のような条件がありました。
- 共通ルールは常に最新を使いたい
- 各リポジトリは同じ親ディレクトリ配下に置ける
- なるべくシンプルに運用したい
これらの条件を踏まえると、シンボリックリンクが最も扱いやすいと判断しました。
前提条件と制約
相対パスで共有する前提
シンボリックリンク自体は絶対パスでも作成できます。
ただし今回は、「開発者間で同じリンク設定を Git で共有しやすいよう、相対パスで作成する」という前提にしています。
そのため、各リポジトリと共通リポジトリは、同じ親ディレクトリ配下に配置する必要があります。
~/projects/ ← 親ディレクトリ
├── shared-rules-repo/ ← 共通ルール管理
├── repo-web/ ← Web フロントエンド
├── repo-mobile/ ← モバイルアプリ
└── repo-backend/ ← バックエンドAPI
この構成であれば、各リポジトリから共通リポジトリへの相対パスを固定できます。
他の開発者が使うときの前提
各リポジトリ側のリンク設定は Git で配布できますが、利用者のローカル環境にも、リンク先となる共通リポジトリが所定の位置に clone されている必要があります。
つまり、「1 人が設定してコミットすれば終わり」ではなく、以下のような役割分担になります。
- 各リポジトリ側の準備は代表者が用意できる
- 各利用者は、共通リポジトリを同じ相対位置に配置する
Step 1. 共通ルール用リポジトリを作る
まず、共通のルールやスキルを配置する専用リポジトリを作成します。
shared-rules-repo/
├── shared-claude-rules/
│ └── workflow-rules.md
└── shared-claude-skills/
├── deploy/
│ └── SKILL.md
├── review/
│ └── SKILL.md
└── continue/
└── SKILL.md
たとえば shared-claude-rules/workflow-rules.md に、チーム共通のタスク管理ルールを書きます。
# タスク管理(GitHub Projects カンバン)
## 作業フロー
1. 着手時: assignee を自分に設定し、ステータスを「In progress」に変更
2. 完了時: ステータスを「In review」に変更
3. 作業中: 進捗を Issue コメントに記録
## よく使うコマンド
- カンバン確認: `gh project item-list <PROJECT_NUMBER> --owner <ORG> --format json`
- ステータス変更: `gh project item-edit --project-id <ID> ...`
Step 2. 各リポジトリからシンボリックリンクで参照する
各開発リポジトリでは、共通リポジトリ内のファイルへシンボリックリンクを作成します。
cd repo-web
# ルール置き場を作成
mkdir -p .claude/rules
# 共通ルールへのシンボリックリンクを作成
ln -s ../../../shared-rules-repo/shared-claude-rules/workflow-rules.md \
.claude/rules/workflow-rules.md
# スキルも同様
mkdir -p .claude/skills/deploy
ln -s ../../../../shared-rules-repo/shared-claude-skills/deploy/SKILL.md \
.claude/skills/deploy/SKILL.md
# Git に追加
git add .claude/rules/ .claude/skills/
git commit -m "feat: 共通ルール・スキルへのシンボリックリンクを追加"
シンボリックリンクの確認
正しく設定できているかは ls -la で確認できます。
ls -la .claude/rules/
# lrwxr-xr-x 1 user staff ... workflow-rules.md -> ../../../shared-rules-repo/...
- 先頭が
lで始まる行がシンボリックリンク ->の後ろにリンク先パスが表示される- リンク先が存在しない場合は、環境によっては色や表示で判別できる
Step 3. CLAUDE.md から参照する共通ルール
.claude/rules/ には、チーム共通で使うルールを配置します。
| ファイル | 内容 |
|---|---|
session-start-rules.md |
セッション開始時の通知 |
kanban-rules.md |
タスク管理・カンバン |
CLAUDE.md では、必要な共通ルールを @path 構文で読み込みます。
## 共通ルール
@.claude/rules/session-start-rules.md
@.claude/rules/kanban-rules.md
## このリポジトリ固有の補足
- Issue を作成する場合、ラベルは `frontend` を付与する。
Step 4. SessionStart Hook で共通リポジトリを自動更新する
シンボリックリンクは、ローカルにある共通リポジトリを参照しているだけです。
そのため、共通リポジトリのリモート側が更新されても、手元の clone が古いままでは最新のルールは取り込まれません。
そこで、Claude Code の SessionStart Hook を使って、起動時に共通リポジトリを git fetch / git pull するようにします。
Claude Code の Hook は設定ファイルで管理できます。SessionStart はセッション開始時に実行され、startup / resume / clear / compact の matcher が使えます。また、SessionStart Hook の stdout は追加コンテキストとして Claude Code に渡されます。
設定ファイルの置き場所
Hook は以下のような設定ファイルで管理できます。チームで共有したい場合は .claude/settings.json、個人ごとに持ちたい場合は .claude/settings.local.json が適しています。
~/.claude/settings.json: ユーザー全体設定.claude/settings.json: プロジェクト設定.claude/settings.local.json: ローカル専用設定(通常はコミットしない)
Hook の設定
まずは一番シンプルな方法として、設定ファイルにインラインで記述する例を紹介します。
{
"hooks": {
"SessionStart": [
{
"matcher": "startup",
"hooks": [
{
"type": "command",
"command": "(cd ../shared-rules-repo 2>/dev/null || { echo '⚠ shared-rules-repo が見つかりません'; exit 0; }; git fetch --quiet 2>/dev/null || { echo '⚠ fetch に失敗しました'; exit 0; }; LOCAL=$(git rev-parse HEAD); REMOTE=$(git rev-parse @{u} 2>/dev/null || echo ''); [ -z \"$REMOTE\" ] && { echo '⚠ upstream が設定されていません'; exit 0; }; [ \"$LOCAL\" = \"$REMOTE\" ] && { echo '✓ 共通ルールは最新です'; exit 0; }; git pull --ff-only --quiet 2>/dev/null && echo '✓ 共通ルールを更新しました' || echo '⚠ pull に失敗しました')"
}
]
}
]
}
}
処理の流れは以下のとおりです。
Claude Code 起動
↓
SessionStart Hook 実行
↓
shared-rules-repo で git fetch
↓
ローカルと upstream を比較
↓
差分があれば git pull --ff-only
↓
結果を stdout に出力
↓
その内容がセッション開始時の追加コンテキストとして Claude Code に渡る
SessionStart Hook の stdout は、通常の会話本文ではなく、セッション開始時の追加コンテキストとして Claude Code に渡されます。成功時に「✓ 共通ルールを更新しました」のような短いメッセージを出力しておくと、Claude Code が現在の状態を把握しやすくなります。
Hook の動作確認
意図どおりに更新されるかは、共通リポジトリ側に差分を作って確認できます。
cd ../shared-rules-repo
# 最新を取得(pull はしない)
git fetch
# ローカルと upstream の差分を確認
git log HEAD..@{u} --oneline
ここでコミットが表示されれば、ローカルは未更新の状態です。
この状態で Claude Code を起動すると、Hook が git pull --ff-only を実行し、次回以降は最新の共通ルールを参照できるようになります。
なお、Hook 設定はセッション開始時に読み込まれます。設定ファイルを変更しても、その変更は現在のセッションには即時反映されません。動作を確認したいときは、新しいセッションを開始するのが確実です。
運用上の注意
オフライン時や upstream 未設定時は更新に失敗しますが、その場合でも既存のローカル内容を参照するため、作業自体は続けられます。
ただし、チームの最新ルールとズレる可能性があります。
共通リポジトリに未コミットの変更があると git pull --ff-only が失敗しやすいため、共通ルールは PR ベースで更新する運用が安全です。
Hook はローカルで任意のコマンドを実行できる仕組みなので、チームで共有する場合は内容をレビューし、設定変更も Git で追える形にしておくことをおすすめします。
誰が何をやるか
初回セットアップで代表者が用意できること
| 作業 | 備考 |
|---|---|
| 共通ルールリポジトリの作成 | shared-claude-rules/ や shared-claude-skills/ を配置 |
| 各リポジトリでシンボリックリンク作成 | Git でリンク設定を配布できる |
各リポジトリの CLAUDE.md に import を追加 |
共通と固有の責務を分離できる |
Hook 設定を .claude/settings.json に追加 |
共有設定として配布可能 |
リポジトリ数が多い場合は、リンク作成や Hook 配置をスクリプト化しておくと楽です。
各利用者がやること
| 作業 | 理由 |
|---|---|
| 各リポジトリを同じ親ディレクトリ配下に clone | 相対パスのリンクが前提のため |
shared-rules-repo も所定の位置に clone |
リンク先の実体が必要 |
CLAUDE.md の import が解決できることを確認 |
/memory で確認可能 |
.claude/settings.local.json を使う場合は各自設定 |
ローカル専用設定のため |
共通スキルも同じ考え方で配布できる
同じ構成で、チーム共通のスキル定義ファイルも共有できます。
shared-rules-repo/
└── shared-claude-skills/
├── deploy/SKILL.md
├── review/SKILL.md
└── continue/SKILL.md
各リポジトリでは、必要なスキルだけシンボリックリンクを作成します。
mkdir -p .claude/skills/review
ln -s ../../../../shared-rules-repo/shared-claude-skills/review/SKILL.md \
.claude/skills/review/SKILL.md
その上で、必要に応じて CLAUDE.md から参照する構成にしておくと、どの知識を使わせたいかが整理しやすくなります。
どんなルールを共有するとよいか
判断基準はシンプルです。「どのリポジトリでも同じかどうか」で決めます。
| 共通リポジトリに置くもの | 各リポジトリに残すもの |
|---|---|
| タスク管理ワークフロー | 技術スタック(React、Flutter など) |
| GitHub Projects の操作方法 | ディレクトリ構造 |
| コミットメッセージ規約 | リポジトリ固有のコマンド |
| PR レビュー観点 | 環境構築手順 |
| チーム共通の作業継続手順 | コーディング規約の細かいルール |
たとえば、技術スタックやディレクトリ構造、命名規則などはプロジェクトごとに異なりやすいので、各 CLAUDE.md に残した方が自然です。
一方で、タスク管理やレビュー観点のようなチーム全体の運用知識は、共有リポジトリで一元管理すると効果が出やすくなります。
まとめ
複数リポジトリで Claude Code を運用するなら、以下の構成がおすすめです。
- チーム共通のルール・スキルは専用リポジトリで管理する
- 各リポジトリ固有の文脈は
CLAUDE.mdに残す - シンボリックリンクで参照し、
SessionStartHook でローカル clone を同期する
この構成にすれば、更新コストを抑えながら、共通運用と個別文脈を分離できます。
派手な仕組みではありませんが、以下の点でチーム運用にはちょうどよいバランスだと感じています。
- Git で追える
- 仕組みが理解しやすい
- 複数リポジトリへ横展開しやすい







