OpenCode Plugins 指南：安装前先做 7 个检查

只有当能力需要可复用代码、可打包分发或稳定集成点时，才应该创建或安装 OpenCode plugin。如果只是让 agent 记住审查规则，用 skill；如果是用户显式触发的发布流程，用 command；如果要接外部服务或工具，用 MCP。

好的插件能减少分散脚本、重复提示词和手工步骤；差的插件会把密钥、宽泛权限、一次性偏好或危险操作藏起来。判断标准不是“相关”，而是它是否让工作流更可维护。

插件打包行为，skill 打包指导，command 暴露可触发任务，agent 隔离角色和上下文，hook 在生命周期点运行，MCP 暴露外部工具。每种方式都应该有清晰职责。

边界混乱会让排障变慢：问题可能来自提示词、插件代码、hook 副作用、MCP 连接、模型提供商或 command 包装。把选择原因写在仓库里，后续才能快速禁用一层来定位问题。

先从工作流问题出发，而不是从热门列表出发。插件应该减少重复人工步骤、提升验证稳定性，或暴露团队已经信任的能力。不要因为“看起来自动化”就安装。

逐项检查维护者、发布记录、权限、配置面和失败模式。需要广泛文件访问、命令执行、网络调用或密钥处理的插件，必须比只格式化输出的插件更谨慎。

推荐顺序是来源、审查、安装、测试、保留。先确认官方或维护者来源，再看插件会碰哪些文件、命令、provider 或网络路径。先在小型一次性仓库测试，再进入真实项目。

只有当插件确实改善流程且结果仍然容易解释时才保留。保留后，在项目配置旁写明它做什么、如何更新、如何禁用。

`opencode hooks` 与插件相关，但不应被混成同一个概念。Hooks 适合时机很重要的场景：编辑前、生成 diff 后、运行命令前或验证后。

Hook 要窄。一个 hook 同时做策略、格式化、部署和通知，会很难排查。如果它会改文件、调用外部服务或阻断流程，必须显式说明。

`opencode sdk` 往往意味着围绕 OpenCode 构建更深的内部集成，而不是装一个小插件。只有当你要维护内部开发平台、共享自动化包或公司系统桥接时，SDK 才更合适。

代价是所有权：测试、版本、发布说明、上游变化后的修复都要有人负责。多数团队应先从 skill、command、hook 或 MCP 开始。

安装插件后 OpenCode 行为异常时，不要先改提示词。按层禁用：plugin、hook、command wrapper、项目 skill、全局 skill、MCP server、provider 设置，并用同一小任务复测。

记录插件变更日志：名称、版本、来源、安装原因、首次测试碰到的文件和回滚方式。这个习惯能避免插件层变成无人理解的隐藏自动化。