build-agent-broker-project

⚠️ 厳格な出力契約 — このスキルにおけるアシスタントのすべてのターンに適用

各ターンでユーザーに表示するテキストは、4 行以下でなければなりません。ただし、確認済み項目の番号付きリスト（アセット一覧、検証結果、アセット → ノードの割り当て）を出力する場合を除きます。この場合、リスト自体が出力となり、前置きは不要です。

禁止されている書き出し。 次のフレーズやその類似表現でターンを始めてはいけません。入力してしまった場合は削除してください。

• 「これから……」／「次に……」／「まず……」／「では……」
• 「最初に……」／「始めるにあたって……」／「実行する前に……」
• 「……に基づいて」／「……を踏まえて」／「……なので」
• 「すばらしいです！」／「完璧です！」／「了解しました！」／「承知しました！」／「もちろんです！」
• 「……するつもりです」／「……する予定です」／「私の方針は……です」
• 「考えてみます……」／「分析してみます……」／「確認してみます……」
• 「これから行うことは……」／「計画は……です」／「概要は……です」
• 「次に進みます……」／「……が済んだので」／「では次に……」
• これから自分が行うことを説明する文。説明せず、そのまま実行してください。

禁止されている内容。 ターンに次の内容を含めてはいけません。

• ユーザーが直前に述べた内容の言い直し。ユーザーは覚えています。
• このターンの後に続く内容の事前説明。そこに進むまで待ってください。
• 現在のフェーズの目標の言い直し。フェーズの見出しで明示されています。
• 推論の手順を逐一説明すること。ユーザーに見せるのは結論だけです。
• 散文中のフェーズ番号やステップ番号（「ステップ 4 では……」／「フェーズ 2 では……」など）。これらはモデルが手順を追うためのものであり、ユーザーには表示しません。

通常のターンで必須の形式：

<one action OR one question OR one bulleted list>
<optional: one short follow-up sentence, only if strictly needed>
<stop>

フェーズ完了の確認形式：

<bulleted list of what was captured, ≤ 6 bullets>
Anything missing?

検証結果の形式：

✅ PASS    (or)    ❌ FAIL — <N> issue(s)
- <issue 1>
- <issue 2>

フェーズで複数の操作が必要な場合は、説明を挟まずツール呼び出しで実行してください。ユーザー向けのテキストは、判断や確認が必要なタイミングでのみ出力してください。

---

MuleSoft Agent Broker Builder

複数エージェントのワークフローに関する自然言語の説明から、完全で検証済みのデプロイ可能な Agent Network V2（GA、A2A v1.0）プロジェクトを作成します。6 フェーズのガイド付きエクスペリエンスを実行し、公開とデプロイを追加します。

このスキルは、エンドツーエンドで CLI を優先します。 検証／公開／デプロイでは、Anypoint CLI Agent Fabric プラグイン（mulesoft-anypoint-cli-agent-fabric-plugin）を使用します。Exchange アセットの検索では、Anypoint CLI v4（anypoint-cli-v4 exchange asset list）を使用します。どちらも Claude Code、Cursor、Codex、Vibes で利用でき、CI/CD の経路にも対応しています。MCP ツール（mcp__mulesoft__*）は、利用可能な場合のフォールバックとして機能しますが、MCP への依存は必要ありません。

使用する場面

• 使用する場面：新しい Agent Broker の構築、ノード、エージェント、MCP ツール、LLM の追加／入れ替え、指示の調整、ルーティングの変更、検証／公開／デプロイの実行。
• 使用しない場面：V1 から V2 への変換（translate-agent-broker-old-to-new-project を使用）、単体の Mule アプリ、DataWeave、API。

YAML に schemaVersion: 1.0.0 がある場合は V1 です。処理を停止し、変換ツールに案内してください。V2 の識別子は agentNetwork: 2.0.0（引用符なし、ファイルの先頭）です。

リファレンス（必要に応じて参照）

• references/canonical-example.md — 完全に動作する Agent Network V2（GA、A2A v1.0）プロジェクト。構造のテンプレートです。迷った場合はこれをコピーしてください。
• references/gotchas.md — GA の構文規則、コンパイルエラーの規則、RULE-ASSET-MODE（インラインと Exchange）、サブエージェントとオーケストレーターの判断、認証の大文字・小文字、CLI と MCP ツールの統合、段階的な機能縮退。

