fusion-setup

Fusion のセットアップ

このスキルは、~/.config/opencode/（Windows の場合：%USERPROFILE%\.config\opencode\）にユーザーのグローバルな opencode 設定を書き込み、Fusion エージェントチーム（メインエージェント、サイドキック実行役、探索担当、任意の専門エージェント）を構成します。リポジトリをクローンする必要はありません。

XDG_CONFIG_HOME が設定され、空でない場合、opencode はそのディレクトリを $XDG_CONFIG_HOME/opencode/ として解決します。そうでない場合は、~/.config/opencode/ にフォールバックします。以下の ~/.config/opencode/... というパスは、いずれも解決されたディレクトリを指します。Step 4 に含まれるインストーラーがこれを自動的に判定するため、通常の手順では特別な対応は不要です。手動での代替手順である Step 4b と、Step 5 での検証のみ、手動で解決する必要があります。XDG_CONFIG_HOME が異なるマシンで ~/.config/opencode/ にインストールすると、opencode が読み込まないディレクトリツリーが書き込まれます。インストールは成功したように見えても、Fusion は読み込まれないままです。

Fusion とは

Fusion は、権限に差をつけて作業をエージェント間で分担します。

• build（メイン、プライマリ）：計画を立て、判断を下し、レビューを行う強力なモデルです。ファイルの編集、コードベースの検索、任意のシェルコマンドの実行はできません。ファイルを変更する唯一の手段は、task ツールを介してサイドキックに委任することです。
• plan（プライマリ）：計画モードです。build と同じ計画立案能力を備えています。レビュー済みの計画を作成し、探索を委任しますが、実行はしません。計画を実行するには build に切り替えます。opencode 組み込みの plan エージェントを上書きし、計画モードでも Fusion に対応できるようにします。
• sidekick（サブエージェント）：より低コストで高速なモデルで、完全な edit と幅広い bash アクセスを備えています（多層防御のため、直接の git commit／git push や一般的なラッパーコマンドは禁止されており、コミットはメインエージェントが行います）。メインエージェントから渡された明確な仕様に従って実行します。
• explore（サブエージェント）：読み取り専用のコードベース探索に使う低コストモデルです。
• research（サブエージェント）：ウェブ検索やドキュメントを使った、外部情報の読み取り専用調査を行います。編集アクセスはありません。
• design（サブエージェント）：フロントエンド／UI の実装を担当します。デザインスキルを読み込み、ファイルを編集し、開発／ビルドツールを実行します。
• reviewer（サブエージェント）：実装前に計画を批評し、コミット前に差分を監査します（正確性、範囲、セキュリティ）。読み取り専用で、リンターとテストのみ実行できます。編集アクセスはありません。
• vision（サブエージェント）：メインモデルが認識できない画像やスクリーンショットを読み取り、テキストで報告します。メインモデルに画像入力機能がない場合にのみ必要です。

リポジトリを役割のカタログとして考えてください。コア（build／plan／sidekick／explore）は必須で、残りはワークフローに応じてインストールする任意の要素です。research／design／reviewer／vision の専門エージェントは任意です。各役割のモデルは個別に選べます。これは Fusion を使う大きな理由の一つです。たとえば、お気に入りのデザインモデルを design に、別のレビューモデルを reviewer に設定できます。

この権限の非対称性は、慣習ではなく権限レイヤーによって強制されます。Fusion を機能させるには、Step 4 でインストールする同梱エージェントファイルの権限フロントマターを正確に保持する必要があります。

ステップ 0 - サブスクリプションプロファイルを提示する

ロールごとのヒアリングに入る前に、ユーザーが使用しているモデルが次のいずれかのサブスクリプションによるものか尋ねます。それぞれ、ロールごとの妥当なデフォルト設定を備えた、<this-skill-dir>/profiles/ 内の既成の設定フラグメントに対応します。

プロファイル	サブスクリプション
opencode-go	OpenCode Go（OpenCode Zen の低価格なオープンモデルプラン）
opencode-zen	OpenCode Zen の従量課金クレジット
opencode-zen-free	OpenCode Zen の無料プランのモデルのみ
chatgpt	ChatGPT Plus または Pro
github-copilot	GitHub Copilot

ユーザーがいずれかを指定した場合（/fusion-setup の引数として指定した場合も含む）：

