fusion-setup

Fusion 配置

此技能通过写入用户的全局 opencode 配置来配置 Fusion Agent 团队（一个主 Agent、一个搭档执行器、一个探索搜索器，以及可选的专家），配置文件位于 ~/.config/opencode/（Windows 上为：%USERPROFILE%\.config\opencode\）。无需克隆任何代码仓库。

如果 XDG_CONFIG_HOME 已设置且非空，opencode 会将该目录解析为 $XDG_CONFIG_HOME/opencode/；否则回退到 ~/.config/opencode/。下文中的每个 ~/.config/opencode/... 路径都指该解析后的目录。第 4 步中的捆绑安装程序会自行处理路径，因此常规流程无需特殊处理；只有第 4b 步中的手动备用方案和第 5 步中的验证需要你手动解析路径。在 XDG_CONFIG_HOME 不同的机器上安装到 ~/.config/opencode/，会写入 opencode 永远不会读取的目录树——安装看似成功，但 Fusion 实际上不会加载。

Fusion 是什么

Fusion 将工作分配给权限不对称的 Agent：

• build（主 Agent、主角色）：使用能力强的模型进行规划、判断和审查。它不能编辑文件、搜索代码库或运行任意 Shell 命令。它只能通过 task 工具委派给搭档来修改文件。
• plan（主角色）：规划模式——与 build 使用同一个规划核心。它会生成经过审查的计划并委派探索任务，但不会执行；切换到 build 后即可执行计划。它会覆盖 opencode 内置的规划 Agent，使规划模式始终了解 Fusion。
• sidekick（子 Agent）：使用成本较低、速度较快的模型，拥有完整的 edit 和广泛的 bash 访问权限（为纵深防御，禁止直接 git commit/git push 及常见包装命令——提交仍由主 Agent 负责）。它会执行主 Agent 交给它的精确规格说明。
• explore（子 Agent）：使用低成本模型，只读探索代码库。
• research（子 Agent）：只读外部调研——网页搜索和文档。没有编辑权限。
• design（子 Agent）：前端/UI 实现。加载设计技能、编辑文件并运行开发/构建工具。
• reviewer（子 Agent）：在实施前评审计划，并在提交前审查差异（正确性、范围、安全性）。仅有只读权限以及 lint/测试权限；没有编辑权限。
• vision（子 Agent）：读取主模型无法查看的图像/屏幕截图，并以文本形式汇报。仅当主模型不支持图像输入时才需要。

可以把代码仓库看作一个角色目录：核心角色（build/plan/sidekick/explore）是必需的，其余角色则是可选组件，仅在工作流需要时安装。research/design/reviewer/vision 专家角色均为可选。每个角色的模型可以独立选择——这正是使用 Fusion 的一个重要原因：可以为 design 选用你最喜欢的设计模型，并为 reviewer 选用另一个模型。

这种不对称性由权限层强制执行，而非依赖约定。第 4 步安装捆绑 Agent 文件时，必须保留其完全一致的权限 frontmatter，Fusion 才能正常工作。

步骤 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 标志：安装程序会从配置文件推导角色列表，因此配置文件为其指定模型的每个角色也都会获得带权限的 Agent 文件。

4. 若要更改一两个选项，保留 --profile <name>，并添加 --config <fragment.json>，其中只包含差异（例如不同的 agent.reviewer.model，以及仅在该模型的提供商不属于配置文件时才添加提供商区块）。片段的优先级高于配置文件。无法通过覆盖移除配置文件指定的可选角色——请改用自定义访谈（步骤 1-4），且不要使用 --profile。

