.claude設定のための一元ライブラリ

マシンに10個のリポジトリがある。そのすべてに.claudeフォルダーが詰め込まれており、エージェント、スキル、コマンド、フック、そしてCLAUDE.mdが入っている。いくつかは最新の状態を保っている。ほとんどは数週間前からずれ始めた。先月修正したコードレビューエージェントは一つのプロジェクトにしか存在せず、残りの9つには反映されていない。チームメイトが配布したプランニングコマンドは、彼らのリポジトリにしかないため、あなたはまだ見たことがない。

これが.claudeフォルダーの配布問題だ。プロジェクトを追加するたびに問題は大きくなる。

すぐできる改善策: .claudeコンテンツ全体を一か所に収めるプライベートGitリポジトリを立ち上げ、map.jsonでどのプロジェクトにどのアイテムを配布するかを指定する:

{
  "projects": {
    "~/projects/webapp": {
      "claude-md": "web-full",
      "skills": ["git-commits", "react", "frontend-design"],
      "agents": ["visual-explainer"],
      "commands": ["team-plan", "build"]
    }
  }
}

コマンドを一つ実行すれば同期が走り、各プロジェクト内の.claudeフォルダーがマップのエントリーと一致するようになる。現地でスキルやエージェントを修正してアップストリームに戻せば、そのアイテムを参照しているすべてのプロジェクトが次の同期時に修正を引き継ぐ。

.claudeフォルダー管理が重要な理由

一つのコードベースで作業している場合、スキル、エージェント、コマンドはコードのすぐそばにある。すべてが手の届く範囲にあり、すべてが最新の状態だ。

5〜6プロジェクトをまたぐと崩壊する:

• あちこちに重複がある。 8つのリポジトリがそれぞれgit-commitsのコピーを持っており、どの二つも同じではない。
• バージョンのずれ。 先週のプランニングコマンドのアップグレードは一つのリポジトリにしか反映されていない。残りはまだ古いコードで動いている。
• 連携がない。 チームメイトがデータベースマイグレーションエージェントを作ったが、彼らのバージョンが見えなかったため、あなたは自分でローリングした。
• 設定の散らかり。 スキルはほんの始まりに過ぎない。フック、settings.json、CLAUDE.mdファイル、エージェント定義、スラッシュコマンドすべてが積み重なる。プロジェクトごとに異なる組み合わせが必要になる。

ファイルをコピーするのが最初の本能だ。一瞬は速く感じ、うまくいくが、1ヶ月以内に崩れる。多くのリポジトリにまたがってエージェントを動かすすべてのエンジニアがこの話を経験している。

IndyDevDanはこれを早くに見抜き、外部リポジトリとパスへの参照をYAMLカタログに詰め込んだ純粋なエージェントベースの修正を出荷した。そのアプローチはアイデアが機能することを証明した。30以上のスキルと19のエージェントを持つ10以上のプロジェクトで実行すると、次の課題が浮かび上がった: より強固な構造。本物のファイル管理。バリアントのサポート。.claudeフォルダーの完全なカバレッジ。元が取れる同期エンジン。

ライブラリーアーキテクチャ

ライブラリーは.claude設定全体を保持するプライベートGitリポジトリだ。他のリポジトリへのポインターや参照ではない。ファイル自体だ。各スキルフォルダー、各エージェント定義、各スラッシュコマンド、各フック、各CLAUDE.md、各settings.jsonのための唯一の真実のソース。

ルートにあるmap.jsonがどのプロジェクトにどのアイテムを配布するかを決める。同期スクリプトが正しいファイルを正しい場所にコピーする。各プロジェクト内のマニフェストがライブラリーが何を所有しているかを記録し、ローカルファイルを安全に保つ。