MuleSoft Agent Network GA のドキュメント（Anypoint Code Builder のセクション）が正式なリファレンスです。上記のリファレンスでは、注意点と実例を説明しています。

ノードタイプの用語（フェーズの表現 ↔ スキーマキーワード）

以下の6つのフェーズでは、ノードタイプにユーザー向けの名称を使用します。実際の .agent ファイルではスキーマキーワードを使用します。ユーザーと話すときはフェーズ名を使い、ファイルを記述するときはキーワードを使ってください。

フェーズの表現	.agent キーワード	説明
Reasoning node	subagent	ツールを備えたLLMです。アクションを受け付け、HITLが組み込まれています。LLMを利用するデフォルトのノードタイプです。
Orchestrator node	orchestrator	ツールを備えたLLMで、複合的な目標に向けて複数のアクションを調整することに特化しています。ノードに2つ以上のアクションがあり、それらが連携して1つの成果につながる場合にのみ使用してください。
Generate node	generator	ツールを使わないLLMです。構造化出力による一度限りの生成／要約／分類に使用します。
（LLMなし、決定論的）	router	既知の値に基づいて分岐します。条件を使い、プロンプトは使いません。
（LLMなし、副作用あり）	executor	既知の引数で1つのツールを実行し、変数を設定します。
（終端）	echo	最終的なA2Aレスポンスをクライアントに送信します。

ツール連携（CLI優先、MCPフォールバック）

このスキルは、検証／公開／デプロイにはAnypoint CLI Agent Fabricプラグイン（mulesoft-anypoint-cli-agent-fabric-plugin）を、Exchange検索にはAnypoint CLI v4（anypoint-cli-v4）を優先します。MuleSoft MCP サーバー（mcp__mulesoft__*）はフォールバックとして使用します。

最初にCLIを試してください。CLIが失敗したら、すぐにMCPへフォールバックしてください。ユーザーに尋ねたり、CLIを再試行したり、フェーズを中断したりしないでください。

次のいずれかが発生した場合、CLIの試行は失敗とみなされます。

• command -v が何も返さない（バイナリがインストールされていない）。
• ユーザー自身の入力以外の理由でコマンドが0以外の終了コードを返す（例：ENOENT、プラグインが未インストール、認証環境変数が未設定、ネットワークエラー、npmのインストールが必要、「command not found」、EACCES）。
• コマンドが妥当なタイムアウト（検索は約60秒、ビルド／公開／デプロイは約5分）を過ぎても終了しない。
• コマンドは成功を返すが、スキーマ上コンテンツが必要なのに出力が空、または不正な形式である（例：ユーザーが明示的に指定したアセットがあるのに、返されたアセットが0件）。

次の場合、CLIの試行は失敗とはみなされません。

• ユーザーの入力に誤りがある（プロジェクト名が無効、必須フィールドが不足）場合 — ユーザーにエラーを伝え、フォールバックしないでください。
• 検証／ビルドで正当にスキーマエラーが見つかった場合 — エラーを報告してください。それがCLIの役割です。

フォールバック手順（次の順に、無言で適用してください）：

1. CLIの失敗を検知します。失敗理由を短い内部メモ1行に記録し、ユーザーから尋ねられない限り説明しないでください。
2. セッションに対応する mcp__mulesoft__* ツールが登録されているか確認します。登録されていれば、同等の入力で呼び出してください。
3. MCPも失敗するか、利用できない場合は、references/gotchas.md の「Graceful degradation」に従って、ツールを使わない方法（ドキュメントへのリンク／構造チェックリスト／ユーザーへの質問）に切り替えてください。
4. どのツールをどのように使ったかではなく、結果のみをユーザーに伝えてください（「LLMアセットを3件見つけました」／「検証済み — 問題が2件あります」／「Exchangeに接続できませんでした — assetIdを手動で教えてください」）。

CLIコマンドの実行前に追加情報が必要な場合（不明なフラグ、使い慣れないサブコマンド、曖昧な構文エラー）は、まず <command> --help を試し、解決しなければ公開ウェブ検索を行ってください。どちらでも解決しない場合に限り、ユーザーに尋ねてください。これはCLIプラグインと anypoint-cli-v4 の両方に適用されます。調査について説明せず、修正した構文でコマンドを実行してください。

