fusion-setup

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fusion setup

Fusion 配置流程

This skill configures the Fusion agent team (a main agent, a sidekick executor, an explore searcher, and optional specialists) by writing the user's GLOBAL opencode config at

~/.config/opencode/

(on Windows:

%USERPROFILE%\.config\opencode\

). It does not require cloning any repository.

opencode resolves that directory as

$XDG_CONFIG_HOME/opencode/

when

XDG_CONFIG_HOME

is set and non-empty, falling back to

~/.config/opencode/

otherwise. Every

~/.config/opencode/...

path below means that resolved directory. The bundled installer in Step 4 works this out itself, so the normal flow needs no special handling; only the manual fallback in Step 4b and the verification in Step 5 need you to resolve it by hand. Installing into

~/.config/opencode/

on a machine with a different

XDG_CONFIG_HOME

writes a tree opencode never reads - the install looks successful and Fusion silently never loads.

本技能通过将用户的全局opencode配置写入

~/.config/opencode/

（Windows系统为

%USERPROFILE%\.config\opencode\

），来配置Fusion代理团队（包含主代理、助手执行代理、探索搜索代理以及可选的专家代理）。无需克隆任何仓库。

当

XDG_CONFIG_HOME

环境变量已设置且非空时，opencode会将该目录解析为

$XDG_CONFIG_HOME/opencode/

，否则默认使用

~/.config/opencode/

。下文所有

~/.config/opencode/...

路径均指解析后的目录。步骤4中的捆绑安装程序会自动处理路径解析，因此常规流程无需特殊操作；仅在步骤4b的手动回退方案和步骤5的验证环节中，需要手动解析路径。若在设置了不同

XDG_CONFIG_HOME

的机器上安装到

~/.config/opencode/

，会导致opencode永远无法读取配置树——安装看似成功，但Fusion会静默加载失败。

What Fusion is

Fusion 是什么

Fusion splits work across agents with asymmetric permissions:

```
build
```
(main, primary): a strong model that plans, makes judgment calls, and reviews. It CANNOT edit files, search the codebase, or run arbitrary shell. Its only path to changing files is delegating to the sidekick via the
```
task
```
tool.
```
plan
```
(primary): plan mode - the same planning brain as build. Produces a reviewed plan and delegates exploration, but does not execute; switch to build to carry it out. Overrides opencode's built-in plan agent so plan mode stays Fusion-aware.
```
sidekick
```
(subagent): a cheaper, fast model with full
```
edit
```
and broad
```
bash
```
access (direct
```
git commit
```
/
```
git push
```
and common wrappers are denied as defense-in-depth - committing stays with the main agent). It executes precise specs handed to it by the main agent.
```
explore
```
(subagent): a cheap model used for read-only codebase exploration.
```
research
```
(subagent): read-only external research - web search and docs. No edit access.
```
design
```
(subagent): frontend/UI implementation. Loads design skills, edits files, runs the dev/build tooling.
```
reviewer
```
(subagent): critiques a plan before implementation and audits a diff before commit (correctness, scope, security). Read-only plus lint/test; no edit access.
```
vision
```
(subagent): reads images/screenshots the main model cannot see and reports them as text. Only needed when the main model lacks image input.

Think of the repo as a catalog of roles: the core (build/plan/sidekick/explore) is required, and the rest are optional pieces you install only if your workflow needs them. The research/design/reviewer/vision specialists are optional. Each role's model is chosen independently - that is a key reason to use Fusion: put your favorite design model on

design

and a different reviewer model on

reviewer

The asymmetry is enforced by the permission layer, not by convention. Preserving the exact permission frontmatter in the bundled agent files installed during Step 4 is what makes Fusion work.

Fusion将工作分配给拥有不对称权限的多个代理：

```
build
```
（主代理，核心角色）：一个强大的模型，负责规划、决策和审核。它无法编辑文件、搜索代码库或运行任意shell命令。它只能通过
```
task
```
工具将文件修改任务委托给助手代理。
```
plan
```
（核心角色）：规划模式——与build使用相同的规划逻辑。生成经过审核的计划并委托探索任务，但不执行；需切换到build模式来执行计划。它会覆盖opencode内置的plan代理，确保规划模式兼容Fusion。
```
sidekick
```
（子代理）：成本更低、速度更快的模型，拥有完整的
```
edit
```
权限和广泛的
```
bash
```
访问权限（出于纵深防御考虑，禁止直接执行
```
git commit
```
/
```
git push
```
及常用包装器——提交操作仍由主代理负责）。它执行主代理下达的精确任务指令。
```
explore
```
（子代理）：低成本模型，用于只读的代码库探索。
```
research
```
（子代理）：只读的外部研究——网页搜索和文档查询。无编辑权限。
```
design
```
（子代理）：前端/UI实现。加载设计技能、编辑文件、运行开发/构建工具。
```
reviewer
```
（子代理）：在实施前审核计划，在提交前检查差异（正确性、范围、安全性）。拥有只读权限及 lint/测试权限；无编辑权限。
```
vision
```
（子代理）：读取主模型无法识别的图像/截图，并将其转换为文本报告。仅当主模型不支持图像输入时才需要。

可以将该仓库视为角色目录：核心角色（build/plan/sidekick/explore）是必需的，其余角色为可选组件，仅在工作流需要时安装。研究/设计/审核/视觉专家均为可选角色。每个角色的模型可独立选择——这是使用Fusion的关键优势：为

design

角色选择你偏好的设计模型，为

reviewer

角色选择另一个审核模型。

权限不对称由权限层强制实施，而非依赖约定。保留步骤4中安装的捆绑代理文件中的精确权限前置内容，是Fusion正常工作的核心。