1. <this-skill-dir>/profiles/<name>.json を読み込み、確認用にそのロール -> モデルの表を提示します。JSON が唯一の信頼できる情報源です。このドキュメントや記憶をもとにモデル ID を引用してはいけません。

2. 認証は別途行う必要があることを伝えます。サブスクリプションのログイン情報またはキーを使って、opencode auth login（または opencode 内の /connect）でプロバイダーを一度接続する必要があります。チャットでキーを尋ねてはいけません。プロファイルのプロバイダーブロックには、意図的に npm アダプター、baseURL、apiKey が含まれていません。opencode はこれらのプロバイダーにネイティブ対応しており、ブロックには表示名のみが含まれます。

3. ステップ 1～3 を省略し、プロファイルを指定してインストーラーを実行します（ステップ 4 の委任ルールは引き続き適用されます）。

   node <this-skill-dir>/scripts/install.js apply --profile <name> --extras commands,plugin
   

   --roles フラグは不要です。インストーラーはプロファイルからロール一覧を導き出すため、プロファイルでモデルが割り当てられた各ロールに、権限を持つエージェントファイルも作成されます。

4. 1 つか 2 つの選択を変更するには、--profile <name> はそのままにし、差分だけを記述した --config <fragment.json> を追加します（たとえば、異なる agent.reviewer.model を指定し、そのモデルのプロバイダーがプロファイルに含まれていない場合に限りプロバイダーブロックも指定します）。フラグメントの設定がプロファイルより優先されます。プロファイルで割り当てられた任意ロールをオーバーライドで削除することはできません。その場合は、代わりにカスタムヒアリング（ステップ 1～4）を --profile を付けずに行います。

該当する場合は、次の注意点も伝えてください。opencode-zen-free には vision ロールが含まれます。これは、メインモデルが画像を読み取れないためです。一方、他のプロファイルは画像を直接読み取れるモデルを優先します。opencode-zen-free は、プロンプトが OpenCode のポリシーに基づいてトレーニングに使用される可能性のある無料期間中のモデルで動作するため、機密コードを使わないようユーザーに注意してください。単一ベンダーの chatgpt プロファイルでは、すべてのロールが 1 つのベンダーに統一されます。そのため、レビュー担当モデルにはベンダー違いではなくモデル違いとして GPT-5.6 Terra が割り当てられます。2 つ目のプロバイダーがあるユーザーは、真のクロスベンダーレビューを実現するため、レビュー担当を上書きするとよいでしょう。github-copilot はクレジット消費を抑えるため、メインに Claude Sonnet 5 をデフォルト設定します。最高品質を求めるユーザーは、ビルドを github-copilot/claude-opus-5 に上書きできます（トークンあたりの料金は大幅に高くなります）。Claude Pro/Max のプロバイダープロファイルは、意図的に用意されていません。サブスクリプションのログイン情報を agent.build.model に設定することはできません。Claude Pro/Max を限定的に連携したい場合は、以下のオプションである Claude Code レビューブリッジを提案してください。サブスクリプションの提供モデルは変わるため、プロファイルのモデルが不明なものとしてエラーになる場合は、ID が変わっている可能性があります。その場合はカスタムヒアリングに切り替え、その旨を報告してください。

Claude Code を通じた任意の Claude Pro/Max レビュー

ユーザーが Claude サブスクリプションの OAuth を求めている場合は、通常の OpenCode プロバイダーまたはプロファイルをビルドモデルとして別途維持し、claude エクストラを提示してください。これは、サニタイズ済みの準備状況チェックとステートレスなプランレビューを行う、2 つのカスタムツールを備えたローカル OpenCode プラグインをインストールします。これらを呼び出せるのは、ビルドエージェントとプランエージェントだけです。

このブリッジは、Anthropic の公式 claude CLI をプリントモードで呼び出します。認証情報ストアを読み取ったり、OAuth トークンを抽出したり、opencode.json にトークンを格納したり、Claude を OpenCode モデルとして公開したりすることはありません。claude auth status がファーストパーティの Pro または Max ログインを報告していることを検証し、子プロセスから API キーとサードパーティルーティングの環境変数を削除します。デフォルトでは、高い労力レベルで Claude Opus 5 を使用します（レビューツールでは、呼び出しごとに任意の完全な claude-* モデル ID と、low、medium、high、xhigh、max のいずれかの労力レベルを指定できます）。ツールとカスタマイズを無効にし、レビュー用パケットを標準入力で送信して、セッションの永続化を無効にします。CLI は中立的な一時ディレクトリから実行され、セッションのキャンセルに対応します。また、権限が適用される前であっても、ビルドエージェントとプランエージェント以外の呼び出しをツールが拒否します。