your-library/
├── map.json                    # どのプロジェクトに何を配布するか
├── sync.mjs                    # Node.js同期エンジン
│
├── skills/                     # すべてのスキルフォルダー
│   ├── git-commits/
│   ├── agentic-builder/
│   ├── react/
│   ├── growth-kit/
│   ├── session-management/
│   └── ... (私のライブラリには31スキル)
│
├── agents/                     # すべてのエージェント.mdファイル
│   ├── frontend-specialist.md
│   ├── backend-engineer.md
│   ├── security-auditor.md
│   ├── master-orchestrator.md
│   └── ... (私のライブラリには19エージェント)
│
├── commands/                   # すべてのスラッシュコマンド
│   ├── team-plan.md
│   ├── build.md
│   ├── team-build.md
│   └── ... (私のライブラリには16コマンド)
│
├── hooks/                      # すべてのフックフォルダー
│   ├── SkillActivationHook/
│   ├── ContextRecoveryHook/
│   └── Validators/
│
├── claude-mds/                 # CLAUDE.mdのバリアント（プロジェクトごとに完全置換）
│   ├── CLAUDE--web-full.md
│   └── CLAUDE--product.md
│
├── settings/                   # settings.jsonのバリアント
│   ├── settings--web.json
│   └── settings--product.json
│
└── rules/                      # .claude/rules/ファイル
    ├── repo-primer--webapp.md
    └── repo-primer--product.md

8つのコンテンツカテゴリ（スキル、エージェント、コマンド、フック、ルール、claude-mds、設定、および任意のファイル）、すべて単一のリポジトリから管理される。同期時にエンジンはmap.jsonを開き、プロジェクトのエントリーを見つけ、そのエントリーにリストされているものだけをコピーする。余分なものはなく、不足もない。

マップ: どこに何を配布するかの制御

map.jsonが頭脳だ。すべてのプロジェクトエントリーは、そのプロジェクトが受け取るアイテムを明示する:

{
  "$schema": "library-map-v1",
  "projects": {
    "C:/Github/my-webapp": {
      "claude-md": "CLAUDE--web-full",
      "settings": "settings--web",
      "skills": [
        "git-commits",
        "react",
        "frontend-design",
        "session-management"
      ],
      "agents": ["frontend-specialist", "quality-engineer"],
      "commands": ["team-plan", "build", "team-build"],
      "hooks": ["SkillActivationHook", "Validators"],
      "rules": [],
      "files": {}
    }
  }
}

別のプロジェクトはまったく異なる組み合わせを選べる。SaaSリポジトリはbackend-engineer、supabase-specialist、security-auditorエージェントとpostgres-best-practices、authスキルを取り込む。マーケティング重視のリポジトリはそれらをgrowth-kit、seo-specialist、content-writerに交換する。プロダクトリポジトリは別のCLAUDE.mdと別のフックを持つよりスリムなセットを受け取る。ライブラリーはカタログ全体を保持し、各プロジェクトが自分のスライスを選ぶ。

プロファイルは複数のプロジェクトが共有したい設定をバンドルする:

{
  "profiles": {
    "web-default": {
      "claude-md": "CLAUDE--web-full",
      "settings": "settings--web",
      "skills": [
        "git-commits",
        "react",
        "frontend-design",
        "session-management"
      ],
      "agents": ["frontend-specialist", "quality-engineer"],
      "commands": ["team-plan", "build"],
      "hooks": ["SkillActivationHook", "Validators"]
    }
  }
}

新しいプロジェクトを立ち上げる際に--profile web-defaultを実行すれば、Webスタック全体が一つのコマンドで配置される。

バリアント: 一つのバージョンでは足りない場合

プロファイルにはギャップがある。git-commitsスキルはほとんどのリポジトリでうまく機能するが、ブログリポジトリにはMDXライティングに紐付いた追加パターンを認識するカスタムビルドが必要だ。新しいスキルとして完全に分割するのは重すぎる。実際に必要なのは、プロジェクトごとの帽子をかぶった同じスキルだ。

命名パターンはname--variantで、ベース名とバリアントタグの間にダブルダッシュを入れる:

skills/
├── git-commits/                    # ベースバージョン
│   └── SKILL.md
├── git-commits--blog/              # ブログプロジェクト用バリアント
│   ├── SKILL.md                    # 修正されたバージョン
│   └── references/
│       └── mdx-patterns.md         # このバリアントが必要な追加ファイル

map.jsonでは、参照にフルネームを使う:

{
  "skills": ["git-commits--blog", "react", "frontend-design"]
}

同期時にgit-commits--blogは.claude/skills/git-commits/に配置される。--blogサフィックスはライブラリー内にのみ存在する。プロジェクトには何も届かない。バリアントは自己完結したフォルダーだ。異なるファイル、異なる構造、異なるコンテンツ。ベースと共有するのはデプロイ名だけだ。