Step 0 - Offer a subscription profile

步骤0 - 提供订阅配置文件

Before the per-role interview, ask whether the user's models come from one of these subscriptions. Each maps to a bundled profile - a ready-made config fragment in

<this-skill-dir>/profiles/

with sane per-role defaults:

Profile	Subscription
`opencode-go`	OpenCode Go (low-cost open-model plan on OpenCode Zen)
`opencode-zen`	OpenCode Zen pay-as-you-go credits
`opencode-zen-free`	OpenCode Zen free-tier models only
`chatgpt`	ChatGPT Plus or Pro
`github-copilot`	GitHub Copilot

If the user names one (including as a

/fusion-setup

argument):

Read
```
<this-skill-dir>/profiles/<name>.json
```
and show its role -> model table for confirmation. The JSON is the single source of truth - never quote model ids from memory or from this document.
Remind them that authentication is out-of-band: the provider must be connected once via
```
opencode auth login
```
(or
```
/connect
```
inside opencode) with their subscription login or key. NEVER ask for a key in the chat. Profile provider blocks deliberately contain no npm adapter, baseURL, or apiKey - opencode knows these providers natively; the blocks only carry display names.
Skip Steps 1-3 and run the installer with the profile (Step 4's delegation rules still apply):
bash
```
node <this-skill-dir>/scripts/install.js apply --profile <name> --extras commands,plugin
```
No
```
--roles
```
flag is needed: the installer derives the role list from the profile, so every role the profile assigns a model also gets its permission-bearing agent file.
To change one or two picks, keep
```
--profile <name>
```
and add
```
--config <fragment.json>
```
holding just the delta (for example a different
```
agent.reviewer.model
```
, plus a provider block only if that model's provider is outside the profile). The fragment wins over the profile. Removing an optional role a profile assigns cannot be expressed as an override - use the custom interview (Steps 1-4) without
```
--profile
```
instead.

Caveats worth mentioning when they apply:

opencode-zen-free

includes a

vision

role because its main model cannot read images, while the other profiles lead with models that read images directly;

opencode-zen-free

runs on free-period models whose prompts may be used for training under OpenCode's policy - warn users to keep sensitive code off it; the single-vendor

chatgpt

profile keeps every role on one vendor, so its reviewer differs from build by model (GPT-5.6 Terra) rather than by vendor - a user with a second provider may still want to override the reviewer for true cross-vendor review;

github-copilot

defaults its main to Claude Sonnet 5 for credit-cost sanity - a user who wants max quality can override build to

github-copilot/claude-opus-5

(billed much higher per token). There is deliberately NO Claude Pro/Max provider profile. A subscription login cannot become

agent.build.model

. If the user wants a limited Claude Pro/Max integration, offer the optional Claude Code review bridge below. Subscription lineups rotate - if a profile model errors as unknown, the ids may have drifted; fall back to the custom interview and report it.

在针对各角色进行设置前，询问用户的模型是否来自以下订阅之一。每个订阅对应一个捆绑配置文件——位于

<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

参数）：

读取
```
<this-skill-dir>/profiles/<name>.json
```
并展示其角色→模型对照表供用户确认。JSON是唯一的事实来源——切勿凭记忆或本文档引用模型ID。
提醒用户需通过带外方式完成认证：必须先通过
```
opencode auth login
```
（或opencode内部的
```
/connect
```
）使用订阅账号或密钥连接提供商。切勿在聊天中索要密钥。配置文件的提供商块刻意不包含npm适配器、baseURL或apiKey——opencode原生支持这些提供商；该块仅包含显示名称。
跳过步骤1-3，使用该配置文件运行安装程序（步骤4的委托规则仍然适用）：
bash
```
node <this-skill-dir>/scripts/install.js apply --profile <name> --extras commands,plugin
```
无需
```
--roles
```
标志：安装程序会从配置文件中推导角色列表，因此配置文件分配了模型的每个角色都会获得其带权限的代理文件。
若要修改一两项选择，保留
```
--profile <name>
```
并添加
```
--config <fragment.json>
```
，其中仅包含差异内容（例如不同的
```
agent.reviewer.model
```
，若该模型的提供商不在配置文件中，还需添加提供商块）。配置片段的优先级高于配置文件。若要移除配置文件分配的可选角色，无法通过覆盖实现——请改用不带
```
--profile
```
的自定义设置流程（步骤1-4）。

需根据情况提及以下注意事项：

opencode-zen-free

包含

vision

角色，因为其主模型无法读取图像，而其他配置文件默认使用可直接读取图像的模型；

opencode-zen-free

使用免费期模型，其提示词可能会根据OpenCode的政策用于训练——提醒用户不要在该配置下处理敏感代码；单一供应商的

chatgpt

配置文件让所有角色使用同一供应商，因此其审核模型与build模型的差异仅在于模型（GPT-5.6 Terra）而非供应商——若用户拥有第二个提供商，仍可覆盖审核模型以实现跨供应商审核；

github-copilot

默认将主模型设置为Claude Sonnet 5以控制成本——若用户追求最高质量，可将build模型覆盖为

github-copilot/claude-opus-5

（按token计费更高）。刻意不提供Claude Pro/Max提供商配置文件。订阅账号无法直接作为

agent.build.model

使用。若用户想要有限的Claude Pro/Max集成，可提供下方的可选Claude Code审核桥接工具。订阅产品线会定期更新——若配置文件中的模型ID报错为未知，可能是ID已变更；请回退到自定义设置流程并上报该问题。

Optional Claude Pro/Max review through Claude Code

可选：通过Claude Code实现Claude Pro/Max审核

If the user asks for Claude subscription OAuth, keep another normal OpenCode provider or profile as the build model and offer the

claude

extra. It installs a local OpenCode plugin with two custom tools: a sanitized readiness check and a stateless plan review. Only the build and plan agents may call them.

The bridge invokes Anthropic's official

claude

CLI in print mode. It does not read the credential store, extract an OAuth token, put a token in

opencode.json

, or expose Claude as an OpenCode model. It verifies that

claude auth status

reports a first-party Pro or Max login, removes API-key and third-party routing variables from the child process, defaults to Claude Opus 5 at high effort (the review tool accepts an optional full

claude-*

model id and an effort of low, medium, high, xhigh, or max per call), disables tools and customizations, sends the review packet over stdin, and disables session persistence. It runs the CLI from a neutral temporary directory, honors session cancellation, and its tools refuse callers other than the build and plan agents even before permissions apply.

Ask the user to install Claude Code and authenticate directly with

claude auth login

; never ask them to paste a token. On Windows they need the native Claude Code build (the installer script or

claude install

), not the npm shim - the bridge spawns

claude

without a shell. Then include

claude

in Step 4's extras, for example

--extras commands,plugin,claude

. Do not enable this by default. Anthropic describes subscription usage as intended for its native applications, including Claude Code, and says third-party-tool access may be allowed at its discretion or charged to usage credits. Present this as an optional compatibility bridge, not as a guaranteed subscription entitlement or an API replacement.

If the user has none of these subscriptions, or wants full control over every pick, continue with Step 1.

如果用户询问Claude订阅OAuth，请保留常规OpenCode提供商或配置文件作为build模型，并提供

claude

附加组件。它会安装一个本地OpenCode插件，包含两个自定义工具：一个经过 sanitize 的就绪检查工具和一个无状态计划审核工具。仅build和plan代理可调用这些工具。

该桥接工具以打印模式调用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，支持会话取消，且其工具会拒绝build和plan代理以外的调用者，甚至在权限验证之前就会拦截。

请用户安装Claude Code并直接通过

claude auth login

完成认证；切勿要求用户粘贴令牌。在Windows系统上，他们需要使用原生Claude Code构建版本（安装脚本或

claude install

），而非npm垫片——桥接工具会在不使用shell的情况下启动

claude

。然后在步骤4的附加组件中包含

claude

，例如

--extras commands,plugin,claude

。请勿默认启用该功能。Anthropic表示订阅使用旨在用于其原生应用（包括Claude Code），第三方工具访问可能需经其酌情允许或从使用额度中扣费。请将其作为可选兼容性桥接工具呈现，而非保证的订阅权益或API替代品。

如果用户没有上述任何订阅，或想要完全控制所有选择，请继续执行步骤1。

Step 1 - Gather the user's model choices

步骤1 - 收集用户的模型选择

Ask the user which model to use for each role. Do not assume; let them choose their own provider and models. Collect:

Main/build model (a strong model - e.g. an Opus/GPT-class model).
Sidekick model (a fast, cheaper coding model).
Explore model (cheap; can be the same as sidekick).
Research model (read-only external research; a solid general model).
Design model (frontend/UI work; pick whichever model does design best in your opinion).
Reviewer model (critiques plans and audits diffs; often a strong model, and deliberately can differ from the main model).
Vision model (reads images) - ONLY ask this if the user's main/build model does not support image input. Most frontier models read images directly, so skip this question unless the main model cannot. The vision model must be one that accepts image input.

Roles 4-7 are optional a-la-carte pieces. If the user only wants the core build/plan/sidekick/explore roles, skip them - but offer them, since choosing a different model per specialist is a key reason to use Fusion. The

plan

agent activates from its installed

agent/plan.md

(Step 4), which overrides opencode's built-in plan agent - it reuses the main/build model and needs no

agent.plan

block in opencode.json and no separate model question. Do not offer

vision

when the main model already reads images.

For each distinct provider the chosen models use, collect the connection details:

provider id (e.g.
```
kiro
```
,
```
progrok
```
,
```
anthropic
```
,
```
openai
```
)
the npm adapter (for OpenAI-compatible local gateways use
```
@ai-sdk/openai-compatible
```
)
baseURL (for local gateways / custom endpoints)
if the endpoint needs a key: the NAME of an environment variable that holds it (e.g.
```
MYPROVIDER_API_KEY
```
). NEVER ask the user to paste the actual key into the chat - the config references the variable and opencode resolves it at startup, so the secret never appears in the conversation or in plaintext config.
the model id(s) and a display name

If the user is unsure, offer the OpenAI-compatible local-gateway shape as the default pattern and ask for their baseURL and key env var name.

询问用户为每个角色选择的模型。请勿假设，让用户自行选择提供商和模型。收集以下信息：

主/build模型（强大的模型——例如Opus/GPT级别的模型）。
Sidekick模型（快速、低成本的编码模型）。
Explore模型（低成本；可与sidekick使用相同模型）。
Research模型（只读外部研究；可靠的通用模型）。
Design模型（前端/UI工作；选择你认为最擅长设计的模型）。
Reviewer模型（审核计划并检查差异；通常为强大模型，且可刻意与主模型不同）。
Vision模型（读取图像）——仅当用户的主/build模型不支持图像输入时才询问。大多数前沿模型可直接读取图像，因此除非主模型无法读取图像，否则跳过该问题。Vision模型必须支持图像输入。

角色4-7为可选的单点组件。如果用户仅需要核心的build/plan/sidekick/explore角色，可跳过这些角色——但需主动提供选择，因为为每个专家角色选择不同模型是使用Fusion的关键优势。

plan

代理通过安装的

agent/plan.md

（步骤4）激活，它会覆盖opencode内置的plan代理——它重用主/build模型，无需在opencode.json中添加

agent.plan

块，也无需单独询问模型问题。当主模型已支持图像输入时，请勿提供

vision

角色选项。

对于所选模型使用的每个不同提供商，收集连接详情：

提供商ID（例如
```
kiro
```
、
```
progrok
```
、
```
anthropic
```
、
```
openai
```
）
npm适配器（对于兼容OpenAI的本地网关，使用
```
@ai-sdk/openai-compatible
```
）
baseURL（用于本地网关/自定义端点）
如果端点需要密钥：存储密钥的环境变量名称（例如
```
MYPROVIDER_API_KEY
```
）。切勿要求用户将实际密钥粘贴到聊天中——配置文件引用该变量，opencode会在启动时解析它，因此密钥永远不会出现在对话或明文配置中。
模型ID和显示名称

如果用户不确定，可提供兼容OpenAI的本地网关格式作为默认模式，并询问其baseURL和密钥环境变量名称。

Step 2 - Build the provider blocks

步骤2 - 构建提供商块

For each provider, build a block under

provider

. OpenAI-compatible template:

json

"<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"] }
    }
  }
}