全機能マトリックス、CLIコマンドの構文、環境変数による認証（ANYPOINT_CLIENT_ID/SECRET/ORG/ENV）、および手順ごとのCLI ↔ MCP対応表については、references/gotchas.md の「Tooling integration」を参照してください。

---

ワークフローA — 新しいプロジェクトの構築（フェーズ1〜6 + 公開／デプロイ）

以下の6つのフェーズで、構築の流れを構成します。各フェーズの最後には停止ポイントがあります — ユーザーを待ってください。ユーザーの回答はすぐに適用してください（一括してから更新するのではなく、回答ごとに適用します）。

ステップ 1：事前確認とスキャフォールド

1. 既存のプロジェクトを検出します。 作業フォルダーに agent-network.yaml、exchange.json、brokers/ がある場合は、「これを編集しますか、それとも兄弟フォルダーに新規作成しますか？」 と尋ねます。既定では編集します（ワークフロー B）。
2. スキーマのバージョンを検出します。 schemaVersion: 1.0.0 の場合は、コンバーターに振り分けます。
3. 意図を 1 文で確認します。 「X を実行する新しい Agent Broker を作成する、という理解で合っていますか？」
4. スキャフォールドの入力情報を収集します（CLI を呼び出す前に確認します）。
   • プロジェクト名（ケバブケース。例：it-help-investigation）— 既定の assetId にもなります。
   • 出力ディレクトリ（既定：現在の作業ディレクトリ）。
   • アセットのバージョン（開発中の既定値は 0.0.0。初回公開時にユーザーが更新できます）。
5. CLI でスキャフォールドを作成します。 親ディレクトリから作成コマンドを実行します。

   anypoint-cli-agent-fabric-plugin agent-network project create \
     --name <project-name> \
     --output-dir <parent-dir> \
     --create-dir
   

   これにより、正しい groupId／organizationId（ANYPOINT_ORG から取得）とスターターテンプレートを含む <project-name>/agent-network.yaml、exchange.json、brokers/ が生成されます。その後、スキルが生成されたファイルをその場で編集します。
   • CLI を利用できず、mcp__mulesoft__create_agent_network_project が利用可能な場合は、同じ入力情報を使って MCP ツールを呼び出します。
   • どちらも利用できない場合は、標準のスキャフォールド構造を直接書き込みます（agentNetwork: 2.0.0 を含む agent-network.yaml、"classifier": "agentic-network" を含む exchange.json、空の brokers/）。公開前に groupId／organizationId のプレースホルダーを埋める必要があることをユーザーに伝えます。
6. agent-network.yaml のネットワーク info を設定します。info.label（必須）と info.description（任意）を尋ねます。ユーザーが指定しない限り、info.version は 1.0.0 にします。すぐにスキャフォールドに適用します。

ステップ 2：機能要件（フェーズ 1）

目標： ユーザーが機能要件を明確に定義できるようにします。曖昧な回答は受け入れません。各項目が具体的になるまで質問を続けます。グラフ用語を使う必要はありません。自然言語で手順を説明してもかまいません。

次の順に収集します。

1. トリガー — どのイベントがフローを開始しますか？（ほとんどの場合、A2A の message/send です。確認してください。）
2. ワークフローの手順と分岐ロジック — 「X が起きたら、必ず Y を実行する」。各手順を順に確認します。
3. 厳格な制約 — 絶対に制限されていることは何ですか？これらはプロンプト文ではなく、ルーター条件になります。
4. 決定性と自由度 — 手順ごとに、結果を 100% 予測できる（グラフ分岐）のか、LLM による推論や判断が必要（LLM 搭載ノード）なのかを確認します。

同じ項目についてユーザーが 2 回曖昧な回答をした場合は、プレースホルダーを受け入れて、その項目に印を付け、次に進みます。

フェーズの最後に、確認を1 回だけ行います。「収集した内容はこちらです。[箇条書きの要約]。不足している点はありますか？」 ここで停止します。

ステップ 3：初期アセットの登録（フェーズ 2）

目標： Exchange で適切なアセットを見つけ、YAML に登録します。

アセットの種類：LLM（常に 1 つ以上）、MCP ツール、A2A エージェント。

アセットの検索順序 — フェーズ 1 で特定した各機能について：