适用时值得提及的注意事项：opencode-zen-free 包含 vision 角色，因为其主模型无法读取图像，而其他配置文件优先使用可直接读取图像的模型；opencode-zen-free 使用免费时段模型，根据 OpenCode 政策，这些模型的提示词可能会用于训练——提醒用户不要在其中处理敏感代码；单一供应商的 chatgpt 配置文件会让所有角色使用同一家供应商，因此其 reviewer 与 build 的区别在于模型（GPT-5.6 Terra），而不是供应商——有第二家提供商的用户仍可能想覆盖 reviewer，以实现真正的跨供应商审查；github-copilot 默认将主模型设为 Claude Sonnet 5，以合理控制额度成本——想要最高质量的用户可以将 build 覆盖为 github-copilot/claude-opus-5（每个 token 的计费高得多）。这里刻意不提供 Claude Pro/Max 供应商配置文件。订阅登录不能用作 agent.build.model。如果用户想要有限度地集成 Claude Pro/Max，可提供下方可选的 Claude Code 审查桥接方案。订阅中的模型阵容会轮换——如果配置文件中的模型报未知错误，说明 ID 可能已变更；请改用自定义访谈并说明情况。

通过 Claude Code 可选地使用 Claude Pro/Max 进行评审

如果用户要求使用 Claude 订阅 OAuth，请保留另一个常规 OpenCode 提供方或配置文件作为构建模型，并提供 claude 附加项。它会安装一个本地 OpenCode 插件，其中包含两个自定义工具：一个经过净化的就绪状态检查工具，以及一个无状态的计划评审工具。只有构建 Agent 和计划 Agent 可以调用它们。

该桥接会以打印模式调用 Anthropic 官方 claude CLI。它不会读取凭据存储、提取 OAuth 令牌、将令牌放入 opencode.json，也不会将 Claude 暴露为 OpenCode 模型。它会验证 claude auth status 报告的是第一方 Pro 或 Max 登录；从子进程中移除 API 密钥和第三方路由环境变量；默认使用高强度的 Claude Opus 5（评审工具允许每次调用时指定可选的完整 claude-* 模型 ID，以及 low、medium、high、xhigh 或 max 强度）；禁用工具和自定义项；通过 stdin 发送评审数据包；并禁用会话持久化。它会从中立的临时目录运行 CLI，遵循会话取消操作，并且即使权限尚未生效，其工具也会拒绝构建 Agent 和计划 Agent 以外的调用方。

请用户安装 Claude Code，并直接使用 claude auth login 进行身份验证；绝不要要求他们粘贴令牌。在 Windows 上，他们需要原生 Claude Code 版本（安装脚本或 claude install），而不是 npm 垫片——该桥接会在不使用 shell 的情况下启动 claude。然后在第 4 步的附加项中加入 claude，例如 --extras commands,plugin,claude。不要默认启用此功能。Anthropic 表示，订阅用量旨在用于其原生应用，包括 Claude Code；第三方工具访问可能会酌情允许，也可能会计入用量额度。应将其描述为可选的兼容桥接，而非有保证的订阅权益或 API 替代方案。

如果用户没有这些订阅，或者希望完全掌控每一项选择，请继续执行第 1 步。

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

询问用户每个角色要使用哪个模型。不要自行假设；让用户选择自己的提供商和模型。收集以下信息：

1. 主模型／构建模型（能力强的模型，例如 Opus／GPT 级别的模型）。
2. 助手模型（快速、成本较低的编码模型）。
3. 探索模型（成本较低；可以与助手模型相同）。
4. 研究模型（用于只读的外部研究；能力可靠的通用模型）。
5. 设计模型（用于前端／UI 工作；选择你认为设计能力最强的模型）。
6. 审核模型（用于审查计划并审计差异；通常是能力较强的模型，也可以刻意选择与主模型不同的模型）。
7. 视觉模型（用于读取图像）——仅当用户的主模型／构建模型不支持图像输入时才询问。大多数前沿模型都能直接读取图像，因此除非主模型不支持，否则跳过此问题。视觉模型必须支持图像输入。

角色 4-7 是可选的按需组件。如果用户只需要核心的构建／计划／助手／探索角色，就跳过其他角色——但要向用户介绍这些选项，因为为不同的专家角色选择不同模型是使用 Fusion 的一个重要原因。plan Agent 会通过已安装的 agent/plan.md（步骤 4）激活，并覆盖 opencode 内置的 plan Agent——它会复用主模型／构建模型，无需在 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。主模型支持图像输入时，就不需要单独的视觉 Agent。

