RinDig/icm-architect

解決する問題

マルチエージェント設定では、ステップ、コンテキスト、状態を定義するためにオーケストレーションコードに依存することが多く、理解やデバッグが困難になります。icm-architect は、そのコードを単純なフォルダ構造に置き換えます。番号付きフォルダが順序を設定し、階層がエージェントが見るコンテキストを制限し、マークダウンファイルが状態を保持します。誰でも任意のフォルダを開いてシステムが何をしているか確認でき、適切なタイミングで適切なファイルを読む1つのエージェントがマルチエージェントフレームワークの仕事を実行できます。

仕組み

2つのモードで動作します。ビルドは、作業の説明に暗黙的に含まれる構造（段階、チェック、安定部分と実行ごとの部分）を抽出し、その構造を運ぶ最小のワークスペースを作成します。再構築は、既存のフォルダを監査し、各ファイルをタイプ（カタログ、契約、工場、製品、廃止）に分類し、依存関係を見つけ、承認用の移行マップを提案し、移行して検証します。

すべてのワークスペースは3つのプリミティブから構築されます：シーケンス（番号付きステップ、各出力が次に供給）、シェルフ（同じ形状のファイルのフォルダ）、カタログ（下を指す小さなファイル）。これらは5つの形式に組み合わされます：パイプライン、レコードライブラリ、ナレッジバンドル（トランスクリプトから構築され、すべての引用がソースに対して検証されるものを含む）、コンテキストマップ、システムマップ。形式はネストできます。

各ステップはチェック（人、スクリプト、または小さなモデル）で終了し、エラーが増幅される前に捕捉されます。最終検証はウォークテストです：メモリのないエージェントがファイルだけで方向付け、行動し、ステータスを報告できなければなりません。ワークスペースはプレーンなフォルダとマークダウンで、AGENTS.md をエントリファイルとし、異なるファイル名を期待するエージェントには1行のポインタが追加されます。

対象読者

オーケストレーションコードに代わる、よりシンプルで透明性の高い代替手段を求める、エージェント駆動のツールやワークフローを構築する人々。SKILL.md ファイルを読み取る任意のエージェント（Codex、Gemini CLI、Hermes Agent、Claude Code、Cursor、GitHub Copilot を含む）で動作します。また、チームが既存のリポジトリやボールトをエージェントフレンドリーで解釈可能なレイアウトに再構築するのにも役立ちます。

ハイライト

• 2つのモード：説明からワークスペースを構築するか、監査と移行で既存のフォルダを再構築します。
• 3つのプリミティブとネスト可能な5つの再利用可能な形式に基づき、小さなワークスペースを最小限に保ちます。
• 各ステップはチェックで終了し、完成したワークスペースは「ウォークテスト」を通過して、新しいエージェントがナビゲートできることを保証します。
• ベンダー中立：プレーンなフォルダとマークダウンで AGENTS.md を使用し、他の名前を期待するエージェントにはポインタを提供します。
• オプションの Python スクリプトがリンクと入力パスをチェックし、ワークスペースグラフを描画し、インデックスを生成し、引用をソースに対して検証します。