The

{env:...}

placeholder is documented opencode config syntax: the key is read from the user's environment at startup, so it never sits in plaintext in opencode.json. An UNSET variable silently resolves to an empty string, which surfaces later as auth errors - tell the user to set the variable in the environment they launch opencode from. If they prefer a key file,

"apiKey": "{file:~/.secrets/<name>}"

works the same way.

Only include

attachment

modalities

for models that actually support image input. A main model with image input means no separate vision agent is needed.

The template above shows the OpenAI-compatible shape (

@ai-sdk/openai-compatible

). If a provider is a native vendor rather than an OpenAI-compatible gateway, use that vendor's adapter instead - for example

@ai-sdk/anthropic

for an Anthropic-style endpoint or

@ai-sdk/openai

for OpenAI. Only the

npm

value changes; the rest of the block shape is the same.

If two roles use different models from the SAME provider (for example a main model and a cheaper research model both on provider

kirocc

), do NOT emit two provider blocks with the same id - that is a duplicate key. Emit ONE block for that provider with BOTH models listed under its

models

object, like this:

json

"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" }
  }
}

为每个提供商在

provider

下构建一个块。兼容OpenAI的模板：

json

"<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

字段。若主模型支持图像输入，则无需单独的vision代理。

上述模板展示了兼容OpenAI的格式（

