---
description: Добавить или настроить возможность OpenCode через environment-manager (план, таблица вариантов, diff, обновление HELP.md)
---

Пользователь хочет добавить или настроить в OpenCode: $ARGUMENTS

Загрузи доступный skill `environment-manager` через tool `skill` перед анализом и действуй строго по нему.

Реестр справки: C:\Users\Вова\.config\opencode\HELP.md

Порядок работы:
1. Проверь, можно ли решить задачу уже установленными skills, commands или MCP.
2. Сравни варианты и покажи ровно такую таблицу:

| Вариант | Тип | Что получу | Доступы/секреты | Риски | Context/token overhead | Рекомендация |
|---|---|---|---|---|---|---|

3. Явно выбери один вариант и объясни, почему.
4. Покажи полный текст создаваемых файлов и полный unified diff, точные пути и список затрагиваемых файлов.
5. Обязательно включи в тот же план обновление HELP.md: дата подготовки и затронутые skills/commands/MCP/permissions. Покажи diff HELP.md до записи.
6. Ничего не записывай, пока пользователь явно не подтвердит единый план.

Запрещено:
- любые изменения без явного подтверждения пользователя;
- менять `opencode.jsonc`, `cli.json`, MCP, plugins, permissions, текущий проект и существующие skills/commands автоматически;
- устанавливать пакеты, подключать MCP, создавать OAuth/PAT;
- читать `service.json`, секреты, токены, `.env`, SSH-ключи;
- создавать manifest или registry помимо единственного HELP.md.

Ограничение: явная загрузка skill из тела Markdown-команды не подтверждена официальной документацией OpenCode V2 (в frontmatter команды нет поля skill, а `@skill-id` в шаблоне не раскрывается). Поэтому загрузка `environment-manager` — это инструкция модели вызвать tool `skill`, а не гарантированный макрос. Явно укажи это ограничение в выводе плана.

После успешного применения проверь, отражает ли HELP.md фактическое состояние. Если для этого требуется изменить `opencode-help/SKILL.md` или иной справочный файл, сначала покажи отдельный полный diff. Выполни его только при отдельном явном подтверждении, если это изменение не было уже включено в тот же ранее подтверждённый единый план. Не изменяй существующие skills или commands автоматически.

---
name: Environment Manager
description: Самообслуживание OpenCode. Автоматически выбирай этот skill, когда пользователь просит добавить, настроить, подключить или найти skill, MCP, plugin, command, agent, permission, интеграцию или иную возможность окружения («хочу X»). Сначала исследует, сравнивает варианты и ничего не меняет без явного подтверждения.
---

# Environment Manager

Самообслуживание окружения OpenCode: понять запрос, задействовать уже установленное, сравнить варианты и выполнить только согласованное изменение после явного подтверждения.

## Когда использовать
- Пользователь говорит «хочу X» про возможности OpenCode: skill, command, MCP, plugin, agent, permission, интеграцию, настройку.
- Нужно добавить, настроить, подключить, найти или объяснить компонент окружения.
- Нужно понять, можно ли решить задачу уже установленными средствами.

## Обязательное использование существующих skills
Если существуют skills general-engineering, technical-research, prompt-engineering, token-efficient-workflow, project-learning — используй релевантные из них по назначению:
- `general-engineering` — базовый процесс для любой задачи;
- `technical-research` — когда нужны актуальные внешние данные и их проверка;
- `prompt-engineering` — когда нужен промпт, ТЗ или бриф;
- `token-efficient-workflow` — когда задача большая и важен контекст/токены;
- `project-learning` — когда нужно вынести конвенции проекта в project-local skill.

Не утверждай, что skill использован, если он не был реально загружен или вызван в среде.

