OpenCode для системного аналитика. Пишем требования и ревьюим спецификации с AI-агентом

Что такое OpenCode

OpenCode — открытый (MIT license) AI-агент для написания и анализа кода, работающий в терминале, desktop-приложении или как IDE-расширение. Проект создан командой Anomaly, стартовал в апреле 2025 года и к июлю 2026 обошел Claude Code по числу звёзд на GitHub — 194K против 140K. Ключевая идея — модельная и провайдерская независимость: OpenCode работает с 75+ LLM-провайдерами через каталог моделей включая Claude, GPT, Gemini, а также локальные модели через Ollama и LM Studio. Сам инструмент бесплатен — платить нужно только за токены выбранного провайдера, либо использовать бесплатные модели через OpenCode Zen или существующую подписку GitHub Copilot / ChatGPT Plus.

Для банковской и в целом enterprise-среды важно, что OpenCode не хранит код и контекстные данные на своей стороне и поддерживает офлайн/air-gapped режим с локальными моделями — того, чего нет у закрытых конкурентов вроде Claude Code.

Что означает офлайн и air-gapped

Офлайн-режим означает, что OpenCode работает с локальной LLM или внутренним AI-сервисом компании, а не отправляет требования, исходный код и спецификации во внешние API облачных провайдеров. Например, модель можно запустить на рабочей станции через Ollama либо развернуть во внутреннем контуре организации.

Air-gapped режим — более строгий вариант. Это изолированный контур без подключения к интернету и без автоматического обмена данными с внешними сетями. Данные можно перенести в такой контур только через контролируемую процедуру — например, с проверенного носителя.

Для системного аналитика разница практична: в облачном сценарии текст OpenAPI, NFR или бизнес-требований передаётся выбранному LLM-провайдеру; в локальном или изолированном контуре он остается внутри корпоративной инфраструктуры. Это особенно актуально для банковских систем, персональных данных, платежной информации и внутренней архитектурной документации.

Важно: локальная модель сама по себе еще не делает решение air-gapped. Для полноценной изоляции нужно также исключить автообновления, внешние плагины, загрузку моделей и любые сетевые обращения OpenCode.

Разница на примере

Ключевые возможности

• Автоматическая интеграция LSP — агент подключает языковые сервера к контексту LLM для более точной диагностики.
• Мультисессионность — параллельные агенты на одном проекте.
• Агенты и субагенты — встроенные Build (полный доступ) и Plan (только анализ, без изменений); General, Explore и Scout — специализированные субагенты для исследования кода и внешней документации.
• Skills — переиспользуемые инструкции через файлы SKILL.md, загружаемые по требованию, без раздувания контекстного окна.
• MCP-серверы — подключение внешних инструментов и источников данных через Model Context Protocol.
• Headless/CI режимы — opencode run, opencode serve, opencode github install.
• Тонкая система разрешений — permission allow/ask/deny для каждого инструмента и агента.
• Совместимость с форматом Claude Code — OpenCode читает .claude/skills и CLAUDE.md, существующие скилы переносятся без переписывания.

Плюсы и минусы

Шаг 1. Установка и первый запуск

1. Установите бинарь одной из стандартных команд (curl/npm/pnpm/bun/brew) — например curl -fsSL https://opencode.ai/install | bash.
2. Авторизуйтесь у провайдера модели: opencode auth login — можно подключить существующий GitHub Copilot, ChatGPT Plus или API-ключ Claude/GPT/Gemini.
3. Запустите TUI в папке проекта командой opencode, либо сразу выполните одноразовый запрос без интерфейса: opencode run "Составь черновик требований к API оплаты" --agent plan --format json.
4. Проверьте, что агент подхватил проект: команда opencode должна показать git-репозиторий и доступные модели в статус-баре.

Шаг 2. Правим конфиг проекта (opencode.json)

Конфиги в OpenCode не заменяют друг друга, а мерджатся: глобальный ~/.config/opencode/opencode.json задаёт общие предпочтения (модель по умолчанию, автообновления), а opencode.json в корне проекта переопределяет только конфликтующие ключи.

1. Создайте файл opencode.json в корне репозитория с требованиями (там же, где лежат ваши .md-файлы ролей).
2. Задайте базовую модель и агента по умолчанию:

{
  "$schema": "https://opencode.ai/config.json",
  "default_agent": "system-analyst",
  "model": "anthropic/claude-sonnet-4-5",
  "permission": {
    "edit": "ask",
    "bash": "ask",
    "skill": "allow"
  }
}