プッシュが成果をもたらす。ブログプロジェクト内の.claude/skills/git-commits/を編集する。プッシュ時にエンジンはマニフェストを開き、ローカルのgit-commitsがgit-commits--blogにマップされていることを発見し、編集をそのフォルダーにルーティングする。他のプロジェクトは引き続きプレーンなベースを参照する。

操作

同期エンジンは外部依存なしのNode.jsスクリプトだ。8つの操作がライフサイクル全体をカバーする:

ブートストラッピングはseedで実行する。.claudeフォルダーが既に整っているリポジトリに向けると、フォルダー全体がライブラリーに配置される。map.jsonにエントリーが追加される。マニフェストが書かれる。それ以降、正規のオーナーシップはライブラリーに存在する。

コンテンツハッシングがdiff操作を動かす。ライブラリーとプロジェクトのバージョンを比較し、各アイテムをin-sync、local-changes、library-aheadとしてタグ付けするので、同期やプッシュが実行される前にドリフトが見えるようになる。

マニフェスト: ライブラリーが所有するものの追跡

同期されたすべてのプロジェクトは.claude/.library-manifest.jsonを受け取る:

{
  "library_path": "/path/to/your-library",
  "synced_at": "2026-03-24T10:30:00Z",
  "library_commit": "abc123",
  "managed": {
    "skills": {
      "git-commits": "git-commits--blog",
      "react": "react",
      "frontend-design": "frontend-design"
    },
    "agents": {
      "frontend-specialist": "frontend-specialist"
    },
    "claude-md": "CLAUDE--web-full",
    "settings": "settings--web"
  }
}

マニフェスト内では、各デプロイ名がライブラリー名の隣に並ぶ。プッシュはそのマッピングに対して動作する。ローカルのgit-commits/フォルダーはプレーンなベースを上書きする代わりにgit-commits--blog/に流れ戻る。

マニフェストにリストされていないファイルはライブラリーのビューから完全に外れる。.claude/内の個人的なメモ、バックアップ、その場限りの実験はすべて同期をくぐり抜けても傷つかない。ライブラリーが配置したアイテムだけがライブラリーに所有される。

自然言語インターフェース

このシステムにはCLI以上のものが付属する。/libraryスラッシュコマンドが同期されたすべてのプロジェクトにデプロイされる。フラグを省いて平易な英語で尋ねる:

/library sync
/library I modified the blog command, push it back
/library add the payment-processing skill to this project
/library what's out of sync?
/library create a variant of react for this project
/library show me everything available

コマンドの向こう側で、Claude はマニフェストを開き、ライブラリーに移動し、文章から意図を引き出し、同期エンジンを起動する。破壊的な操作（削除、上書き）には最初に確認プロンプトが表示される。

これが毎日使えるインタラクションモデルだ。Claude Codeセッションはライブラリー作業のために閉じる必要がない。ニーズを声に出すだけでライブラリーが反応する。

はじめ方

独自のライブラリーを構築するには約30分かかる:

1. プライベートリポジトリを作成する。次のフォルダー構成でレイアウトする: skills/、agents/、commands/、hooks/、claude-mds/、settings/

2. 最良のプロジェクトからシードする。 今日最も充実した.claudeフォルダーを持つリポジトリを選び、その内容をライブラリーに取り込む。そのバンドルが出発点のカタログになる。

3. map.jsonを書く。 単一のプロジェクトレコードから始める。そのレコードに、プロジェクトが必要とするすべてのアイテムを明記する: 各スキル、各エージェント、各コマンド、各フック、および設定ファイル。

4. 同期スクリプトを構築する。 コアはシンプルに保つ。map.jsonをロードする。バリアントが現れる--でスプリットしてアイテム名をパースする。ファイルを目的地にコピーする。マニフェストを書く。同期前にGitからプルする。プッシュ後にコミットしてプッシュする。

5. ライブラリー自体の中に/libraryコマンドを追加する。 同期されたすべてのプロジェクトが自動的にそれを取得するので、最初から平易な英語でのコントロールが利用できる。

6. 異なる組み合わせで2番目のプロジェクトを追加する。 一つのライブラリーを共有する2つのリポジトリが成果を見せる場所だ。同じソース、異なる設定、両側でドリフトなし。

最も重要な設計上の決断: ポインターではなく、実際のファイルをリポジトリに保持する。間接参照はバリアントを余分な作業に変え、プッシュを結び目にする一層を追加する。ファイルがライブラリーの中に直接置かれていれば、同期はコピーであり、プッシュは逆方向のコピーであり、差分はハッシュチェックだ。