@ai-sdk/openai-compatible

）。如果提供商是原生供应商而非兼容OpenAI的网关，请使用该供应商的适配器——例如，对于Anthropic风格的端点使用

@ai-sdk/anthropic

，对于OpenAI使用

@ai-sdk/openai

。仅

npm

值会变化；块的其余结构相同。

如果两个角色使用同一提供商的不同模型（例如主模型和低成本研究模型均使用提供商

kirocc

），请勿生成两个具有相同ID的提供商块——这会导致重复键。为该提供商生成一个块，并在其

models

对象下列出两个模型，如下所示：

json

"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 - Build the config fragment

步骤3 - 构建配置片段

Build a config FRAGMENT with this exact structure and save it to a temporary file (OS temp dir is fine). Do NOT write

~/.config/opencode/opencode.json

yourself - the installer script in Step 4 merges the fragment in deterministically. When running as the restricted Fusion build agent, delegate creation of the temporary fragment and the Step 4 installer command together in one sidekick task so build never needs direct filesystem access. In plan mode, stop after specifying the choices and tell the user to switch to build (or run the command themselves); plan must not execute the install. Replace the

<...>

placeholders with the user's choices. Model references are always

provider-id/model-id

. The JSON only assigns models - each role's mode, permissions, and prompt come from its agent file (Step 4), and the build agent's permission frontmatter is the core of Fusion and must not be loosened.

json

{
  "$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>" }
  }
}

Notes:

Keep
```
"subagent_depth": 2
```
. OpenCode 1.18.2+ defaults to
```
1
```
, which lets build start sidekick but prevents sidekick from starting its permitted read-only explore/research helper. The installer enforces a minimum of
```
2
```
and preserves a larger existing value.
Replace the two
```
"<...-provider-id>": { ... }
```
placeholder lines under
```
provider
```
with the ACTUAL provider block(s) you built in Step 2. If your main and sidekick share one provider, that is a single block (see Step 2 on merging models); if they use different providers, include one block each. The placeholder shape shown is not valid config on its own - it must be filled in.
opencode auto-loads every markdown file in
```
~/.config/opencode/agent/
```
as an agent definition: frontmatter supplies the role's
```
mode
```
and
```
permission
```
, and the body is its prompt. No
```
prompt
```
fields belong in opencode.json - Step 4 installs the files that carry them.
Backup and merge are the installer's job (Step 4): it backs up any existing config to
```
opencode.json.backup.<timestamp>
```
and deep-merges the fragment - your fragment wins on conflicting keys, everything else in the user's config is preserved. Never silently discard an existing config: if the user explicitly wants a clean overwrite instead of a merge, they should move the old
```
opencode.json
```
aside first.
Add
```
"vision": { "model": "<vision-provider>/<vision-model-id>" }
```
to the
```
agent
```
block ONLY if the user configured a vision role (main model lacks image input). Omit it otherwise.
OPTIONAL top-level hardening keys (documented opencode fields; add if the user wants a tighter, cheaper, more private local setup):
- ```
"small_model": "<cheap-provider>/<cheap-model-id>"
```
  - opencode uses a small model for background tasks like title generation; if unset it may fall back to a remote default. Pin it to one of the user's own cheap local models to keep everything on their providers.