## Границы и безопасность
- Ничего не создавай, не изменяй и не удаляй до явного подтверждения пользователя.
- Не устанавливай пакеты, не подключай и не меняй MCP, не создавай OAuth/PAT, не меняй `opencode.jsonc`.
- Не добавляй и не меняй permissions автоматически: только показывай точный diff и жди подтверждения.
- Не читай и не выводи секреты, токены, `.env`, SSH-ключи, browser profile, credential stores, `service.json`.
- Уважай границы проекта: не трогай файлы текущего проекта без прямой просьбы.
- Любое внешнее действие (сеть, установка, запись) — только после подтверждения.

## Шаг 1. Классификация запроса
Когда пользователь пишет «хочу X», сначала ответь:
1. Решается ли это уже установленными skills, commands или MCP? Если да — назови их и покажи, как использовать.
2. Нужен ли новый компонент? Если нет — скажи прямо.
3. Если нужен, что подходит лучше:
   - **skill** — переиспользуемые инструкции и процесс для модели;
   - **command** — явный слэш-сценарий с аргументами;
   - **MCP** — внешний инструмент или сервис;
   - **plugin** — хуки, tools и интеграция с API OpenCode;
   - **agent** — отдельная роль или режим со своими правилами и набором tools;
   - **project-local skill** — конвенции конкретного проекта;
   - **AGENTS.md** — постоянные правила проекта;
   - **изменение `opencode.jsonc`** — конфигурация и разрешения.
4. Нужен ли интернет или официальная документация, чтобы проверить актуальность?

## Шаг 2. Исследование
- Если нужна свежая информация, используй официальную документацию: сначала OpenCode docs, затем документацию вендора и официальный репозиторий.
- Для API/SDK используй Context7, если он доступен.
- Для релизов и GitHub issues используй web search, если он доступен.
- Не выдумывай MCP, skills, URL, команды, версии или поля конфигурации.
- Не рекомендуй пакет только потому, что он популярный.

## Шаг 3. Обязательная таблица сравнения
Перед ЛЮБЫМ изменением верни ровно такую таблицу:

| Вариант | Тип | Что получу | Доступы/секреты | Риски | Context/token overhead | Рекомендация |
|---|---|---|---|---|---|---|

После таблицы явно выбери один вариант и объясни, почему выбрал именно его.

## Шаг 4. Оценка сторонних MCP, skill или plugin
При оценке стороннего MCP, skill или plugin обязательно проверь и укажи:
- maintainer;
- официальный источник;
- необходимость токенов;
- требуемые permissions;
- локальность/сеть;
- active maintenance;
- supply-chain risk;
- context/token overhead;
- совместимость с OpenCode V2.

## Шаг 5. Permissions и доступы
- По умолчанию для новых MCP tools — ask.
- Не добавляй write access к GitHub, БД, почте, файловым хранилищам, Sentry, Jira/Linear, Docker/Kubernetes или облаку без отдельного явного запроса.
- Permissions не меняются автоматически: только предложение и явное подтверждение.

## Шаг 6. План до записи
Покажи пользователю:
- точные пути создаваемых или изменяемых файлов;
- полный текст новых файлов и/или unified diff;
- список затрагиваемых файлов;
- что именно НЕ будет изменено (проект, `opencode.jsonc`, MCP, permissions);
- какие данные намеренно не читались.

## Шаг 7. Выполнение после подтверждения
- снова покажи полный diff непосредственно до записи;
- выполни только согласованные изменения;
- не делай дополнительных установок;
- проверь обнаружение или подключение;
- покажи способ вызова;
- перечисли новые permissions и доступы.

## Запреты
- Не читать и не выводить секреты, токены, `.env`, SSH-ключи, browser profile, credential stores, `service.json`.
- Не устанавливать пакеты и не подключать MCP без подтверждения.
- Не создавать OAuth/PAT и не вставлять секреты в конфиг.
- Не менять permissions без отдельного подтверждения.
- Не удалять и не перезаписывать существующие файлы без подтверждения.

---
description: Краткая справка по среде OpenCode на основе подготовленного реестра HELP.md
---

Вопрос по OpenCode: $ARGUMENTS

Сначала прочитай подготовленный реестр справки:
C:\Users\Вова\.config\opencode\HELP.md

