mcpField
A
agent-config

agent-config

github.com/light-chengエージェントワークフロー522 回インストール4 日前に更新
リポジトリ

agent-config について

agent-config は、検証済みのホスト機能とユーザー確認済みのプロファイルに基づき、コーディングエージェント作業の実行構成、モデル階層、労力を計画します。複数の指定ハーネスにネイティブ対応し、その他には汎用フォールバックを使います。

主な機能

  1. 01実行構成とモデルのルーティング
  2. 02ホスト機能の確認
  3. 03タスク形状と難易度の評価
  4. 04セットアップとプロファイル設定
  5. 05承認後のホスト設定変更

活用シーン

  1. 01複雑なマルチエージェント作業の計画
  2. 02ホストのモデルと階層の設定
  3. 03難易度に応じたタスクのルーティング

MCP 対応

任意のコンパニオンMCPは、セットアップ状態、確認済みプロファイルの証拠、設定ツールを提供します。利用できない場合は、セッション入力または計画のみの運用が可能です。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/light-cheng/skills --skill agent-config

インストール後、Claude Code で/agent-configを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
companion-contract.md
examples.md
harness-support.md
host-evidence-schema.md
plan-schema.md
profile-schema.md
provider-adapter-contract.md
routing.md
setup.md
task-assessment.md
scripts/
__init__.py
abstract_profiler.py
agent_config_models.py
agent_config.py
candidate_selector.py
decision_source.py
harness_adapter.py
tests/fixtures/
adapter-scenarios.json
case-a-tiered-single-pass.json
case-b-tiered-decomposed.json
case-c-fixed-single-pass.json
case-d-fixed-decomposed.json
execution-config-case-a.json
execution-config-case-b.json
execution-config-case-c.json
execution-config-case-d.json
false-inventory.json
missing-model-evidence.json
missing-reasoning-control.json

詳細

エージェント設定

agent-config は、検証済みの Agent Host の機能とユーザーが確認したプロファイル階層を対応付け、適切な規模の実行トポロジー、モデル、作業量を決定します。主要なコーディングエージェントのハーネス（Codex、Claude Code、Antigravity、DSH、OpenCode、ZCode、Cursor、Grok Build、Hermes、Pi）をネイティブでサポートし、それ以外には安全な汎用／手動のフォールバックを提供します。必須のコンパニオン機能、外部スキル、外部サービス要件はありません。

使用するタイミング

  • トポロジー、モデル階層、作業量が重要となる複雑なマルチエージェント作業や分割作業の前。
  • 明示的なセットアップの意図（agent-config setup）により、ホストのモデルと階層を設定または再設定するとき。
  • light-implement または ask-light によって呼び出されたとき、または提示されたとき。

入力

  • 範囲が限定されたタスク、SPEC、またはチケットのグラフ。
  • 根拠のあるホスト機能と確認済みプロファイル（コンパニオン MCP またはセッション入力経由）。

スクリプトのエントリーポイント scripts/agent_config.py は、正規の Host および Profile の根拠を受け取ります。根拠が不足している場合、古い場合、または一致しない場合は NEED_INPUT を返します。フラグとルールについては、host-evidence-schema.md を参照してください。

セットアップゲート

  • 明示的なセットアップ： セットアップの意図（agent-config setup）で呼び出された場合は、ランタイム環境と Profile を準備または修復するためにセットアップモードを実行します（references/setup.md を参照）。セットアップで現在のタスクの実行計画を立てることはありません。
  • 通常の呼び出し： 現在の作業の実行トポロジーとルーティングを計画するのは agent-config モードのみです。コンパニオンの get_setup_status でセットアップ状態を確認してください。健全性ルールについては companion-contract.md を参照してください。コンパニオンが見つからない場合や古い場合は、セットアップを提案するか、計画のみで続行します。Profile がない場合や古い場合は、セットアップを提案するか、安全に可能な範囲でセッション内のみで続行します。セットアップを黙って開始したり、MCP ツールを自動インストールしたり、ホストのファイルを変更したりしないでください。

出力契約：AgentConfigResult

agent-config は正規の AgentConfigResult エンベロープを返します。

  • readiness：READY | NEED_INPUT | NEED_PROJECT_TICKETS | BLOCKED | UNSUPPORTED（実行準備状況の正式な値。重複するステータスは削除されています）。
  • mode：persisted | session-local | plan-only
  • setup_state：companion（ready | missing | stale）、profile（persisted | session-local | missing）。
  • handoff："project-tickets" | "setup" | "light-implement" | null
  • execution_config：ExecutionConfig | null（readiness === "READY" の場合に限り必ず存在し、準備が整っていないすべての状態では必ず null）。