1. Поле permission.edit: "ask" и permission.bash: "ask" подстрахуют от случайных правок файлов требований — агент будет спрашивать подтверждение перед каждым изменением.
2. Поле default_agent указывает на кастомный агент, который вы создадите на шаге 3 — без этой настройки по умолчанию используется встроенный build.
3. Если работаете в нескольких проектах компании с общими правилами (единый стиль NFR, единые стандарты API) — вынесите их в глобальный конфиг ~/.config/opencode/opencode.json, а проектные исключения — в локальный opencode.json, который безопасно коммитить в git.

Шаг 3. Создаём агента “Системный аналитик”

1. Выполните интерактивную команду opencode agent create — она спросит область (глобально или для проекта), описание роли и права доступа, и сама сгенерирует файл. Либо создайте файл вручную.
2. Создайте .opencode/agents/system-analyst.md со следующей структурой:

---
description: Системный аналитик — переводит бизнес-требования в технические спецификации (backend-логика, ERD, Sequence, OpenAPI, AsyncAPI, NFR)
mode: primary
temperature: 0.2
permission:
  edit: ask
  bash: ask
  skill: allow
---
Ты опытный Системный Аналитик — специалист на стыке бизнеса и IT,
преобразующий бизнес-требования в технические спецификации.
Обладаешь глубокими знаниями архитектуры систем, интеграций и данных.

Отвечай только на русском языке. Стиль — профессиональный, без
избыточных объяснений. Для каждого артефакта создавай отдельный файл
в рабочей директории, строго следуя структуре ответа:
краткое резюме → основной контент → интеграционные связи → метрики качества.

Отвечай только на основе достоверных данных. Если информации
недостаточно — сообщи об этом и уточни задачу.

3. Имя файла (system-analyst.md) становится именем агента — вызывайте его через Tab в TUI или --agent system-analyst в CLI.
4. Поле mode: primary делает агента основным (переключаемым по Tab), а не вспомогательным субагентом.
5. Низкая temperature: 0.2 снижает “творческую” вариативность — критично для формальных требований.

Шаг 4. Превращаем частные методики в скилы

Каждая методика используемая нашим агентом (backend-логика, ERD, Sequence-диаграммы, OpenAPI, AsyncAPI, NFR) становится отдельным Skill — так агент подгружает нужную инструкцию по требованию, не раздувая контекст на постоянной основе.

1. Создайте папку под каждый скил в .opencode/skills/<имя-скила>/SKILL.md — имя папки обязательно совпадает с полем name внутри файла.
2. Пример для NFR:

.opencode/skills/nfr-requirements/SKILL.md

---
name: nfr-requirements
description: Создание нефункциональных требований (производительность, надежность, безопасность, масштабируемость) по внутреннему стандарту компании. Используй при запросе NFR или "нефункциональные требования".
---

# Создание нефункциональных требований

[Сюда переносится содержимое вашего корпоративного или личного шаблона требований —
структура разделов, чек-листы, KPI по каждой категории NFR]

## Формат сохранения
Сохраняй результат в файл `*_nfr.md` в рабочей директории.

3. Создайте необходимые скилы для повторяющихся методик используемых в работе. Я возьмк ещё 5
   • .opencode/skills/backend-logic/
   • .opencode/skills/erd-model/
   • .opencode/skills/sequence-diagram/
   • .opencode/skills/openapi-spec/
   • .opencode/skills/asyncapi-spec/
4. Название (name) должно быть 1-64 символа, только нижний регистр, цифры и одиночные дефисы, без начальных/конечных дефисов — иначе скил не загрузится.
5. Поле description — самое важное: агент выбирает скил именно по описанию, поэтому пишите его максимально конкретно (какая задача, какие триггерные слова).
6. Проверьте загрузку: запустите opencode в проекте и спросите “какие скилы доступны” — агент должен перечислить все шесть с их описаниями.

Шаг 5. Настраиваем разрешения на скилы

Если не все скилы должны быть доступны всем агентам (например, security-чек-листы — только для отдельного ревьюера), ограничьте доступ через permission.skill в opencode.json или прямо во frontmatter агента.

{
  "permission": {
    "skill": {
      "nfr-requirements": "allow",
      "backend-logic": "allow",
      "security-*": "deny"
    }
  }
}

Паттерны поддерживают wildcards — security-* запретит сразу все скилы с этим префиксом для агентов, у которых не переопределены персональные разрешения.

Этот вариант разрешает nfr-requirements и backend-logic, запрещает все Skills с именем security-…, например security-review-checklist. Но остальные Skills, которые не соответствуют ни одному правилу, остаться доступными.