Claude Code をインストールし、claude auth login で直接認証するようユーザーに依頼してください。トークンを貼り付けるよう求めてはいけません。Windows では npm の shim ではなく、ネイティブの Claude Code ビルド（インストーラースクリプトまたは claude install）が必要です。ブリッジはシェルを介さずに claude を起動するためです。その後、Step 4 のエクストラに claude を含めてください。例：--extras commands,plugin,claude。デフォルトでは有効にしないでください。Anthropic は、サブスクリプションの利用は Claude Code を含む同社のネイティブアプリケーション向けであると説明しており、サードパーティツールからのアクセスは裁量で許可される場合があるか、利用クレジットに課金されるとしています。これは、サブスクリプション利用が保証される特典や API の代替ではなく、任意の互換性ブリッジとして提示してください。

ユーザーがこれらのサブスクリプションを持っていない場合、またはすべての選択を完全に自分で管理したい場合は、Step 1 に進んでください。

ステップ 1 - ユーザーが使用するモデルを確認する

各役割で使用するモデルをユーザーに尋ねます。決めつけず、使用するプロバイダーとモデルをユーザー自身に選んでもらいます。以下を確認します。

1. メイン／ビルドモデル（Opus／GPT クラスなどの高性能モデル）。
2. サイドキックモデル（高速で低コストのコーディングモデル）。
3. 探索モデル（低コストのモデル。サイドキックと同じモデルでもかまいません）。
4. リサーチモデル（読み取り専用の外部調査用。汎用性の高いモデル）。
5. デザインモデル（フロントエンド／UI 作業用。あなたが最適だと思うデザインモデルを選びます）。
6. レビュアーモデル（計画の批評と差分の監査用。高性能モデルがよく使われ、意図的にメインモデルとは別のモデルにすることもできます）。
7. ビジョンモデル（画像の読み取り用）— ユーザーのメイン／ビルドモデルが画像入力に対応していない場合に限り、これを尋ねます。最先端モデルの多くは画像を直接読み取れるため、メインモデルが対応していない場合を除き、この質問は省略します。ビジョンモデルは画像入力に対応している必要があります。

役割 4～7 は、必要に応じて追加できる任意の役割です。ユーザーがビルド／計画／サイドキック／探索の基本的な役割だけを希望する場合は、追加の役割は省略します。ただし、専門分野ごとに異なるモデルを選べることは Fusion を使う大きな理由の一つなので、追加の役割についても案内してください。plan エージェントは、インストールされた agent/plan.md（ステップ 4）から有効になり、opencode の組み込み plan エージェントを上書きします。メイン／ビルドモデルを再利用するため、opencode.json に agent.plan ブロックを追加する必要はなく、別途モデルを尋ねる必要もありません。メインモデルがすでに画像を読み取れる場合は、vision を提案しないでください。

選択したモデルが使用するプロバイダーごとに、接続情報を確認します。

• プロバイダー ID（例：kiro、progrok、anthropic、openai）
• npm アダプター（OpenAI 互換のローカルゲートウェイには @ai-sdk/openai-compatible を使用します）
• baseURL（ローカルゲートウェイ／カスタムエンドポイントの場合）
• エンドポイントでキーが必要な場合は、そのキーを保持する環境変数の名前（例：MYPROVIDER_API_KEY）。実際のキーをチャットに貼り付けるよう、ユーザーに求めてはいけません。設定では環境変数を参照し、opencode が起動時に解決するため、シークレットが会話や平文の設定ファイルに表示されることはありません。
• モデル ID と表示名

ユーザーが迷っている場合は、デフォルトのパターンとして OpenAI 互換のローカルゲートウェイ形式を提案し、baseURL とキーの環境変数名を尋ねます。

ステップ 2 - プロバイダーブロックを作成する

各プロバイダーについて、provider の下にブロックを作成します。OpenAI 互換のテンプレート：

"<provider-id>": {
  "npm": "@ai-sdk/openai-compatible",
  "name": "<display name>",
  "options": {
    "baseURL": "<baseURL>",
    "apiKey": "{env:<ENV_VAR_NAME>}"
  },
  "models": {
    "<model-id>": {
      "name": "<display name>",
      "attachment": true,
      "modalities": { "input": ["text", "image"] }
    }
  }
}