上面的模板展示了兼容 OpenAI 的配置形式（@ai-sdk/openai-compatible）。如果提供商是原生厂商，而不是兼容 OpenAI 的网关，请改用该厂商的适配器——例如，Anthropic 风格的端点使用 @ai-sdk/anthropic，OpenAI 则使用 @ai-sdk/openai。只需修改 npm 值，其余配置块结构保持不变。

如果两个角色使用同一提供商的不同模型（例如，主模型和成本较低的研究模型都使用提供商 kirocc），不要为同一个 id 输出两个提供商配置块——这会导致键重复。应为该提供商输出一个配置块，并在其 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" }
  }
}

步骤 3 - 构建配置片段

构建一个具有以下精确结构的配置片段，并将其保存到临时文件中（操作系统临时目录即可）。不要自行写入 ~/.config/opencode/opencode.json——第 4 步的安装脚本会以确定性的方式合并该片段。作为受限 Fusion 构建 Agent 运行时，请在同一个 sidekick 任务中一并委派创建临时片段和执行第 4 步的安装命令，这样构建过程就无需直接访问文件系统。处于计划模式时，在指定选项后停止，并告知用户切换到构建模式（或自行运行命令）；计划模式不得执行安装。将 <...> 占位符替换为用户的选项。模型引用始终采用 provider-id/model-id 格式。JSON 只分配模型——每个角色的模式、权限和提示词都来自其 Agent 文件（第 4 步），而构建 Agent 的权限 frontmatter 是 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，这允许 build 启动 sidekick，却会阻止 sidekick 启动其获准使用的只读 explore/research 助手。安装程序会强制将最小值设为 2，并保留更大的现有值。
• 将 provider 下的两个 "<...-provider-id>": { ... } 占位行替换为你在第 2 步中构建的实际 provider 块。如果 main 和 sidekick 共用一个 provider，则只需一个块（参见第 2 步中合并模型的说明）；如果它们使用不同的 provider，则每个都要包含一个块。这里显示的占位结构本身不是有效配置，必须填入实际内容。
• opencode 会自动将 ~/.config/opencode/agent/ 中的每个 markdown 文件加载为 Agent 定义：frontmatter 提供角色的 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 会使用小模型处理标题生成等后台任务；如果未设置，可能会回退到远程默认模型。将其固定为用户自己的廉价本地模型之一，确保所有任务都使用其 provider。
  • "enabled_providers": ["<provider-a>", "<provider-b>"] - 仅允许加载列出的 provider；这能让模型选择器保持确定性，并忽略任何其他现有凭据。
  • "compaction": { "prune": true } - 压缩上下文时会删除过时的工具输出，从而降低大量委派的 Fusion 工作流中主 Agent 的 token 成本。
  • 对于每个自定义模型，可在模型块中添加可选的 "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 可以添加其他角色，但如果遗漏了配置中指定了模型的角色，安装程序会拒绝执行：有模型却没有 Agent 文件的角色会在没有 Fusion 权限的情况下运行。
• --extras commands,plugin 会安装下文介绍的可选斜杠命令和审计插件。只有当用户明确需要 Claude Code Pro/Max 审查桥接时，才添加 claude：--extras commands,plugin,claude。
• 添加 --dry-run 可打印完整计划（备份名称、合并的键、文件），但不进行任何写入——如果用户似乎比较谨慎，可以提供此选项。计划还会打印一行 OVERRIDES:，列出片段将替换其当前值的顶层键。
• --adopt-config 用于重新应用到用户自上次安装后手动编辑过的 opencode.json。不使用该选项时，此不匹配会导致拒绝执行，从而使重新应用永久受阻——即使只是刷新提示词且所有受管理文件都完好无损也是如此。合并会将片段并入当前文件，因此手动编辑会保留；此标志只会重新记录基准哈希。清单会保留安装前的 originalContent，因此之后撤销时仍会恢复到 Fusion 介入前的真实状态。该选项不会放过已修改的受管理提示词：此拒绝行为会保护有意进行的本地自定义，避免其被覆盖。
• 当验证或所有权检查失败时，脚本会以退出码 1 拒绝执行且不做任何更改，失败情况包括无效的 JSON/配置结构、不安全的路径、受管理文件已更改，以及无效的目标父目录。如果模型引用的提供方没有对应的提供方区块，脚本会发出警告。
• 如果运行此技能的 Agent 无法执行 bash（例如 Fusion 构建 Agent 的允许列表限制），请将片段创建和这条确切命令都委托给 sidekick。在计划模式下，切换到 build 模式或让用户运行命令。只有在 Node 不可用时，才使用下文的手动备用方案。