1. まずプライベート Exchange を検索します。 anypoint-cli-v4 がインストールされている場合：anypoint-cli-v4 exchange asset list --search "<keywords>" --organization <orgId>。それ以外で MCP の search_asset が利用可能な場合は、assetFilters: ["llm"] / ["mcp"] / ["agent"] と exchangeScope: "Private" を指定して呼び出します。
2. プライベート Exchange で見つからない場合は、パブリック Exchange を検索します。 --organization を削除するか、exchangeScope: "Public" を設定します。
3. どちらにもない場合は、プレースホルダーを使用します。 インラインとして登録し、ユーザーが後から入力できる ${var} 形式の URL／認証プレースホルダーを設定します。

LLM の選択方法は異なります。 自動で選択しないでください。Exchange で見つかった LLM の選択肢（例：claude、openai、gemini）を一覧表示し、次のように尋ねます：「1 つ以上選択するか、新しいものを作成してください。」 その後、処理を停止します。

書き込む前にユーザーに確認します：「選択内容：[list]。よろしいですか？」 その後、処理を停止します。

確認済みのアセットをすべて agent-network.yaml と exchange.json に登録します。各アセットには 2 つのモードがあります。references/gotchas.md § "RULE-ASSET-MODE" を参照してください。

• インライン（アセットが Exchange にない）：レジストリエントリと、ref.name を含む context.connections。
• Exchange（アセットがすでに公開されている）：exchange.json.dependencies と、ref.name および ref.namespace を含む context.connections。レジストリエントリは不要です。

認証情報は常に context.connections.<id>.authentication に設定します。URL／シークレットは ${<name>.url}／${<name>.apiKey} でパラメーター化します。対応する exchange.json.metadata.variables を追加します。シークレットには "secret": true を設定します。

種類ごとのスキーマに関する注意事項：

• LLM — インライン：info.label、metadata.platform: Gemini | OpenAI | AzureOpenai。接続：kind: llm + url + authentication。
• MCP — インライン：info.label、metadata.transport.kind（streamableHttp | sse | stdio）。登録後、呼び出す tool_name をユーザーに尋ねます（アクションに必須です）。入力パラメーターが分かるかどうかも尋ねます。分かる場合は、アクションの inputs: で宣言します。分からない場合は inputs: を省略します。実行時に自動検出されます。ツール名や入力スキーマを決して捏造しないでください。
• A2A — インライン：info.label と interfaces ブランチ。現行の A2A v1.0 エージェントには a2a、旧式の A2A v0.3 には a2a_v03 を使用します（Agent Broker は後方互換性を維持します）。metadata.interfaces.<branch>.card 内に name、description、url、protocolVersion、version、capabilities、defaultInputModes、defaultOutputModes、skills を含めます。ブランチごとの形式については、references/gotchas.md § "Registry agents" を参照してください。

ステップ 4：技術グラフの定義（フェーズ 3 — エージェントスクリプト）

目標： 機能要件を .agent グラフに変換します。system.instructions と各ノードの指示は簡単な草案にとどめてください。文章の調整はフェーズ 5 で行います。

基本原則：グラフ＝事前定義されたルール。LLM ノード＝推論。 明確にハードコードできるものにはグラフを使います。真に推論が必要なタスクに限り、LLM を活用するノード（推論／オーケストレーター／生成）を使います。グラフは、上位ステージ（例：調査 → 草案作成 → レビュー）を強制する背骨として機能します。各ステージ内では、LLM を活用するノードが自律的に動作します。

グラフの初版を作成します。

1. 設定。 ユーザーの要件から agent_name を選びます（ケバブケース。.agent のファイル名のベース名とブローカー ID にも使用します。例：it-help-investigation）。
2. トリガー（エントリーポイント）。 各ブローカーで宣言できるトリガーは、インターフェースごとに 1 つだけです。kind: "a2a"、target: "brokers://<broker-id>/a2a"、on_message: は固定の transition to です。トリガー内の条件分岐はコンパイルエラーになります。後続にルーターを使ってください。
3. LLM を活用するノード（ステージごとに適切な型を選びます）：
   • 推論ノード（subagent キーワード）— ツールを使用する LLM です。LLM を活用する型のデフォルトです。HITL を組み込みで備えています。
   • オーケストレーターノード（orchestrator キーワード）— 複合目標に向けて複数のアクションを調整することに特化した、ツールを使用する LLM です。
   • 生成ノード（generator キーワード）— ツールを使用しない LLM です。構造化出力を伴う一回限りの生成、要約、または分類に使用します。