- ```
"enabled_providers": ["<provider-a>", "<provider-b>"]
```
  - allowlist of providers to load; keeps the model picker deterministic and ignores any other credentials present.
- ```
"compaction": { "prune": true }
```
  - drops stale tool outputs when compacting context, which cuts main-agent token cost in a delegation-heavy Fusion flow.
- Per custom model, an optional
```
"limit": { "context": <n>, "output": <n> }
```
  inside the model block lets opencode track remaining context accurately (models on models.dev supply this automatically; custom local gateways do not). Use the real context/output window for that model; do not guess.

构建具有以下精确结构的配置片段，并保存到临时文件（系统临时目录即可）。请勿自行编写

~/.config/opencode/opencode.json

——步骤4中的安装程序会以确定的方式合并该片段。当作为受限制的Fusion build代理运行时，请将临时片段的创建和步骤4的安装程序命令一起委托给sidekick任务，这样build代理永远无需直接访问文件系统。在规划模式下，指定选择后停止操作，并告知用户切换到build模式（或自行运行命令）；规划模式不得执行安装操作。将

<...>

占位符替换为用户的选择。模型引用始终为

provider-id/model-id

。JSON仅分配模型——每个角色的模式、权限和提示词来自其代理文件（步骤4），build代理的权限前置内容是Fusion的核心，不得放宽。

json