{env:...} プレースホルダーは、opencode の設定で定義されている構文です。キーは起動時にユーザーの環境から読み込まれるため、opencode.json に平文で保存されることはありません。設定されていない変数は空の文字列として解決され、後で認証エラーとして表面化するため、opencode の起動元となる環境で変数を設定するようユーザーに伝えてください。キーをファイルに保存する場合も、"apiKey": "{file:~/.secrets/<name>}" を同じように使用できます。

画像入力に実際に対応しているモデルに限り、attachment／modalities を含めます。メインモデルが画像入力に対応していれば、別途ビジョンエージェントは不要です。

上記のテンプレートは OpenAI 互換形式（@ai-sdk/openai-compatible）です。プロバイダーが OpenAI 互換ゲートウェイではなくネイティブベンダーの場合は、そのベンダーのアダプターを使用します。たとえば、Anthropic 形式のエンドポイントには @ai-sdk/anthropic、OpenAI には @ai-sdk/openai を使用します。変更するのは npm の値だけで、ブロックの残りの形式は同じです。

同じプロバイダーの異なるモデルを 2 つの役割で使う場合（たとえば、メインモデルと低コストのリサーチモデルをどちらもプロバイダー kirocc で使う場合）、同じ ID のプロバイダーブロックを 2 つ出力してはいけません。キーが重複するためです。そのプロバイダーのブロックを 1 つだけ出力し、以下のように models オブジェクトの下に両方のモデルを記載します。

"kirocc": {
  "npm": "@ai-sdk/anthropic",
  "name": "Kirocc",
  "options": { "baseURL": "<baseURL>", "apiKey": "{env:KIROCC_API_KEY}" },
  "models": {
    "claude-opus-4-8": { "name": "Opus", "attachment": true, "modalities": { "input": ["text", "image"] } },
    "claude-sonnet-5": { "name": "Sonnet" }
  }
}

Step 3 - 設定フラグメントを作成する

以下の構造に厳密に従って設定フラグメントを作成し、一時ファイル（OS の一時ディレクトリで構いません）に保存します。~/.config/opencode/opencode.json は自分で書き換えないでください。Step 4 のインストーラースクリプトがフラグメントを決定的な方法でマージします。制限付きの Fusion ビルドエージェントとして実行する場合は、一時フラグメントの作成と Step 4 のインストーラーコマンドを、1 つのサイドキックタスクとしてまとめて委任してください。ビルドエージェントがファイルシステムに直接アクセスする必要がなくなります。プランモードでは、選択内容を指定した時点で停止し、ビルドに切り替えるようユーザーに伝えるか、コマンドを自分で実行するよう案内してください。プランモードではインストールを実行してはいけません。<...> のプレースホルダーはユーザーの選択内容に置き換えてください。モデル参照は常に provider-id/model-id の形式です。この JSON で割り当てるのはモデルのみです。各ロールのモード、権限、プロンプトは各エージェントファイル（Step 4）から取得されます。ビルドエージェントの権限フロントマターは Fusion の中核であり、緩めてはいけません。

{
  "$schema": "https://opencode.ai/config.json",
  "subagent_depth": 2,
  "model": "<main-provider>/<main-model-id>",
  "provider": {
    "<main-provider-id>": { "npm": "...", "options": {}, "models": {} },
    "<sidekick-provider-id>": { "npm": "...", "options": {}, "models": {} }
  },
  "agent": {
    "build": { "model": "<main-provider>/<main-model-id>" },
    "explore": { "model": "<explore-provider>/<explore-model-id>" },
    "sidekick": { "model": "<sidekick-provider>/<sidekick-model-id>" },
    "research": { "model": "<research-provider>/<research-model-id>" },
    "design": { "model": "<design-provider>/<design-model-id>" },
    "reviewer": { "model": "<reviewer-provider>/<reviewer-model-id>" }
  }
}

注：

