OpenCode: Step-by-Step Setup of a Full-Fledged AI Agent Instead of Chatting with an LLM

⚡ The gist in 5 seconds - OpenCode is a shell where the LLM gets access to files, instructions, local tools, APIs, and MCP servers. - You can connect an external provider or a local LLM: Settings → Providers → Select provider → Connect. - For work projects, you need to account for corporate policies: which models are allowed and whether code can be sent to external services. ### 🔍 What was found The author of the piece is Arina, an analyst at Selectel. She describes moving from the standard scenario of "open a chat, paste text, phrase a request, get an answer" to a full-fledged agent. According to her, such a chat quickly hits a ceiling: the model doesn't know the context of projects, documentation, code, or team rules. The working environment used is OpenCode — a shell in which the LLM gets access to files, instructions, local tools, APIs, and MCP servers. Connecting a model: for personal projects, it's enough to copy an API key from a popular provider in the settings. For a local LLM, you need to fill in the fields: provider ID, display name, base URL, API key, and available models. The configuration is split into two levels. The global config (~/.config/opencode/) contains opencode.json, AGENTS.md, and skills for all projects. The project config (in the repository) includes AGENTS.md, opencode.json, docs, contexts, scripts, and.opencode/ with skills, commands, and agents. The JSON example lists the glm-5.3 model with a 262,000 context and kimi-k2.6 with a 203,000 context, as well as default_agent: "plan". ### 💡 Why it matters Splitting the configuration and moving repetitive routines into skills and commands lets the agent work more reliably and take over the drudgery. For example, a code review skill sets a consistent check of changed files, related calls, possible regressions, error handling, and the presence of tests. The /fix-bug command runs a clear algorithm: study the description, find the code, determine the cause, propose a solution, and after confirmation, modify the code, run tests, and show the diff and risks. This eliminates having to manually describe the same scenario every time. ### 🧩 Context For rules that should apply almost always, the AGENTS.md file is used: don't invent facts that don't exist, study related implementations before changing code, don't perform commit, push, or merge without permission, and ask clarifying questions when things are ambiguous. As the configuration grows, the author advises splitting roles into separate agents: developer, reviewer, researcher, docs. They can differ in available tools, model, prompt, permissions, and skills. For example, the reviewer works in read-only mode, while the developer has access to file modifications — this is safer than giving a universal agent maximum privileges.

🔗 Read on habr.com