Для безопасной настройки лучше использовать модель deny by default: запретить все Skills и затем открыть только те, которые необходимы конкретному агенту. Правила сопоставляются с wildcard-паттернами; * соответствует любому набору символов. Если совпало несколько правил, применяется последнее совпавшее правило. Поэтому общее правило * нужно указывать первым, а более конкретные — ниже.

{
  "$schema": "https://opencode.ai/config.json",
  "default_agent": "system-analyst",
  "model": "opencode/big-pickle",
  "permission": {
    "edit": "ask",
    "bash": "ask",
    "skill": {
      "*": "deny",
      "backend-logic": "allow",
      "erd-model": "allow",
      "sequence-diagram": "allow",
      "openapi-spec": "allow",
      "asyncapi-spec": "allow",
      "nfr-requirements": "allow"
    }
  }
}

Эта конфигурация действует для всех агентов проекта:

• запрещает загрузку любых неявно разрешённых Skills
• дает агенту системного аналитика доступ только к шести методикам подготовки артефактов
• не дает основному агенту использовать security-чек-листы
• требует явного подтверждения перед изменением файлов и запуском команд в терминале

Имена в правилах должны в точности совпадать со значением name из frontmatter соответствующего SKILL.md. Например, для пути .opencode/skills/nfr-requirements/SKILL.md используется имя nfr-requirements.

Шаг 6. Создаем субагента для ревью безопасности

1. Создайте .opencode/agents/security-reviewer.md:

---
description: Проверяет требования и спецификации на соответствие ИБ-стандартам (ISO 27001, NIST, OWASP, 152-ФЗ). Используй для ревью безопасности артефактов системного анализа.
mode: subagent
temperature: 0.1
permission:
  read: allow
  edit: deny
  bash: ask
  skill: allow
---
Ты специалист по кибербезопасности. Проверяешь требования из рабочей
директории на соответствие шести столпам ИБ: конфиденциальность,
целостность, доступность, аутентичность, неотрицаемость, подотчётность.

Используй методологию STRIDE, PASTA, DREAD, MITRE ATT&CK для анализа
угроз; OWASP Top 10 для Application Security; проверяй соответствие
ISO 27001, NIST CSF, PCI DSS, 152-ФЗ.

Результат сохраняй в папку reports (создай, если её нет) в файл
{название проверяемого артефакта}_security_review.md.

2. permission.edit: deny физически не даёт субагенту менять файлы требований — он может только читать и писать отчет в отдельную папку reports.
3. Чек-листы по этапам (STRIDE, OWASP Top 10, Data Classification и т.д.) выносим в отдельный скил .opencode/skills/security-review-checklist/SKILL.md — субагент подгрузит его только при проверке. В файл выносим все знаемые проверки для ваших задач.
4. mode: subagent делает роль вызываемой автоматически другими агентами или вручную через @security-reviewer в чате.

Шаг 7. Проверяем и запускаем весь пайплайн

1. Перезапустите OpenCode в проекте, чтобы подхватить новые агенты и скилы (агенты подхватываются автоматически при следующем запуске).
2. Запросите черновик требований: opencode run --agent system-analyst "Составь NFR для сервиса развития регулярных привычек" — агент сам выберет скил nfr-requirements и сохранит файл *_nfr.md.
3. Запустите ревью безопасности через субагента: opencode run --agent security-reviewer "Проверь nfr_service.md на соответствие 152-ФЗ и OWASP" — результат появится в reports/nfr_service_security_review.md.
4. Для регулярных проверок на каждый Pull Request подключите opencode github install — субагент security-reviewer будет автоматически комментировать PR при изменении файлов требований.
5. Если что-то не загружается — проверьте по чек-листу: имя папки скила совпадает с полем name, файл называется именно SKILL.md (в верхнем регистре), frontmatter содержит name и description, а разрешение permission.skill для агента не стоит на deny.

Сравнение с альтернативами для контекста решения

Для банковских и enterprise-проектов с требованиями к контролю данных и отсутствием vendor lock-in открытость и офлайн-режим OpenCode дают ощутимое преимущество, тогда как задачи, где критична максимальная скорость на топовой модели “из коробки”, лучше решаются Claude Code.

Ограничения, которые стоит учитывать

Итоговое качество генерации зависит от выбранной модели и провайдера — сам OpenCode не гарантирует уровень результата, это задача базовой LLM. Проект относительно молод: свыше 7000 открытых issues на GitHub говорят о недочетах в функционале и стабильности, которые стоит проверить на пилотном проекте перед массовым внедрением в команду системных аналитиков. Наконец, в отличие от подхода с CLAUDE.md, у OpenCode нет встроенной персистентной памяти между сессиями — управление долгосрочным контекстом ложится на явную структуру Skills и файлов конфигурации.