Opencode Acp Control

**Judgement:** A strong, well-documented integration skill for controlling OpenCode via ACP, best suited for environments where OpenCode is already installed and generic process/bash/webfetch tools are available. It offers rich functionality (sessions, streaming, resume, and update workflows) but requires careful protocol adherence by the agent. **Key strengths:** - Clearly specified JSON-RPC 2.0 contract (initialize, session/new, session/prompt, session/update notifications, session/cancel, session/load). - Concrete polling and timeout strategy, with examples for full end-to-end interactions. - Thoughtful handling of session persistence and resumption, supporting long-lived coding workflows. - Version-check and update orchestration pattern using `opencode --version` and GitHub releases. **Main risks and limitations:** - **Environment dependencies:** Assumes the presence of the `opencode` CLI and of tools like `bash`, `process.write/poll/kill`, `process.list`, and `webfetch`. In environments lacking these, the skill is non-functional. - **Protocol complexity:** Requires the agent to correctly manage message IDs, newline-delimited JSON-RPC messages, polling intervals, and stop conditions; mis-implementation can lead to hangs or lost responses. - **Process management risk:** Background `opencode acp` processes must be tracked and killed correctly; poor handling can leave orphaned processes or prematurely terminate active sessions. - **Update flow sensitivity:** The update workflow involves killing all OpenCode processes and relying on OpenCode’s auto-update; if misapplied, it can interrupt active work. The documentation also suggests a `curl | bash` manual update command, which is powerful and should be recommended cautiously. **Recommended scenarios:** - You want to treat OpenCode as a powerful coding backend that your agent can drive programmatically via ACP. - You need to resume and continue existing OpenCode sessions from an agent, preserving full conversation history and context. - You operate in a controlled dev environment (e.g., local dev box or dedicated server) where spawning and managing background OpenCode processes is acceptable and monitored. **Less suitable when:** - The runtime cannot guarantee availability of the `opencode` CLI or the required process/network tools. - You require a very simple, one-shot code generation tool without the overhead of ACP sessions, polling, and process management. - Strict operational policies disallow automated process control or system-level update flows initiated by an AI agent.