コアフロー

  1. セットアップの確認： 正常なコンパニオンまたはセッション入力を通じて、確認済みのプロファイルを検証します。プロファイルなしに単一モデルだと推測してはいけません。
  2. ホストの確認： 有効なモデル、サポートされている推論強度の値、同時実行数の上限を読み取ります。
  3. タスクの形状の判定： single-pass または decomposed に分類します（単語数で判定してはいけません）。
  4. 分解のゲート： decomposed で、正式なチケットが存在しない場合は、readiness: NEED_PROJECT_TICKETS、handoff: "project-tickets"、execution_config: null を出力し、チケット化の推奨を呼び出し元に返します。
  5. 難易度とティア： マルチモデルの場合、作業の難易度（routine..critical）を、ユーザーが確認したプロファイルのティア（routine、standard、high、review）に対応付けます。難易度または推論の必要性が明示されていない場合、スクリプトは型付きの判断ソースに尋ねることがあります（「オプション機能」を参照）。
  6. 推論強度の解決： 抽象ポリシー（例：highest-supported）は、検証済みでホストがサポートする文字列（例：high）に厳密に解決し、検証されていないリテラルの max は決して出力しません。
  7. 実行モードの選択：
    • ケース A（固定単一モデル＋シングルパス）： メインセッションで直接実行し、単一モデル、解決済みの推論強度を使用します。偽の役割は設けません。
    • ケース B（固定単一モデル＋分解、P0）： コントローラーのメインセッションが、新しいワーカーコンテキストを調整し、同じモデルと実際の推論強度を使用します。
    • ケース C（ティア別マルチモデル＋シングルパス）： タスクの難易度に基づいて、ユーザーが設定したティアを割り当て、最小限のトポロジーを使用します。
    • ケース D（ティア別マルチモデル＋分解、P0）： チケットの難易度をユーザープロファイルのティアに対応付け、解決済みの推論強度を使用し、コントローラーが統合します。
  8. 計画の出力と適用： references/plan-schema.md および AgentConfigResult に準拠した計画を出力します。ホスト設定を変更するには、プレビューの承認が必要です（preview_configuration → ユーザーの承認 → apply_configuration → validate_configuration）。

不変条件

  • 知能を推測しない： 名前やメタデータからモデルの能力を推測してはいけません。モデルのティアは、ユーザーが確認したものに厳密に従います。
  • 単一モデルを第一級の選択肢とする： 単一モデルは、機能が劣る場合の代替策ではなく、対等なトポロジーです。ケース B とケース D は、どちらも P0 のパスです。
  • 無断で変更しない： 明示的な同意なしに、パッケージのインストール、バックグラウンドデーモンの起動、ホストファイルの編集を自動で行いません。
  • 単語数に基づく判定をしない： タスクの形状は、文章の長さではなく、意味上の複雑さと依存関係によって決まります。

引き継ぎ

  • AgentConfigResult を呼び出し元に返します。handoff は推奨事項を示すもので、別の Skill を開始する許可ではありません。
  • すでに有効な light-implement の呼び出し元は、readiness === "READY" の場合、許可済みの範囲内の項目を再開できます。
  • 単独で呼び出された場合、準備完了時は明示的な $light-implement を、チケットが必要な場合は $project-tickets を推奨し、その後は停止します。ユーザーが呼び出したどちらかの段階を開始するには、その対象への明示的なユーザー承認と、検証済みのホスト遷移サポートが必要です。これらがない場合は、該当する呼び出し方法をそのまま表示します。
  • コードレビューは review-loop を通じて収束させ、最終承認は project-review が行います。

オプション機能

  • 複雑さや推論の必要性が明示されていない場合 → タスクプロファイラーは light-decide スクリプトのパスを通じて質問します。スクリプトを使わずに判断する場合は、質問 ID agent-config/task-complexity または agent-config/reasoning-need を指定して light-decide を呼び出します。質問はプロジェクトの Decision data: の上限内（行がない場合はデバイス上で実行）に限られ、ユーザーのポリシーファイルで該当する質問が調整されている場合にのみ回答が適用されます。また、スコアが下位の区分に明確に収まる場合にのみ、ダウングレードが適用されます。利用できない場合、または調整されていない場合は、決定論的なプロファイルを維持します。判断によってプロファイルが確認されたり、ホスト設定が変更されたりすることはありません。

参考資料

コメント

Markdown 対応