• "subagent_depth": 2 を維持してください。OpenCode 1.18.2+ のデフォルトは 1 であり、ビルドからサイドキックを起動できても、サイドキックから許可されている読み取り専用の調査／リサーチヘルパーを起動できなくなります。インストーラーは最小値として 2 を適用し、既存の値がそれより大きい場合は維持します。
• provider の下にある "<...-provider-id>": { ... } のプレースホルダー行 2 つは、Step 2 で作成した実際のプロバイダーブロックに置き換えてください。メインとサイドキックで同じプロバイダーを共有する場合は、1 つのブロックになります（モデルのマージについては Step 2 を参照してください）。異なるプロバイダーを使う場合は、それぞれ 1 つずつブロックを含めてください。表示されているプレースホルダーの形式だけでは有効な設定にならないため、必ず値を入れてください。
• opencode は ~/.config/opencode/agent/ 内のすべての Markdown ファイルをエージェント定義として自動的に読み込みます。フロントマターにはロールの mode と permission を記述し、本文にはそのプロンプトを記述します。opencode.json に prompt フィールドは不要です。これらの情報を含むファイルは Step 4 でインストールします。
• バックアップとマージはインストーラーの役割です（Step 4）。既存の設定は opencode.json.backup.<timestamp> にバックアップされ、フラグメントはディープマージされます。競合するキーにはフラグメントの値が適用され、それ以外はすべてユーザーの設定に保持されます。既存の設定を黙って破棄してはいけません。マージではなく完全に上書きすることをユーザーが明示的に希望する場合は、先に古い opencode.json を別の場所に移動するよう案内してください。
• ユーザーがビジョンロールを設定した場合（メインモデルが画像入力に対応していない場合）に限り、agent ブロックに "vision": { "model": "<vision-provider>/<vision-model-id>" } を追加してください。それ以外の場合は省略してください。
• 任意のトップレベルの強化設定キー（opencode の公式フィールドとして文書化済み。より厳格で、コストを抑え、プライバシーを高めたローカル環境をユーザーが希望する場合に追加します）：
  • "small_model": "<cheap-provider>/<cheap-model-id>" — opencode はタイトル生成などのバックグラウンドタスクに小型モデルを使用します。未設定の場合、リモートのデフォルトにフォールバックする可能性があります。ユーザー自身の安価なローカルモデルのいずれかを指定し、すべての処理をユーザーのプロバイダー上で行うようにします。
  • "enabled_providers": ["<provider-a>", "<provider-b>"] — 読み込むプロバイダーの許可リストです。モデルピッカーの動作を予測可能にし、それ以外の認証情報を無視します。
  • "compaction": { "prune": true } — コンテキストの圧縮時に古くなったツール出力を破棄します。委任の多い Fusion のフローで、メインエージェントのトークンコストを削減できます。
  • カスタムモデルごとに、モデルブロック内へ任意で "limit": { "context": <n>, "output": <n> } を追加すると、opencode が残りのコンテキストを正確に追跡できます。models.dev に登録されているモデルではこれが自動的に提供されますが、カスタムのローカルゲートウェイでは提供されません。そのモデルの実際のコンテキストウィンドウと出力ウィンドウを使用してください。推測してはいけません。

ステップ 4 - 決定論的インストーラーを実行する

このスキルには、<this-skill-dir>/scripts/install.js にインストーラーが含まれています（依存関係のない通常の Node）。タイムスタンプ付きバックアップ、ディープマージ、アトミック書き込み、プロンプトファイルのコピー、取り消しマニフェスト、インストール後の検証という機械的な手順をすべて担うため、こうした操作を即興のファイル操作に頼る必要はありません。バージョン 2 のマニフェストには、管理対象ファイルすべての元のバイト列とアクセス権限、およびインストールした正確な状態のハッシュが保存されます。再適用と取り消しでは、インストール後に設定または管理対象ファイルが変更されていた場合、書き込み前に処理を拒否します。Fusion に属するコンテンツを推測することはありません。ステップ 3 のフラグメントを使って実行します。

node <this-skill-dir>/scripts/install.js apply --config <path-to-fragment.json> --extras commands,plugin