Как отвечать:
1. Сначала используй релевантный раздел HELP.md.
2. Если данных HELP.md недостаточно — сам сформулируй уточняющие подзадачи, найди ответ в безопасных read-only источниках и официальной документации OpenCode. Ничего не меняй и не выдумывай.
3. HELP.md — подготовленный реестр, а не гарантия live-runtime статуса. Для runtime-состояния явно указывай, что оно не проверено.
4. Если реестр и факты расходятся, покажи расхождение и предложи обновить HELP.md через `/add`.

Примечание: не заставляй `/help` читать `opencode.jsonc`, если это нарушает настройку или permission; при недоступности безопасного источника честно указывай, что состояние не удалось проверить.

Если `$ARGUMENTS` пуст — дай краткий обзор по разделам HELP.md:
1. Skills.
2. Commands.
3. MCP.
4. Permissions.
5. Быстрые команды и как добавить новую возможность через `/add`.

Если `$ARGUMENTS` не пуст — покажи только релевантный раздел HELP.md и один готовый пример.
Если нужного раздела в HELP.md нет — сам сформулируй уточняющие подзадачи, найди ответ в безопасных read-only источниках и официальной документации OpenCode, ничего не меняя и не выдумывая.

Запрещено из `/help`:
- выполнять shell;
- менять конфиг, skills, commands, MCP, permissions, текущий проект;
- читать `service.json`, секреты, токены, `.env`, SSH-ключи;
- создавать manifest или registry помимо единственного HELP.md.

Ограничение: явная загрузка skill из тела Markdown-команды не подтверждена официальной документацией OpenCode V2 (в frontmatter команды нет поля skill, а `@skill-id` в шаблоне не раскрывается). Это инструкция модели вызвать tool `skill`, а не гарантированный макрос.

---
name: OpenCode Help
description: Инструкция по фактической среде OpenCode. Автоматически выбирай этот skill, когда пользователь спрашивает, как пользоваться OpenCode, что доступно сейчас, какие skills, commands, MCP и permissions активны, и как выполнить действие в этой среде.
---

# OpenCode Help

Источник по умолчанию — подготовленный реестр `C:\Users\Вова\.config\opencode\HELP.md`. Полный аудит на каждый запрос не выполняется.

## Порядок ответа
1. Сначала прочитай `C:\Users\Вова\.config\opencode\HELP.md` и ответь по релевантному разделу.
2. Полную проверку skills, commands и permissions делай только если данных в HELP.md не хватает или есть подозрение на расхождение.
3. Для MCP показывай конфигурационный состав из HELP.md; runtime-статус — только если он уже доступен через UI/безопасный read-only источник без shell.
   Если runtime-статус недоступен, явно укажи: “runtime-статус не проверен: команда /help не выполняет shell и не запускает CLI”.
4. HELP.md — подготовленный реестр, а не live-runtime снимок. Если реестр и фактическое состояние расходятся, покажи факт и предложи обновить HELP.md через `environment-manager` (`/add`).

## Безопасность
Не читай `service.json`, секреты, токены, `.env`, SSH-ключи, browser profile и credential stores.
Не выполняй shell из `/help`.
Не меняй конфиг, skills, commands, MCP, permissions и текущий проект.
Не создавай manifest или registry помимо единственного HELP.md.

## Ограничение по shell и CLI
Если для проверки фактического статуса MCP нужны shell или CLI, а командой `/help` это запрещено — честно укажи ограничение и покажи доступный статус без shell.

## Достоверность
Не утверждай, что компонент установлен, только потому, что он упомянут в HELP.md. При недоступности безопасного источника честно указывай, что состояние не удалось проверить. Не заставляй `/help` читать `opencode.jsonc`, если это нарушает настройку или permission.

## Если пустой /help — короткие разделы
1. Что доступно сейчас: skills, commands, MCP.
2. Что умеет среда по категориям:
   - разработка;
   - research/docs;
   - git/GitHub;
   - проекты и local skills;
   - безопасность/permissions.