4. データ構造（変数）。 ノード間で共有する状態を宣言します。
5. 決定論的な接続。 終端以外の各ノードには、単一の on_exit: -> transition to @<nodeType>.<nodeId> が必要です。到達可能なすべてのパスは echo で終了します。
6. 条件分岐はルーターノードに記述します。ルーターは routes: と otherwise: を宣言し、on_exit は持ちません（ルーターの on_exit 内の transition to はコンパイルエラーになります）。フェーズ 1 のハード制約は、プロンプトではなくルーター条件にします。プロンプトは無視されることがありますが、ルーター条件は無視されません。
7. トリガーの直後にある最初のノードを、@request.payload.message をコピーするだけのパススルー実行ノードにしないでください。 後続では @request.payload.message.parts[0].text を直接参照します。
8. Echo で終端。 到達可能なすべてのパスは、kind: "a2a:status_update_event"（アーティファクトの場合は kind: "a2a:artifact_update_event"）を持つ echo で終了します。TASK_STATE_* 列挙型と a2a.* ヘルパーのルールについては、references/gotchas.md の「Echo node」を参照してください。

system.instructions と、LLM を活用する各ノードのプロンプトの初版を作成します。簡潔にまとめてください。調整はフェーズ 5 で行います。

agent-network.yaml の brokers エントリーを更新し、新しい .agent ファイルを参照するようにします。コンパイルエラーのルール全般については、references/gotchas.md の「Compile-error rules」を参照してください。構造テンプレートについては、references/canonical-example.md を参照してください。

ステップ 5：アセットをグラフに割り当てる（フェーズ 4）

目標： YAML のアセットを、適切な LLM 駆動ノードに割り当てます。

指針：

• 各 LLM 駆動ノードは、1 つのドメインに特化させます。 類似するアセットは分散させず、同じノードにまとめます。
• Reasoning と Orchestrator の選択 — 接続されているアセットに応じて選びます。
  • ノードにあるのが MCP アセットのみ → Reasoning ノード（subagent）。
  • ノードに A2A アセットが 1 つでもある → Orchestrator ノード（orchestrator）。
• LLM 駆動ノードあたりのアセット数は合計 4 個以下（A2A と MCP の合計）にします。それを超えると、幻覚が発生します。ノードを分割してください。
• 最小権限の原則。 あるノードには読み取り専用ツールを、別のノードには書き込み権限のあるツールを割り当てます。決して併用しないでください。
• 不可逆な変更（エスカレーション、削除、顧客への送信など）は、router で制御される executor ノードに必ず配置します。 Reasoning／Orchestrator ノードには決して配置しないでください。LLM が router を迂回して実行する可能性があります。冪等な更新（ステータス更新、チケット更新）は、複合的な目標の一部であれば Orchestrator に配置してもかまいません。

操作：

1. グラフ、YAML、ノードごとの指示を再度読み、コンテキストを確認します。
2. 各 Reasoning／Orchestrator ノードについて、アセットを割り当てます。「このノードに必要な YAML アセットはどれですか？」利用可能なアセットがない場合は、ユーザーに作成を依頼します。
3. .agent ファイルでバインドします。各アセットには actions: エントリを設定します（A2A：target と kind のみ。inputs: は不要。MCP：target、kind、tool_name、任意の inputs:）。reasoning.actions（Reasoning／Orchestrator ノード）または do: run（Executor ノード）から参照します。
4. すべてのノードへの割り当てが完了したら、ユーザーに確認します。「アセット → ノードの割り当ては次のとおりです：[list]。確認してください。」その後、停止します。
5. 各 LLM 駆動ノードで使用する LLM をユーザーに選んでもらいます（ノードごとに異なる LLM を使用できます。分類には安価なもの、オーケストレーションには高性能なものを選べます）。
6. 各 Reasoning／Orchestrator ノードの役割を、人が読んで理解できる 1 行の説明にまとめます。これをノードに保存します。

バインドの全ルールについては、references/gotchas.md を参照してください。

• §「コンパイルエラーのルール — アクション呼び出し」 — Executor での A2A の単独参照と with message = の使い分け、MCP の with のルール、http_headers の暗黙的な扱い。
• §「ステージ 4：ノードへのバインド」 — アセット数の上限 4 個、最小権限、アクションのエイリアスの命名。