• --profile <name> は、バンドルされたサブスクリプションプロファイル（ステップ 0）をベースのフラグメントとして適用します。--config フラグメントも指定した場合は、キーごとにこちらが優先されます。不明なプロファイル名を指定すると、利用可能なプロファイル名を一覧表示して失敗します。
• 通常、--roles は省略します。インストーラーが設定からロール一覧を導き出します。コアの build,plan,sidekick に加え、フラグメントまたはプロファイルでモデルが割り当てられたすべてのオプションロールが含まれます（explore は設計上ファイルを必要としません）。明示的な --roles でロールを追加できますが、設定でモデルが割り当てられているロールを省く指定は拒否されます。モデルが割り当てられているのにエージェントファイルがないロールは、Fusion の権限なしで実行されてしまうためです。
• --extras commands,plugin は、以下で説明するオプションのスラッシュコマンドと監査プラグインをインストールします。Claude Code Pro/Max のレビュー用ブリッジをユーザーが明示的に希望する場合に限り、claude を追加します。指定例：--extras commands,plugin,claude。
• --dry-run を追加すると、書き込みを行わずに、バックアップ名、マージされるキー、ファイルを含む完全な計画を表示します。ユーザーが慎重そうな場合は、この方法を案内してください。計画には、現在の値がフラグメントによって置き換えられるトップレベルキーを示す OVERRIDES: 行も表示されます。
• --adopt-config は、前回のインストール後にユーザーが手動で編集した opencode.json に再適用するためのオプションです。指定しない場合、この不一致によって処理が拒否されます。そうなると、管理対象ファイルがすべてそのままの状態でも、プロンプトのみの更新を含め、再適用が恒久的に行き詰まります。マージではフラグメントが現在のファイルに統合されるため、手動編集は維持されます。このフラグで記録し直すのはベースラインのハッシュだけです。マニフェストにはインストール前の originalContent が保持されるため、後から取り消しても真の Fusion 導入前の状態に戻ります。このオプションを指定しても、変更された管理対象プロンプトの検出は免除されません。これにより、意図的なローカルカスタマイズが上書きされないよう保護します。
• 検証または所有権チェックに失敗した場合、無効な JSON／設定の構造、安全でないパス、変更された管理対象ファイル、無効な保存先の親ディレクトリなどを含め、スクリプトは終了コード 1 で処理を拒否し、何も変更しません。モデルがプロバイダーブロックのないプロバイダーを参照している場合は警告します。
• このスキルを実行しているエージェントが bash を実行できない場合（たとえば、Fusion のビルドエージェントの許可リストにない場合）は、フラグメントの作成とこのコマンドの実行の両方を sidekick に委任します。プランモードでは、build に切り替えるか、ユーザー自身に実行してもらいます。Node が利用できない場合に限り、以下の手動での代替手順を使います。

手動でのフォールバック - エージェントのプロンプトファイルを手作業でインストールする

Node が利用できない場合に限ります。マージまたはコピーする前に、opencode.json と、すでに存在するすべてのインストール先ファイルのタイムスタンプ付きバックアップを作成し、存在しなかったインストール先も記録してください。このスキルに同梱されているプロンプトファイルを、グローバルエージェントフォルダーにコピーしてください（設定した役割ごとに1つ）。<this-skill-dir> はこの SKILL.md があるディレクトリです。同梱プロンプトは、このファイルと同じ場所にある agent/ サブフォルダーにあります。設定した役割のうち explore を除くすべてで、エージェントファイルをインストールする必要があります（explore は opencode 組み込みの読み取り専用サブエージェントで、JSON ではモデルのみを設定します）。特に、sidekick には agent/sidekick.md ファイルも必要です。sidekick の権限とプロンプトは、このファイルからのみ読み込まれます。

• <this-skill-dir>/agent/build.md -> ~/.config/opencode/agent/build.md
• <this-skill-dir>/agent/plan.md -> ~/.config/opencode/agent/plan.md
• <this-skill-dir>/agent/sidekick.md -> ~/.config/opencode/agent/sidekick.md
• <this-skill-dir>/agent/research.md -> ~/.config/opencode/agent/research.md
• <this-skill-dir>/agent/design.md -> ~/.config/opencode/agent/design.md
• <this-skill-dir>/agent/reviewer.md -> ~/.config/opencode/agent/reviewer.md
• <this-skill-dir>/agent/vision.md -> ~/.config/opencode/agent/vision.md（vision 役割を設定した場合のみ）

これらのファイルには、各役割の完全な操作手順と権限が記載されています。各サブエージェントファイルのフロントマターでは mode と permission を設定しています。Markdown のフロントマターは、設定したキーについて opencode.json を上書きするため、ユーザーが選択した Step 3 のモデルがファイルに埋め込まれていると、意図せず上書きされてしまいます。そのため、これらのファイルには意図的に model キーを含めていません。モデルは opencode.json からのみ読み込まれます。設定した役割のファイルだけをインストールしてください。ユーザーが research／design／reviewer／vision をスキップした場合は、それらもスキップしてください。