手动备用方案——手动安装 Agent 提示词文件

仅在 Node 不可用时使用。合并或复制任何内容前，请为 opencode.json 以及每个已存在的目标文件创建带时间戳的备份，并记录哪些目标文件原本不存在。然后将此技能随附的提示词文件复制到全局 Agent 文件夹（每个已配置的角色对应一个文件）。<this-skill-dir> 是此 SKILL.md 所在的目录——随附的提示词位于此文件旁边的 agent/ 子文件夹中。除 explore 外，每个已配置的角色都需要安装其 Agent 文件（explore 是 opencode 内置的只读子 Agent，只需在 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 角色时）

这些文件包含每个角色的完整操作说明和权限。每个子 Agent 文件的 frontmatter 都会设置其 mode 和 permission；这些文件特意不包含 model 键，因为 Markdown frontmatter 会覆盖其设置的任何 opencode.json 键——若在文件中预设模型，就会悄无声息地覆盖用户在第 3 步中的选择。模型只取自 opencode.json。只安装已配置角色对应的文件——如果用户跳过了 research/design/reviewer/vision，就跳过这些文件。

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

此技能旁还提供四个可选组件。安装程序会将两个命令归入 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 健康检查，用于验证设置是否已安装、加载并生效（实时工具架构、磁盘上的配置、已安装的 Agent 文件，以及可选的 Claude 桥接）。它只会报告，不会更改任何内容。
• 审计插件：将 <this-skill-dir>/plugins/fusion-audit.js 复制到 ~/.config/opencode/plugins/fusion-audit.js（复数 plugins/）。它会通过 opencode 的日志记录器记录委派树（子 Agent 的启动，以及 edit/write/apply_patch/task 工具调用），并按会话汇总每个 Agent 的 token 使用量，以供审计——这些原始数字可以回答“Fusion 到底有没有省钱？”。此插件仅用于观察，无法看到调用方 Agent，因此不会强制执行任何操作；强制执行由权限负责。如果用户不希望增加日志记录，请跳过此插件。
• Claude Code 桥接：将 <this-skill-dir>/plugins/fusion-claude.js 复制到 ~/.config/opencode/plugins/fusion-claude.js。还需将 "fusion_claude_*": "deny" 合并到顶层 permission 映射中。build 和 plan Agent 文件中包含两个精确的允许项，可覆盖此全局拒绝规则。如果现有顶层 permission 使用简写形式，请先将其保留为 "*"，再添加 Claude 拒绝规则。此桥接专为审查而设计，且为可选项。请注意，不带 claude 扩展重新运行安装程序不会移除之前安装的桥接——插件文件、全局拒绝规则以及 build/plan 允许项都会保留；要移除它们，请运行 install.js undo（或手动删除插件文件和拒绝规则）。

步骤 5 - 验证并完成