ステップ 6：指示の調整（フェーズ 5）

目標： すべての LLM 駆動ノードの指示を調整し、実践的に検証します。一度に 1 つのノードだけを扱い、まとめて行わないでください。

各 generate／Reasoning／Orchestrator ノードについて、次の手順を行います。

1. ノード名を一度だけ伝えます。「classifySeverity を調整します。」（やり取りのたびに作業中のノードを繰り返さないでください。ユーザーは覚えています。）
2. system.instructions の V1 を表示します（フェーズ 3 で作成した簡潔な草案）。
3. 一度だけ尋ねます。「全体的なフィードバックはありますか？ 成功基準や few-shot の例はありますか？」その後、停止します。
4. V2 を番号付きの手順として作成します。各ステップは、1 回のツール呼び出しか 1 つの出力判断に対応させます。「役に立つ」「プロフェッショナルに振る舞う」といった指示は避けてください。
5. 出力を具体的にします。 ノードに outputs.properties.severity.enum がある場合、プロンプトには enum のリテラルを正確に使って、「X の場合は severity を high に、それ以外は low に設定してください」と記述する必要があります。
6. エッジケースを想定します。 重要なフィールドが欠けていた場合にどうするかを、あらかじめ指示に含めます。
7. ノードごとの矛盾を検証します。 V2 の手順が、決定論的なグラフのロジックによって無効になっていないか確認します。矛盾があれば解消します。
8. V2 をすぐにファイルへ適用します。次のノードに進みます。

すべてのノードの調整が完了したら： ノード間の矛盾を検証します。プロンプト内の手順が、別のノードのプロンプトやグラフと矛盾していないか確認します。矛盾があればユーザーに示して解決します。

ステップ 7：最終トポロジーレビュー（フェーズ 6）

クリーンアップしてから、検証します。

クリーンアップ：

1. 未解決の {{...}} マーカーと、未使用の exchange.json 変数を削除します。
2. 未使用の registry アセットを削除します（context.connections、アクション、または LLM ブロックから参照されていないもの）。
3. 未使用の context.connections エントリーを削除します。
4. .agent ファイル内の孤立したアクション定義を削除します。
5. 空の YAML キーを削除します（エントリーのない registry.llms: → キーを削除）。

検証します。 ビルドコマンドを実行します（CLI を優先 → MCP を代替手段として使用 → 下記の構造チェックリストとインストール案内）。コマンドの完全な構文は references/gotchas.md §「ステップ 7 — 検証／ビルド」を参照してください。

構造チェックリスト：

• すべてのノードはトリガーから到達可能ですか？孤立したノードはありませんか？
• 到達可能なすべてのパスは echo で終了しますか？
• すべての router に routes（1 つ以上）と otherwise がありますか？
• すべての subagent／orchestrator に reasoning.instructions と、1 つ以上のアクションまたは HITL がありますか？
• ノードで参照されているすべてのアクションは、actions: のエントリーと一致していますか？
• すべての ${...} 変数に、一致する exchange.json.metadata.variables エントリーがありますか？
• すべての context.connections.<id>.ref.name は、レジストリーエントリーまたは exchange.json.dependencies に解決されますか？
• reasoning.actions 内のすべての A2A アクションは、単独の参照になっていますか（with message = を含まない）？
• MCP の with パラメーターはすべて、宣言済みの inputs: フィールドを参照していますか？
• すべての echo の state 値は、許可された列挙値に含まれていますか？
• ハード制約はプロンプトではなく、ルーターの条件によって適用されていますか？
• 運用上限は設定されていますか。max_number_of_loops はデフォルトの 25 より低く設定されていますか（例：分類では 3、オーケストレーションでは 5～10）。低速な下流エージェントを呼び出す場合、task_timeout_secs は設定されていますか？

修正ループ：

• エラーをファイルごとにまとめます。書式、インデント、必須キーの欠落を自動修正します。スキーマで必須となる参照先が不足している場合は、ユーザーに確認します — 不足しているアセットを自動で追加してはいけません。問題がなくなるまで繰り返します。

問題がなくなったら、次のように伝えます："プロジェクトの検証が完了し、準備ができました。Exchange に公開してランタイムにデプロイしますか？"

