OpenCode 的设计很清楚：skill 是 terminal coding agent 可按需加载的 reusable instructions。它不会假设所有 skill 都应该自动进入上下文，而是让 agent 先看到可用 skill 列表，再通过 native skill tool 加载完整内容。

OpenCode 支持标准 SKILL.md 文件夹，也兼容 .claude/skills 和 .agents/skills。这让它成为一个很好的“生态收敛”证据：同一个 skill 外壳正在从 Claude/Codex 扩散到 terminal agent。

OpenCode 要回答的是：在终端 coding agent 里，怎样既发现可复用 workflow，又不让每个 skill 无条件污染上下文。

它的关键机制是 native skill tool。模型先在工具描述中看到 <available_skills>，包括 skill name 和 description；当任务匹配时再调用 skill({ name }) 读取正文。这是 progressive disclosure 在 terminal agent 里的直接实现。

另一个关键机制是 permission.skill。OpenCode 可以按 pattern 把 skill 设置为 allow、deny、ask，也可以按 agent override。这个设计说明 OpenCode 不把 skill 当成普通 Markdown，而是当成会影响 agent 行为边界的能力入口。

Terminal agent 的上下文和权限压力都很真实。用户可能同时有很多本地 skill：release、debug、review、docs、incident、infra。全部塞进系统提示会浪费 token，也会让模型误触发。用 skill tool 延迟加载，可以让 skill 既可发现，又不常驻。

权限层也合理：某些 skill 可能涉及公司内部流程、危险命令或敏感工具。deny 隐藏，ask 让用户确认，allow 直接加载，这比把“请小心使用”写在正文里更可靠。

• .opencode/skills、~/.config/opencode/skills 等发现路径。
• permission.skill 的 allow/deny/ask 策略。
• OpenCode agent override。
• native skill tool 的调用方式。
• .opencode/commands 与 .opencode/agents 的 terminal-specific 边界。

OpenCode adapter 应该写 skill 放置路径、是否兼容 .agents/skills、默认权限策略、哪些 agent 可以加载、是否需要禁用 skill tool、和 commands/agents 的边界。portable core 不应该提 OpenCode 的 tool 名或 permission JSON。

• OpenCode: Agent Skills

继续阅读