実際のプロジェクトでは、コードが単一のリポジトリに収まることは稀です。フロントエンド、バックエンド、ドキュメント、共有ライブラリは異なるリポジトリに分散しており、一つの機能変更で複数のリポジトリを同時に触る必要が生じることもあります。Kiro にとってシングルリポジトリモードは機能しますが、リポジトリ間の関係を本来は理解しておらず、毎回の会話で「この変更はあと 2 つのリポジトリにも同期が必要」と手動で伝えなければならず、明らかに非効率です。
HagiCode の Monospecs 機構は、マルチリポジトリシナリオのために設計された構造化されたソリューションです。.hagicode/monospecs.yaml 設定ファイルを通じて、プロジェクト群のすべてのサブリポジトリのアドレス、名前、関係を宣言し、提案を起動する際に Kiro に自動的にリポジトリ間の地図を提供します:
Monospecs は実質的に、リポジトリをまたぐ協業における Kiro の認知の死角を取り除きます。Kiro の推論は強力ですが、変更範囲を特定するには正確な地図が依然として必要であり、Monospecs はその体系的に管理されたプロジェクトの地図です。
- 自動的なリポジトリ関係の認識:開発提案を作成する際、Kiro は Monospecs 設定からサブリポジトリ一覧を直接読み取れます。「この変更のフロントエンドコードは repos/frontend、API 定義は repos/backend、ドキュメントは repos/docs」と把握し、毎回どのリポジトリが関わるかを手動で列挙する必要はなくなります。
- リポジトリ間の変更追跡:提案が複数のサブリポジトリにまたがる場合、OpenSpec の提案ディレクトリはメインリポジトリに置かれ、サブリポジトリはコードの変更だけを担います。これにより仕様とコードが分離され、サブリポジトリはクリーンに保たれますが、変更全体の意思決定チェーンと議論の記録は一カ所に集約されます。アーカイブ時には commit_when_archive が仕様をメインリポジトリに自動コミットすることもでき、手動のバージョン管理の手間を省けます。
- AI コミットの賢い送り先判定:AI コミットの際、HagiCode は変更内容を Monospecs 設定と照らして、コミットの送り先リポジトリを自動的に提案します。ターミナルで各ディレクトリに cd する必要はなく、HagiCode がこのコードがどのリポジトリに属するかを判断します。
- リポジトリごとの AGENTS.md:各サブリポジトリは独自の AGENTS.md を持ち、そのリポジトリの技術スタック、コーディング規約、開発の慣習を Kiro に伝えられます。Kiro は異なるリポジトリを操作する際に対応するガイダンスを自動的に読み込み、常にチームの基準に沿って行動します。