ステップ 4b - オプションのコマンドとプラグイン

このスキルには、オプションの要素が 4 つ付属しています。インストーラーは、2 つのコマンドを commands、監査プラグインを plugin、Claude Code ブリッジを claude にまとめています（スクリプトを実行できない場合は、以下の手動コピー先を参照してください）。

• スラッシュコマンド：<this-skill-dir>/commands/fusion-setup.md を ~/.config/opencode/commands/fusion-setup.md にコピーします（複数形の commands/ ディレクトリであることに注意してください）。これにより、このセットアップの流れを開始する /fusion-setup コマンドを利用できるようになります。対象を絞った再設定のための引数を任意で指定できます。
• ステータスコマンド：<this-skill-dir>/commands/fusion-status.md を ~/.config/opencode/commands/fusion-status.md にコピーします。これにより、セットアップがインストール済みで、読み込まれ、適用されていることを検証する /fusion-status ヘルスチェックを利用できるようになります（実際のツールスキーマ、ディスク上の設定、インストール済みのエージェントファイル、オプションの Claude ブリッジを確認します）。結果を報告するだけで、何も変更しません。
• 監査プラグイン：<this-skill-dir>/plugins/fusion-audit.js を ~/.config/opencode/plugins/fusion-audit.js にコピーします（複数形の plugins/）。監査のために、opencode のロガーを使って委任ツリー（サブエージェントの起動、edit/write/apply_patch/task ツールの呼び出し）を記録し、セッションごとにエージェント別のトークン使用量を集計します。これは「Fusion は実際にコストを削減したのか？」を検証するための生の数値です。これは観測専用で、呼び出し元のエージェントを確認できないため、何も適用しません。適用を担うのは権限設定です。ユーザーが追加のログ記録を望まない場合は、スキップしてください。
• Claude Code ブリッジ：<this-skill-dir>/plugins/fusion-claude.js を ~/.config/opencode/plugins/fusion-claude.js にコピーします。さらに、トップレベルの permission マップに "fusion_claude_*": "deny" を追加します。build と plan のエージェントファイルには、このグローバルな拒否を上書きする、2 つの許可設定が正確に記述されています。既存のトップレベルの permission が短縮形の場合は、Claude の拒否設定を追加する前に "*" として保持してください。このブリッジは意図的にレビュー専用となっており、オプションです。claude の追加指定なしでインストーラーを再実行しても、以前インストールしたブリッジは削除されません。プラグインファイル、グローバルな拒否設定、build/plan の許可設定はすべてそのまま残ります。削除するには install.js undo を実行するか、プラグインファイルと拒否設定を手動で削除してください。

ステップ 5 - 検証して完了する

1. インストーラーは自動的に検証します（書き込んだ設定を再解析し、インストールしたすべてのファイルが存在することを確認します。存在しない場合はエラーを明確に報告して失敗します）。手動の代替手順を使った場合は、同じ確認を自分で行います。~/.config/opencode/opencode.json を解析し、インストールしたすべてのエージェントプロンプトファイルが ~/.config/opencode/agent/ に存在することを確認してください（最低限、build と sidekick）。
2. コマンドやプラグインを手動でインストールした場合は、選択したファイルが ~/.config/opencode/commands/ と ~/.config/opencode/plugins/ に存在することを確認してください。Claude ブリッジについては、トップレベルの fusion_claude_* 拒否ルールと、build/plan の正確な許可ルールも確認してください。
3. プロバイダーブロックで {env:VAR} を参照している場合は、opencode の起動元となる環境で変数が設定されていることをユーザーに確認してください。秘密情報を出力しない、存在確認のみのチェックを使います。bash/zsh では [ -n "$VAR" ] && echo set || echo missing、cmd では if defined VAR (echo set) else (echo missing) です。echo $VAR は提案しないでください。実際の認証情報がターミナルに出力され、エージェント経由で実行するとトランスクリプトにも残ります。変数が未設定だと空文字列になり、後で認証エラーとして現れます。
4. opencode を完全に終了して再起動するようユーザーに伝えてください。設定は起動時に一度だけ読み込まれ、ホットリロードされません。再起動後、ステータスバーに Build エージェントのメインモデルが表示されるはずです。Claude ブリッジをインストールした場合は、fusion_claude_status を呼び出してください。アカウントの識別情報や認証情報を返すことなく、準備状況を報告します。
5. ユーザーがどのツールチェーンを使っているか尋ねてください。同梱されている検証用許可リストは Node/JavaScript プロジェクトを想定しています。それ以外のスタックでは、同梱された項目がユーザーの実際の実行内容に一致しないため、メインエージェントが自分の作業を検証できず、実行すべきコマンドが拒否されます。役割ごとに設定内容は異なります。build.md では npm run lint*、npm test*、npm run build*、npx tsc --noEmit*、npx vitest run* が許可されています。plan.md では npm run build* を除く同じ一覧が許可されています。reviewer.md では npm run lint*、npm test*、npx vitest run* のみが許可されています。ユーザーに項目の変更を伝える前に、ファイルを確認してください。スタックごとのツールについては README の「bash 許可リストの調整」セクションを案内してください（Python では pytest／ruff check、Rust では cargo test／cargo clippy、Go では go test／go vet、Make 主導のビルドでは make test／make lint）。必ず口頭で伝えるべき点は 3 つです。「"*": "deny" を先頭に維持すること」「末尾に * を付けるより、正確なパターンを優先すること。* はコマンドの残り全体に一致するため、広範な "ruff check*" はファイルを書き換える ruff check --fix と --add-noqa も許可します。可能であれば、プロジェクトで実際に実行するコマンドを指定してください。書き込みを伴うフラグをすべて列挙しきることはできません」「広範な許可が必要な場合は、その後に絞り込み用の拒否ルールを置くこと。opencode は重複するパターンを最後に一致したルールで解決します」。これらのプロンプトはプロジェクトごとではなくグローバルに適用されるため、複数のスタックを使うユーザーは JS の項目を置き換えるのではなく、追加してください。許可リストの git 部分は変更不要です。