1. 安装程序会自动验证（重新解析写入的配置，并检查每个已安装的文件是否存在；否则会明确报错）。如果你改用手动备用方案，则需要自行执行相同的检查：解析 ~/.config/opencode/opencode.json，并确认你安装的每个 Agent 提示词文件都存在于 ~/.config/opencode/agent/ 下（至少包括 build 和 sidekick）。
2. 如果你手动安装了命令或插件，请确认选定的文件存在于 ~/.config/opencode/commands/ 和 ~/.config/opencode/plugins/ 下。对于 Claude 桥接，还要确认顶层的 fusion_claude_* deny 规则和精确的 build/plan allow 规则均已添加。
3. 如果任何 provider 区块引用了 {env:VAR}，请向用户确认：他们启动 opencode 时所用的环境中已设置该变量。使用仅检查变量是否存在且绝不打印密钥的方式：在 bash/zsh 中运行 [ -n "$VAR" ] && echo set || echo missing，在 cmd 中运行 if defined VAR (echo set) else (echo missing)。不要建议运行 echo $VAR——这会把实际凭据打印到终端（如果通过 Agent 运行，也会出现在对话记录中）。未设置的变量会变成空字符串，之后会导致身份验证错误。
4. 告知用户完全退出并重启 opencode——配置只会在启动时加载，不会热重载。重启后，状态栏应在 Build Agent 上显示主模型。如果已安装 Claude 桥接，请调用 fusion_claude_status；它会报告就绪状态，但不会返回账户身份或凭据数据。
5. 询问用户使用哪些工具链。随附的验证 allowlist 默认适用于 Node/JavaScript 项目；如果使用其他技术栈，提供的条目就不会匹配用户实际运行的任何命令，因此主 Agent 无法验证自己的工作，并会在它应该运行的命令上遭到拒绝。不同角色的子集各不相同：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 的“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（尽可能指定项目实际运行的命令，因为永远无法列举完所有会写入文件的标志）；如果确实需要宽泛的 allow 规则，请将每条用于收窄范围的 deny 规则放在它之后，因为 opencode 会按最后匹配的规则处理重叠模式。这些提示词是全局的，而非针对单个项目，因此同时使用多种技术栈的用户应将相应条目添加到 JS 条目旁边，而不是替换它们。allowlist 中的 git 部分无需更改。

稍后重新配置

要更换模型，请使用 agent.<role>.model（如果新模型使用新的提供商，还需添加 provider 块）构建一个小片段，然后重新运行安装程序并重启 opencode。对于基于配置文件的安装，请使用相同的 --profile <name> 和较小的 --config 增量重新运行。重新应用会保留原始的 Fusion 前基线，并继续记录所有先前由其管理的文件，以便完整撤销。

建议通过安装程序进行操作，因为这样可以确保清单准确；但直接编辑 opencode.json 也受支持，不会造成任何丢失：下次重新应用时会拒绝一次，让不一致情况显现出来；而 --adopt-config 会将编辑后的文件作为新基线接受，同时仍将片段合并到其中。编辑已安装的 agent/*.md 则不同——对此类情况没有覆盖选项，因为停止操作也好过悄悄覆盖刻意定制的提示词。如果希望安装程序重新管理该文件，请恢复其捆绑版本。

撤销 Fusion

运行捆绑的撤销程序。它会恢复精确的安装前配置和 Fusion 替换的每个目标，只移除 Fusion 最初创建的目标，保留所有带时间戳的配置备份；如果安装后的状态已被编辑，或清单不安全，它会在进行任何更改前拒绝执行：

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

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

1. 从手动安装期间创建的备份中恢复 opencode.json 以及安装前已存在的每个目标。
2. 对于记录为新建的目标，仅当其内容与已安装的捆绑文件逐字节完全一致时才将其删除。如果任何文件发生了更改，请保留该文件并报告冲突，而不是删除用户的工作成果。
3. 对可选命令和插件应用相同的恢复或删除规则。
4. 告知用户重启 opencode——它会回退到内置的 build/plan Agent。

如果 Node 暂时不可用，且是通过自动方式安装的，请等到 Node 可用后使用由清单驱动的撤销程序。如果自动安装的清单缺失，带时间戳的文件只能恢复 opencode.json；除非独立备份或逐字节的所有权证据证明提示词或额外文件仍归 Fusion 所有，否则不要将其删除。删除任何内容前都要征得用户确认，并且绝不要删除备份本身。