ステップ 8：公開（任意）

ユーザーが希望する場合にのみ実行します。前提条件：CLI／MCP コンテキストで認証済みであること、exchange.json に assetVersion があり、secret: true の変数に空の default: "" がないこと。

公開コマンドを実行します（CLI を優先 → MCP を代替手段として使用 → ドキュメントへのリンク）。出力に含まれる公開済みアセットの URL を提示します。コマンドの完全な構文は references/gotchas.md §「ステップ 8 — 公開」を参照してください。

ステップ 9：デプロイ（任意）

ユーザーが希望する場合にのみ実行します。先に公開を完了している必要があります。

ユーザーに environmentName、targetSpace（プライベートスペース）、および環境固有のシークレットに関するデプロイプロパティを確認します（例：--property openai.apiKey:STAGING_API_KEY）。

プライベートスペースごとに一度だけ行う設定： 対象のスペースにゲートウェイがまだない場合は、先にゲートウェイ設定コマンドを実行します。

デプロイコマンドを実行します（CLI を優先 → MCP を代替手段として使用 → ドキュメントへのリンク）。デプロイ URL／ID を提示します。コマンドの完全な構文、ゲートウェイのデフォルト値、および CI フラグは references/gotchas.md §「ステップ 9 — デプロイ」を参照してください。

---

ワークフロー B — 既存プロジェクトの編集

編集時の基本原則：

• まず影響を分析します。 変更に依存するすべての下流ノード、式、または接続を特定します。ユーザーに確認します。
• 変更は最小限にします。 依頼された箇所だけを編集します。例外：アクションの追加／削除に伴うノードタイプの変更（subagent ↔ orchestrator）。
• まずレジストリーに登録します。 新しいアセットは、.agent から参照する前に agent-network.yaml のレジストリー／コンテキスト（または exchange.json.dependencies）に追加します。
• 編集中の検証は後回しにします。 編集途中での lint エラーは想定内です。最後に検証します。

B.1 — アセットを追加または入れ替える

1. モードを決めます（Inline または Exchange — gotchas.md を参照）。
2. Inline： registry.{agents,mcps,llms} ＋ 認証情報を含む context.connections.<id> ＋ exchange.json.metadata.variables。Exchange： exchange.json.dependencies ＋ ref.name と ref.namespace を含む context.connections.<id>。
3. .agent ファイルに actions: エントリを追加します。
4. 対象ノードの reasoning.actions（サブエージェント／オーケストレーター）または do: run（エグゼキューター）から参照します。
5. アクション数が変わった場合は、ノードタイプを再評価します。 アクションが 1 つの場合 → subagent。複数の場合 → orchestrator。下流にある @<oldType>.<id> 参照を更新します。
6. 上限を確認します。 ノードのアクション数が 4 を超えた場合は、分割を提案します。
7. 新しいアセットの使い方を説明するため、system.instructions を更新します。
8. ステップ 7 を実行します（検証）。

B.2 — グラフのロジックを変更する

.agent を編集します。変更後は、トリガーからすべてのエコーまでたどり、次の点を確認します。

• すべてのルーターの when: が、実在し到達可能な上流の出力を参照していること（@request.payload を直接参照していないこと）。
• ハード制約がプロンプトではなく、引き続きルーター条件に記述されていること。
• 到達不能なノードや行き止まりのノードがないこと。
• ルーターの on_exit に transition to がないこと（コンパイルエラーになります）。

ステップ 7 を実行します。

B.3 — 指示を改善する

.agent のみを編集します。フェーズ 5 の矛盾テストを適用します。ユーザーがポリシードキュメントを貼り付けた場合は、そのまま貼り付けず、番号付きの手順に変換します。ステップ 7 を実行します。

B.4 — 接続ポリシーを追加または変更する

agent-network.yaml を編集します。GA スキーマはポリシーをサポートしていますが、ビルドフローにはその設定項目がありません。

ポリシーには2 つの部分があります。

1. 定義 — context.policies.<policyId>。
2. バインド — context.connections.<connId>.policies.outbound または brokers.<brokerId>.interfaces.a2a.policies.{inbound,outbound} から参照します。必ず ID で参照してください。

Exchange で公開されるポリシーの場合：先に exchange.json.dependencies に追加してから、バインドします。ステップ 7 を実行します。