スケールにおいてこれが重要な理由

ライブラリーが動き始めると、習慣が変わる。参考として、この投稿で扱った稼働中のセットアップは、3つのアクティブなプロジェクトにわたって31スキル、19エージェント、16コマンド、4つのフックシステム、プロジェクト固有のCLAUDE.mdとsettings.jsonファイルをカバーしている。実際の動きはこうだ:

改善が伝播する。 コードレビューエージェントのバグ修正は一度だけ行う。次の同期以降、そのエージェントをリストするすべてのプロジェクトがパッチを引き継ぐ。修正がどのリポジトリにあるか探し回る必要はもうない。

新しいプロジェクトの立ち上げが速い。 プロファイルで新鮮なリポジトリを初期化すれば、エージェントチーム全体、フックバンドル、設定、CLAUDE.mdが数秒で配置される。設定ファイルをコピーするという最初の1時間の儀式は過去のものだ。

バリアントがフォークを防ぐ。 調整されたバージョンが必要なプロジェクトは、暗黙のうちにドリフトする代わりにバリアントを取る。ベースとバリアントはライブラリー内の明示的なリンクを通して互いに関連する。12ヶ月後も、どのプロジェクトがどのバージョンに依存しているかを追跡するのは一回のクエリで済む。

ライブラリーは自己配布する。 /libraryコマンドはライブラリー自体の中に存在する。改善すれば、次の同期でアップグレードがすべてのプロジェクトに乗って届く。配布システムは自身によって配布される。

.claudeフォルダーの配布問題は、より深いシフトのサインだ。エージェント型エンジニアリングが成熟するにつれ、.claude設定全体が本物のインフラとなる: スキル、エージェント、コマンド、フック、ルール、CLAUDE.md、設定。これらはアプリケーションコードに与えるのと同じ注意を受けるべきだ。それを実現する一つの方法: バリアント対応で双方向に流れる同期を持つ共有ライブラリー。

ライブラリーが配布できるものの先行事例として、ClaudeFast Code Kitは20以上のプロダクションスキル、18の専門化されたエージェント（frontend-specialist、backend-engineer、security-auditor、quality-engineerなど）、チームオーケストレーションシステム、5つのプロダクションフックを提供し、プロジェクト間でカタログ化して同期できる状態にある。

よくある質問

Claude Codeライブラリーシステムとは何ですか？

.claudeコンテンツのすべての部品を一か所に所有する一つのプライベートGitリポジトリだ: スキル、エージェント、コマンド、フック、CLAUDE.mdファイル、設定。map.jsonがどのアイテムをどのプロジェクトに配置するかを決める。同期エンジンが正しいファイルを正しいディレクトリにシャトルする。

これはIndyDevDanのthe-libraryとどう違いますか？

IndyDevDanのセットアップはYAMLカタログ内に参照を保持し、GitHubリポジトリやローカルパスに到達するポインターを使う。ここで扱うパターンは実際のファイルを一つのリポジトリの中に直接格納する。バリアント命名スキームがプロジェクトごとのバージョンをサポートする。マニフェストが双方向同期を可能にする。すべての.claudeコンテンツカテゴリがスコープに入る: スキル、エージェント、コマンド、フック、ルール、CLAUDE.md、設定、および任意のファイル。

ライブラリーはオープンソースである必要がありますか？

いいえ。プライベートリポジトリが適切な場所だ。ライブラリーには専門化されたスキル、プロジェクト固有のCLAUDE.mdファイル、機密性がある可能性のあるエージェント指示が含まれる。デフォルトではプライベートに保つ。後で公開したい単一のスキルは常に独自のリポジトリに抽出できる。

バリアントはどのように機能しますか？

name--variant命名パターンがコアのアイデアだ。ライブラリー内のreact--strict/という名前のフォルダーは、プロジェクト内の.claude/skills/react/に配置される。各バリアントは独自のファイルとレイアウトを持つスタンドアロンのコピーだ。マニフェストが関係を記録するので、プッシュ操作が編集を対応するバリアントに戻す。

複数の人が一つのライブラリーを共有できますか？

はい。Gitリポジトリなので、チームはそれをクローンしてプルする。スキルの改善はプッシュで戻る。すべてのチームメイトが次の同期でその修正を受け取る。map.jsonには全員のプロジェクトをカバーするエントリーをリストできる。