{
  "$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
```
，该值允许build启动sidekick，但阻止sidekick启动其允许的只读explore/research助手。安装程序会强制执行最小值
```
2
```
，并保留更大的现有值。
将
```
provider
```
下的两个
```
"<...-provider-id>": { ... }
```
占位符行替换为步骤2中构建的实际提供商块。如果主代理和sidekick共享一个提供商，则为单个块（参见步骤2中的模型合并）；如果它们使用不同的提供商，则各包含一个块。所示的占位符格式本身不是有效的配置——必须填充完整内容。
opencode会自动加载
```
~/.config/opencode/agent/
```
中的每个markdown文件作为代理定义：前置内容提供角色的
```
mode
```
和
```
permission
```
，正文是其提示词。opencode.json中不应包含
```
prompt
```
字段——步骤4会安装承载这些内容的文件。
备份和合并是安装程序的职责（步骤4）：它会将现有配置备份到
```
opencode.json.backup.<timestamp>
```
，并深度合并片段——你的片段在键冲突时优先，用户配置中的其他内容会被保留。切勿静默丢弃现有配置：如果用户明确想要干净覆盖而非合并，他们应先将旧的
```
opencode.json
```
移至别处。
仅当用户配置了vision角色（主模型不支持图像输入）时，才在
```
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流程中降低主代理的token成本。
- 对于自定义模型，在模型块内可选添加
```
"limit": { "context": <n>, "output": <n> }
```
  ，让opencode准确跟踪剩余上下文（models.dev上的模型会自动提供该信息；自定义本地网关则不会）。使用该模型的实际上下文/输出窗口大小；请勿猜测。

Step 4 - Run the deterministic installer

步骤4 - 运行确定性安装程序

The skill bundles an installer at

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

(plain Node, no dependencies). It owns every mechanical step - timestamped backup, deep merge, atomic write, prompt-file copies, an undo manifest, and post-install validation - so none of that depends on improvised file operations. Its version-2 manifest stores the original bytes and permissions of every managed file, plus hashes of the exact installed state. Reapply and undo refuse before writing if the config or a managed file changed after installation; they never guess which content belongs to Fusion. Run it with the fragment from Step 3:

bash

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

```
--profile <name>
```
applies a bundled subscription profile (Step 0) as the base fragment; a
```
--config
```
fragment, when also given, overrides it key by key. Unknown profile names fail listing the available ones.
```
--roles
```
is normally omitted: the installer derives the list from the config - the core
```
build,plan,sidekick
```
plus every optional role the fragment or profile assigns a model (explore needs no file by design). An explicit
```
--roles
```
can add extra roles, but one that omits a role the config assigns a model is refused: a role with a model and no agent file would run without Fusion's permissions.
```
--extras commands,plugin
```
installs the optional slash commands and audit plugin described below. Add
```
claude
```
only when the user explicitly wants the Claude Code Pro/Max review bridge:
```
--extras commands,plugin,claude
```
.
Add
```
--dry-run
```
to print the full plan (backup name, merged keys, files) without writing anything - offer this if the user seems cautious. The plan also prints an
```
OVERRIDES:
```
line naming any top-level key whose current value the fragment would replace.
```
--adopt-config
```
is for reapplying over an
```
opencode.json
```
the user edited by hand since the last install. Without it that mismatch refuses, which would otherwise wedge reapply permanently - including a prompt-only refresh whose managed files are all intact. The merge folds the fragment into the CURRENT file, so hand edits survive; the flag only re-records the baseline hash. The manifest keeps the pre-install
```
originalContent
```
, so a later undo still restores the true pre-Fusion state. It deliberately does NOT excuse a modified managed prompt: that refusal protects a deliberate local customization from being overwritten.
The script refuses with exit 1 and changes nothing when validation or ownership checks fail, including invalid JSON/config shapes, unsafe paths, changed managed files, and invalid destination parents. It warns when a model references a provider that has no provider block.
If the agent running this skill cannot execute bash (for example the Fusion build agent's allowlist), delegate both the fragment creation and this exact command to the sidekick. In plan mode, switch to build or have the user run it. Use the manual fallback below only when Node is unavailable.

本技能在

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

中捆绑了一个安装程序（纯Node编写，无依赖）。它负责所有机械步骤——带时间戳的备份、深度合并、原子写入、提示文件复制、撤销清单以及安装后验证——因此无需依赖临时文件操作。其版本2清单存储每个受管文件的原始字节和权限，以及精确安装状态的哈希值。重新应用和撤销操作会在写入前检查配置或受管文件是否在安装后发生了更改；它们永远不会猜测哪些内容属于Fusion。使用步骤3中的片段运行它：

bash

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安装前的真实状态。它刻意不允许修改受管提示：该拒绝操作旨在保护故意的本地自定义不被覆盖。
当验证或所有权检查失败时，脚本会以退出码1拒绝并不做任何更改，包括无效的JSON/配置格式、不安全路径、已更改的受管文件以及无效的目标父目录。当模型引用的提供商没有提供商块时，它会发出警告。
如果运行本技能的代理无法执行bash（例如Fusion build代理的允许列表），请将片段创建和此精确命令一起委托给sidekick。在规划模式下，切换到build模式或让用户自行运行。仅当Node不可用时，才使用下方的手动回退方案。

Manual fallback - install the agent prompt files by hand

手动回退方案 - 手动安装代理提示文件

Only when Node is unavailable. Before merging or copying anything, make a timestamped backup of

opencode.json

and of every destination file that already exists, and record which destinations did not exist. Then copy the prompt files bundled with this skill into the global agent folder (one per role you configured).

<this-skill-dir>

is the directory this SKILL.md lives in - its bundled prompts are in the

agent/

subfolder next to this file. Every configured role except

explore

needs its agent file installed (explore is opencode's built-in read-only subagent and only gets a model in the JSON); in particular the sidekick DOES need its

agent/sidekick.md

file - its permissions and prompt come entirely from that file:

<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

(only if a vision role was configured)

These carry the full operating instructions and permissions for each role. Each subagent file's frontmatter sets its

mode

and

permission

; the files deliberately ship WITHOUT a

model

key, because markdown frontmatter overrides opencode.json on any key it sets - a model baked into the file would silently override the user's Step 3 choice. Models come only from opencode.json. Install only the files for the roles you configured - if the user skipped research/design/reviewer/vision, skip those.

仅当Node不可用时使用。在合并或复制任何内容之前，为

opencode.json

和每个已存在的目标文件创建带时间戳的备份，并记录哪些目标文件不存在。然后将本技能捆绑的提示文件复制到全局代理文件夹（每个已配置的角色对应一个文件）。

<this-skill-dir>

是本SKILL.md所在的目录——其捆绑的提示文件位于此文件旁边的

agent/

子文件夹中。除

explore

外，每个已配置的角色都需要安装其代理文件（explore是opencode内置的只读子代理，仅在JSON中设置模型即可）；特别是sidekick需要其

agent/sidekick.md

文件——其权限和提示词完全来自该文件：

<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

；这些文件刻意不包含

model

键，因为markdown前置内容会覆盖opencode.json中的任何键——文件中内置的模型会静默覆盖用户在步骤3中的选择。模型仅来自opencode.json。仅安装已配置角色的文件——如果用户跳过了research/design/reviewer/vision，则跳过这些文件。

Step 4b - Optional commands and plugins

步骤4b - 可选命令和插件

Four optional pieces ship next to the skill. The installer groups the two commands under

commands

, the audit plugin under

plugin

, and the Claude Code bridge under

claude

(manual copy paths below if the script cannot run):

Slash command: copy
```
<this-skill-dir>/commands/fusion-setup.md
```
->
```
~/.config/opencode/commands/fusion-setup.md
```
(note the PLURAL
```
commands/
```
directory). This gives a discoverable
```
/fusion-setup
```
command that launches this setup flow; it accepts optional arguments for a targeted reconfigure.
Status command: copy
```
<this-skill-dir>/commands/fusion-status.md
```
->
```
~/.config/opencode/commands/fusion-status.md
```
. This gives a
```
/fusion-status
```
health check that verifies the setup is installed, loaded, and enforcing (live tool schema, config on disk, installed agent files, and the optional Claude bridge). It only reports - it changes nothing.
Audit plugin: copy
```
<this-skill-dir>/plugins/fusion-audit.js
```
->
```
~/.config/opencode/plugins/fusion-audit.js
```
(PLURAL
```
plugins/
```
). It logs the delegation tree (subagent spawns and edit/write/apply_patch/task tool calls) and aggregates per-agent token usage per session via opencode's logger for auditing - the raw numbers behind "did Fusion actually save money?". It is observational only - it cannot see the calling agent, so it does not enforce anything; permissions do the enforcing. Skip it if the user does not want extra logging.
Claude Code bridge: copy
```
<this-skill-dir>/plugins/fusion-claude.js
```
->
```
~/.config/opencode/plugins/fusion-claude.js
```
. Also merge
```
"fusion_claude_*": "deny"
```
into the top-level
```
permission
```
map. The build and plan agent files contain the two exact allows that override this global deny. If the existing top-level permission is shorthand, preserve it as
```
"*"
```
before adding the Claude deny. This bridge is deliberately review-only and optional. Note that re-running the installer without the
```
claude
```
extra does not remove a previously installed bridge - the plugin file, the global deny, and the build/plan allows all stay in place; removal is
```
install.js undo
```
(or deleting the plugin file and the deny by hand).

本技能附带四个可选组件。安装程序将两个命令归为

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/
```
）。它记录委托树（子代理生成和edit/write/apply_patch/task工具调用），并通过opencode的日志聚合每个会话中每个代理的token使用情况，用于审核——回答“Fusion是否真的节省了成本”背后的原始数据。它仅用于观察——无法看到调用代理，因此不执行任何强制操作；权限层负责强制实施。如果用户不想要额外日志，可跳过该插件。
Claude Code桥接工具：复制
```
<this-skill-dir>/plugins/fusion-claude.js
```
->
```
~/.config/opencode/plugins/fusion-claude.js
```
。同时将
```
"fusion_claude_*": "deny"
```
合并到顶层
```
permission
```
映射中。build和plan代理文件包含两个精确的允许规则，会覆盖该全局拒绝。如果现有顶层权限是简写形式，请在添加Claude拒绝规则前保留
```
"*"
```
。该桥接工具刻意仅用于审核，且为可选组件。注意：重新运行安装程序时不带
```
claude
```
附加组件不会移除已安装的桥接工具——插件文件、全局拒绝规则和build/plan允许规则都会保留；移除需使用
```
install.js undo
```
（或手动删除插件文件和拒绝规则）。

Step 5 - Validate and finish

步骤5 - 验证并完成

The installer validates automatically (it re-parses the written config and checks every installed file exists, failing loudly otherwise). If you used the manual fallback instead, do the same checks yourself: parse
```
~/.config/opencode/opencode.json
```
, and confirm every agent prompt file you installed exists under
```
~/.config/opencode/agent/
```
(build and sidekick at minimum).
If you installed commands or plugins manually, confirm the selected files exist under
```
~/.config/opencode/commands/
```
and
```
~/.config/opencode/plugins/
```
. For the Claude bridge, also confirm the top-level
```
fusion_claude_*
```
deny and the exact build/plan allows are present.
If any provider block references
```
{env:VAR}
```
, confirm with the user that the variable is set in the environment they launch opencode from - using a presence-only check that never prints the secret:
```
[ -n "$VAR" ] && echo set || echo missing
```
in bash/zsh,
```
if defined VAR (echo set) else (echo missing)
```
in cmd. Do NOT suggest
```
echo $VAR
```
- that prints the actual credential into the terminal (and into the transcript if run through an agent). An unset variable becomes an empty string and shows up later as auth errors.
Tell the user to fully quit and restart opencode - config is loaded once at startup and is not hot-reloaded. After restart, the status bar should show the main model on the Build agent. If the Claude bridge was installed, call
```
fusion_claude_status
```
; it reports readiness without returning account identity or credential data.
Ask which toolchains the user works in. The bundled verification allowlists assume a Node/JavaScript project, and on any other stack the shipped entries match nothing the user actually runs - so the main agent cannot verify its own work and gets denied on the command it should be running. The subsets differ per role:
```
build.md
```
allows
```
npm run lint*
```
,
```
npm test*
```
,
```
npm run build*
```
,
```
npx tsc --noEmit*
```
, and
```
npx vitest run*
```
;
```
plan.md
```
has the same list without
```
npm run build*
```
;
```
reviewer.md
```
allows only
```
npm run lint*
```
,
```
npm test*
```
, and
```
npx vitest run*
```
. Check the file before telling the user to change an entry in it. Point them at README's "Adjust the bash allowlist" section for the per-stack tools (
```
pytest
```
/
```
ruff check
```
for Python,
```
cargo test
```
/
```
cargo clippy
```
for Rust,
```
go test
```
/
```
go vet
```
for Go,
```
make test
```
/
```
make lint
```
for Make-driven builds). Three things to say out loud: keep
```
"*": "deny"
```
first; prefer an exact pattern over a trailing
```
*
```
, because
```
*
```
matches the whole rest of the command and a broad
```
"ruff check*"
```
also permits the file-rewriting
```
ruff check --fix
```
and
```
--add-noqa
```
(pin the command the project actually runs where you can, since enumerating every writing flag never finishes); and if you do need a broad allow, put each narrowing deny after it, because opencode resolves overlapping patterns by last-match-wins. These prompts are global, not per project, so a user who works across stacks should add their entries alongside the JS ones rather than replacing them. The git half of the allowlist needs no change.

安装程序会自动进行验证（它会重新解析写入的配置并检查所有已安装文件是否存在，否则会报错）。如果使用了手动回退方案，请自行执行相同检查：解析
```
~/.config/opencode/opencode.json
```
，并确认每个已安装的代理提示文件都存在于
```
~/.config/opencode/agent/
```
下（至少包含build和sidekick）。
如果手动安装了命令或插件，请确认所选文件存在于
```
~/.config/opencode/commands/
```
和
```
~/.config/opencode/plugins/
```
下。对于Claude桥接工具，还需确认顶层
```
fusion_claude_*
```
拒绝规则和精确的build/plan允许规则已存在。
如果任何提供商块引用了
```
{env:VAR}
```
，请与用户确认该变量已在启动opencode的环境中设置——使用仅检查存在性的命令，切勿打印密钥：在bash/zsh中使用
```
[ -n "$VAR" ] && echo set || echo missing
```
，在cmd中使用
```
if defined VAR (echo set) else (echo missing)
```
。切勿建议使用
echo $VAR
——这会将实际凭证打印到终端（如果通过代理运行，还会记录到 transcript 中）。未设置的变量会变为空字符串，随后会表现为认证错误。
告知用户完全退出并重启opencode——配置仅在启动时加载一次，不支持热重载。重启后，状态栏应显示Build代理使用的主模型。如果安装了Claude桥接工具，请调用
```
fusion_claude_status
```
；它会报告就绪状态，不会返回账户身份或凭证数据。
询问用户使用的工具链。捆绑的验证允许列表假设是Node/JavaScript项目，在其他栈上，附带的条目与用户实际运行的内容不匹配——因此主代理无法验证自己的工作，会在运行应执行的命令时被拒绝。各角色的允许列表子集不同：
```
build.md
```
允许
```
npm run lint*
```
、
```
npm test*
```
、
```
npm run build*
```
、
```
npx tsc --noEmit*
```
和
```
npx vitest run*
```
；
```
plan.md
```
的列表与build相同，但不含
```
npm run build*
```
；
```
reviewer.md
```
仅允许
```
npm run lint*
```
、
```
npm test*
```
和
```
npx vitest run*
```
。在告知用户修改条目之前，请先检查文件。引导他们查看README的“Adjust the bash allowlist”部分，获取针对各栈的工具（Python使用
```
pytest
```
/
```
ruff check
```
，Rust使用
```
cargo test
```
/
```
cargo clippy
```
，Go使用
```
go test
```
/
```
go vet
```
，基于Make的构建使用
```
make test
```
/
```
make lint
```
）。需明确告知用户三点：保持
```
"*": "deny"
```
在首位；优先使用精确模式而非后缀
```
*
```
，因为
```
*
```
会匹配命令的剩余部分，宽泛的
```
"ruff check*"
```
也会允许修改文件的
```
ruff check --fix
```
和
```
--add-noqa
```
（尽可能固定项目实际运行的命令，因为枚举所有写入标志永远无法完成）；如果确实需要宽泛的允许规则，请在其后添加每个缩小范围的拒绝规则，因为opencode会按最后匹配优先的原则解析重叠模式。这些提示是全局的，而非按项目设置，因此跨栈工作的用户应在JS条目旁添加自己的条目，而非替换它们。git相关的允许列表无需修改。

Reconfiguring later

后续重新配置

To change a model, build a small fragment with

agent.<role>.model

(and a

provider

block if the new model uses a new provider), then rerun the installer and restart opencode. For a profile-based install, rerun with the same

--profile <name>

plus the small

--config

delta. Reapply preserves the original pre-Fusion baseline and keeps all previously managed files recorded for a complete undo.

Going through the installer is preferred because it keeps the manifest accurate, but editing

opencode.json

in place is supported and does not lose anything: the next reapply refuses once so the mismatch is visible, and

--adopt-config

accepts the edited file as the new baseline while still merging the fragment into it. Editing an installed

agent/*.md

is different - that refusal has no override, because silently overwriting a deliberately customized prompt is worse than stopping. Restore the bundled copy of that file if you want the installer to manage it again.

要更改模型，构建一个包含

agent.<role>.model

的小片段（如果新模型使用新提供商，还需包含

provider

块），然后重新运行安装程序并重启opencode。对于基于配置文件的安装，使用相同的

--profile <name>

加上小的

--config

差异片段重新运行。重新应用会保留原始的Fusion安装前基线，并记录所有先前的受管文件以支持完整撤销。

优先使用安装程序，因为它能保持清单的准确性，但也支持直接编辑

opencode.json

：下次重新应用时会拒绝一次以显示不匹配，

--adopt-config

会接受编辑后的文件作为新基线，同时仍将片段合并到其中。编辑已安装的

agent/*.md

则不同——该拒绝操作没有覆盖选项，因为静默覆盖故意自定义的提示比停止操作更糟糕。如果希望安装程序再次管理该文件，请恢复其捆绑副本。

Undoing Fusion

撤销Fusion

Run the bundled undo. It restores the exact pre-install config and every destination that Fusion replaced, removes only destinations Fusion originally created, keeps every timestamped config backup, and refuses before changing anything if the installed state was edited afterward or the manifest is unsafe:

bash

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

Manual fallback after a manual install (no Node):

Restore
```
opencode.json
```
and every destination that existed before installation from the backups made during the manual install.
For destinations recorded as newly created, remove them only if they are still byte-for-byte identical to the bundled file that was installed. If any file changed, leave it in place and report the conflict instead of deleting user work.
Apply the same restore-or-remove rule to optional commands and plugins.
Tell the user to restart opencode - it falls back to its built-in build/plan agents.

For an automatic install when Node is temporarily unavailable, wait until Node is available and use the manifest-driven undo. If an automatic manifest is missing, the timestamped files recover only

opencode.json

; do not remove prompts or extras unless independent backups or byte-for-byte ownership evidence prove they are still Fusion-owned. Confirm with the user before deleting anything, and never delete the backups themselves.

运行捆绑的撤销命令。它会恢复安装前的精确配置和Fusion替换的每个目标，仅移除Fusion最初创建的目标，保留所有带时间戳的配置备份，并在安装状态后续被编辑或清单不安全时拒绝更改任何内容：

bash

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

手动安装后的手动回退方案（无Node）：

从手动安装期间创建的备份中恢复
```
opencode.json
```
和安装前已存在的每个目标。
对于记录为新建的目标，仅当它们仍与安装的捆绑文件完全相同时才移除。如果任何文件已更改，请保留并报告冲突，切勿删除用户的工作成果。
对可选命令和插件应用相同的恢复或移除规则。
告知用户重启opencode——它会回退到内置的build/plan代理。

对于自动安装但Node暂时不可用的情况，请等待Node可用后使用基于清单的撤销命令。如果自动清单丢失，带时间戳的文件仅能恢复

opencode.json

；除非有独立备份或字节级所有权证据证明它们仍属于Fusion，否则请勿删除提示或附加组件。删除任何内容前请与用户确认，切勿删除备份本身。