3. Быстрые команды с готовыми примерами:
   - /search;
   - /prompt;
   - /lean;
   - /plan;
   - /review;
   - /add;
   - /help.
4. Что потребует подтверждения, что разрешено автоматически, что запрещено.
5. Как добавить новую возможность: `/add <что хочу>`.

## Если пользователь спрашивает о конкретном компоненте
Не выводи всю справку: покажи только релевантный раздел HELP.md и один готовый пример. Если раздела нет — уточни по безопасным read-only источникам и официальной документации OpenCode, ничего не меняя.

Создай файл справки HELP.md: подготовленный реестр моих возможностей агента.
Путь: ~/.config/opencode/HELP.md (в Claude Code и Codex подставь свою
глобальную папку конфига).

Сначала только читай, ничего не записывай:
1. Составь список установленных skills и commands. Нужны имя и одна строка
   «когда использовать». Опирайся на их frontmatter.
2. Составь список MCP-серверов: только имя и тип. Статус подключения не
   проверяй и не выдумывай.
3. Кратко опиши permissions по категориям: что разрешено автоматически,
   что требует подтверждения, что запрещено. Без значений и секретов.

Структура HELP.md:
- шапка: «подготовленный реестр, не live-статус», дата подготовки,
  «секретов здесь нет»;
- 1. Skills (таблица);
- 2. Commands (таблица с примером вызова; обязательно /add и /help);
- 3. MCP (таблица + пометка, что runtime-статус не проверен);
- 4. Permissions (сводка);
- 5. Безопасность и границы;
- 6. Как обновлять: после каждого подтверждённого изменения окружения /add
  включает обновление HELP.md в тот же план и показывает его diff.

Правила:
- Не читай и не вноси токены, .env, ключи, значения переменных окружения,
  private URL.
- Не меняй конфиг, skills, commands, MCP, permissions.
- Не выдумывай то, чего нет в среде. Если не уверен, пропусти пункт или
  пометь «не проверено».
- Файл должен быть коротким и удобным для чтения: таблицы, без воды.

Сначала покажи полный текст HELP.md и жди моего «да». Файл создай только
после подтверждения.

/add Настроить permissions по моей схеме. Только план и diff, без записи.

Задача: привести permissions OpenCode к схеме ниже. Права сам не меняй,
только покажи план и diff и жди моего «да».

Схема:
- allow: чтение файлов, поиск по коду, веб-поиск, webfetch;
  рутинный shell, git (status, diff, log), запуск тестов.
- ask: инструменты PostgreSQL MCP; любое новое или не описанное правило;
  соседний репозиторий и домашняя папка.
- Docker: одно подтверждение на связанную серию действий.
- deny: чтение секретов (.env, *.pem, *.key, SSH-ключи, .aws);
  управление браузером и вход в аккаунты (или подтверждение каждого шага).

Порядок работы:
1. Определи версию OpenCode и формат permissions именно для неё.
   Используй официальную документацию. Если синтаксис в моей версии
   отличается от того, что ты знаешь, скажи об этом и не угадывай.
2. Прочитай текущий конфиг (только блок permissions и MCP). Если встретишь
   секрет, токен или значение переменной среды, не выводи его, а предупреди меня.
3. Покажи таблицу: что сейчас -> что предлагается -> зачем.
   Отдельно перечисли правила, которые станут строже или мягче.
4. Покажи полный unified diff, точный путь файла и способ отката.
5. Учти порядок правил: общее правило идёт первым, исключения после него.
6. Новые MCP-инструменты добавляй только в режиме ask.
   Write-доступ к PostgreSQL, почте, облаку и базам без моей отдельной просьбы
   не добавляй.
7. Обнови HELP.md в том же плане (раздел Permissions) и покажи его diff.

Запрещено:
- записывать что-либо до моего явного «да»;
- расширять права сверх схемы выше;
- читать секреты, .env и значения переменных среды;
- удалять существующие правила, не указав это в плане.

В конце напиши, какие пункты ты не смог проверить, и что мне нужно
проверить вручную.