複数の独立 Git リポジトリを1ディレクトリに束ねて運用するワークスペースでは、ルート直下の設定資産（AI エージェント設定・スキル・エディタ設定・自動化シナリオ・worktree 設定など）がどのリポジトリにも属さず、マシン移行や消失時に復元できない。ルート自体を private のメタリポジトリにすると、日常運用に干渉せずこれを解決できる。

構成

• サブリポジトリのディレクトリと生成物（依存ディレクトリ・キャッシュ・出力物）を gitignore で除外し、設定資産だけを追跡する。
• ignore された入れ子の Git リポジトリは gitlink（submodule 的エントリ）にならず、メタ側の git はその存在自体を見ない。gitlink が生まれるのは ignore されていない入れ子リポジトリを明示的に add したときだけなので、サブリポジトリ内での日常の git 操作とは完全に独立する。
• サブリポジトリ復元用に、未 clone のものだけ clone する小さな bootstrap スクリプトを同梱する。移行は「メタリポジトリを clone → bootstrap 実行」の2手になる。
• symlink は Git がリンクのまま追跡するため、エージェント間で設定ディレクトリを共有する symlink もメタリポジトリごと移行できる。

判断基準（却下した代替案）

• git submodule 化: clone 一発で全部揃う利点はあるが、サブリポジトリで commit するたびメタ側にポインタ差分が出続ける。毎日触るワークスペースでは運用ノイズが利便を上回る。稀にしか更新しない読み取り中心の集約には向く。
• ghq / myrepos 等のマニフェスト管理のみ: リポジトリ群の復元はできるが、肝心のワークスペース直下の設定ファイル自体は管理外のまま残り、結局メタリポジトリが必要になる。

注意（秘密の線引き)

ワークスペース設定には MCP 接続定義やローカル設定など秘密が混ざりやすい。push 前に追跡対象全体を秘密らしい文字列で走査し、「ローカル開発の既定値のみ許容、実秘密は置かない」という線引きを先に決めておく。

検証

メタリポジトリの status 表示にサブリポジトリが一切現れないこと、bootstrap スクリプトが clone 済み環境では冪等に skip すること、追跡ファイルの秘密走査で実秘密が出ないことを確認する。