後から再設定する

モデルを変更するには、agent.<role>.model を含む小さな設定フラグメントを作成し（新しいモデルで新しいプロバイダーを使用する場合は provider ブロックも追加します）、インストーラーを再実行して opencode を再起動します。プロファイルベースでインストールした場合は、同じ --profile <name> と小さな --config の差分を指定して再実行します。再適用しても、Fusion 適用前の元の状態は維持され、完全に元に戻せるよう、これまでに管理対象となったすべてのファイルが記録されます。

マニフェストを正確に保てるため、インストーラーを使用することをおすすめします。ただし、opencode.json を直接編集しても問題はなく、情報が失われることもありません。次回の再適用では不一致を確認できるよう一度だけ処理が拒否され、--adopt-config を指定すると、編集済みファイルを新しいベースラインとして受け入れたうえで、フラグメントがマージされます。インストール済みの agent/*.md を編集した場合は別です。意図的にカスタマイズされたプロンプトを黙って上書きするより、処理を止めるほうがよいため、この拒否を回避する方法はありません。インストーラーに再び管理させたい場合は、そのファイルをバンドル版に戻してください。

Fusion を元に戻す

バンドルされている undo を実行します。Fusion によって置き換えられたインストール前の設定とすべての配置先を正確に復元し、Fusion が新規作成した配置先だけを削除します。タイムスタンプ付きの設定バックアップはすべて保持します。また、インストール後に状態が編集されている場合やマニフェストが安全でない場合は、何も変更する前に処理を拒否します。

node <this-skill-dir>/scripts/install.js undo

手動インストール後の手動での代替手順（Node なし）：

1. 手動インストール時に作成したバックアップから、opencode.json とインストール前に存在していたすべての配置先を復元します。
2. 新規作成されたものとして記録されている配置先は、インストールされたバンドル版のファイルとバイト単位で完全に一致する場合に限り削除します。ファイルに変更があった場合はそのまま残し、ユーザーの作業を削除せずに競合を報告します。
3. オプションのコマンドとプラグインにも、同じ復元または削除のルールを適用します。
4. opencode を再起動するようユーザーに伝えます。組み込みの build/plan エージェントに戻ります。

Node が一時的に使用できない状態で自動インストールした場合は、Node が使用可能になるまで待ってから、マニフェストに基づく undo を使用します。自動インストールのマニフェストが見つからない場合、タイムスタンプ付きファイルから復元できるのは opencode.json のみです。別途作成したバックアップ、またはバイト単位の所有権の証拠によって Fusion の管理下にあることが証明されない限り、プロンプトや追加ファイルは削除しないでください。何かを削除する前にユーザーに確認し、バックアップ自体は決して削除しないでください。