Недавно я экспериментировал с использованием Gemini для написания кода. Основным инструментом была веб-версия AI Studio. Такой подход позволял точно контролировать изменения, но был крайне медленным.

Гораздо эффективнее — анализировать diff изменений. Поэтому я перешёл к поиску более производительных решений: расширений для IDE и консольных инструментов.

Сравнение инструментов

• Gemini CLI: высокая скорость, но чрезмерно расходует токены и лимиты запросов.
• IDE-расширения с внешними провайдерами: незначительный прирост удобства по сравнению с консолью.
• Open source инструменты с поддержкой асинхронных агентов: гибкость и работа с любыми провайдерами, но слабые расширения для IDE и нестабильное соединение с бэкендом.
• RooCode: удобные настройки, предсказуемость результата, встроенные MCP-серверы, но синхронное выполнение задач (медленнее асинхронных аналогов).

Сейчас я использую три инструмента: VS Code + RooCode, QWEN Code и OpenCode.

Почему RooCode стал основным инструментом

RooCode — мой самый частый выбор. Он похож на OpenCode, но удобнее в настройке: изменить поведение можно быстро и на лету. Несмотря на более медленное последовательное выполнение задач, это даёт предсказуемость результата.

Что даёт эта статья

Статья поможет глубоко настроить RooCode с минимальным количеством итераций. Вы получите:

• Пошаговое руководство по настройке всех компонентов
• Готовые промпты для Модов
• Структуру Скиллов для копирования
• Понимание философии многоагентной системы

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

Часть 1: Базовая настройка

Main Window | Главное окно

После авторизации отображается стандартный список чатов (пока пустой) и нижняя панель с элементами:

1. Окно ввода сообщения: сообщения ставятся в очередь, если выполняются текущие задачи.
2. Mode | Мод: режим работы, аналогичный агенту. Переключение происходит при следующем запросе — нужно остановить выполнение или отправить новое сообщение.
3. AI-модель: смена применяется после завершения текущего запроса.
4. Auto-Approve: разрешение на выполнение потенциально опасных действий (например, запуск команд в консоли).
5. Indexing | Значок базы данных: активация индексации проекта. Позволяет RooCode сканировать файлы и каталоги, что повышает точность LLM.

Indexing | Индексация проекта

Требуется настроить подключение к провайдеру векторной обработки и указать соединение с векторной БД Qdrant для хранения графов. Это улучшает контекстное понимание кода и точность правок.

Auto-Approve | Разрешения на выполнение операций

Здесь задаются разрешённые действия для LLM. Можно ограничить по количеству запросов или стоимости, чтобы избежать превышения лимитов.

Если разрешить выполнение консольных команд (Execute), появится список разрешённых и запрещённых команд. Его можно дополнять вручную или в процессе работы. При появлении новых команд RooCode будет запрашивать подтверждение — так список разрешений постепенно растёт.

Marketplace | Маркетплейс MCP-серверов и Модов

Через кнопку в главном меню можно установить преднастроенные MCP-серверы и Моды. Установленные серверы отображаются в отдельной вкладке.

Важно: MCP-сервер для git всегда настраивается внутри проекта, чтобы не смешивать репозитории. Поэтому на скриншотах он может отсутствовать.

Предустановленных Модов много, но я использую только один.

Notifications | Уведомления

Рекомендую включить уведомления и настроить громкость. RooCode оповестит о:

• Необходимости подтвердить команду
• Прерванных операциях (при подозрении на циклические действия)
• Полном завершении всех задач

Prompts | Встроенные промпты

Промпты улучшают взаимодействие. Например, промпт "Enhance" переформулирует запрос пользователя перед отправкой, делая его более точным.

Все промпты стоит внимательно прочитать и адаптировать под себя. В моём случае промпт "Enhance" был полностью переписан и будет дорабатываться в будущем.

Enhance Prompt | Промпт по улучшению запроса пользователя

UI | Полезные функции интерфейса

Следующие настройки UI оказались особенно полезными:

• Разворачивать размышления моделей: помогает выявлять логические ошибки на раннем этапе.
• Отправка сообщений по Ctrl+Enter (или Shift+Enter): предотвращает случайную отправку незавершённых сообщений при быстрой печати.

Experimental | Экспериментальные функции

Из экспериментальных функций я включаю:

• Background editing: убирает мелькание окон при правках, позволяя параллельно работать с кодом.
• Выполнение команд через слэш: удобно для вызова Модов и Скиллов.

Часть 2: Скиллы

Я разделил Скиллы на три категории:

1. Использование MCP-серверов (префикс mcp-): повышают успешность выполнения задач, минимизируя использование консоли.
2. Использование консоли (префикс cli-): базовые команды с понятным синтаксисом.
3. Пользовательские Скиллы (префикс usr-): пояснения для решения конкретных задач в определённых режимах.

Ресурсы: множество Скиллов доступно в открытых библиотеках: https://claudemarketplaces.com/skills и https://geminicli.com/extensions

Пример состава Скилла

Путь: ~/.roo/skills/mcp-time/SKILL.md

Набор Скиллов для RooCode

Глобальные Скиллы хранятся в ~/.roo/skills, проектные — в <project_dir>/.roo/skills. Мои системные Скиллы выложены на GitHub.

Часть 3: Моды (Агенты)

RooCode поддерживает встроенные Моды, которые можно расширять через Маркетплейс или создавать самостоятельно. Каждый Мод привязан к конкретной LLM — это одна из ключевых особенностей (вторая — агентское поведение, позволяющее Модам переключаться между собой).

Встроенный набор Модов

• Orchestrator (Оркестратор): управляет всеми другими Модами, отвечает на любые вопросы.
• Project Research (Ищейка): ищет участки кода (кастомный Мод из Маркетплейса).
• Architect (Архитектор): проектирует архитектуру, пишет и модифицирует код, решает проблемы.
• Code (Кодер): вносит правки по инструкциям.
• Debug (Дебаггер): ищет решения при ошибках реализации.

Оркестратор планирует все задачи, но не может выполнять код или обращаться к файлам. Это заставляет его делегировать задачи другим Модам, что оптимизирует использование LLM.

Примечание: было бы удобно запускать несколько оркестраторов в разных ветках, но пока доступен только один. Зато проще контролировать качество выполнения.

Modes | Меню Модов

Здесь настраивается привязка моделей к Модам и системные промпты. Исходные формулировки мне не подошли — я переписал их в несколько итераций, наблюдая за поведением. Вероятно, буду корректировать и дальше.

Таблица температур для Модов

• Orchestrator: 0.8 — творческое планирование задач.
• Project Research: 0.3 — минимальные отклонения, точный поиск.
• Architect: 0.8 — архитектурное мышление и креативность.
• Code: 0.3 — точное следование инструкциям.
• Debug: 0.8 — творческий поиск решений.

Orchestrator | Оркестратор

Оркестратор — главный агент. Он должен полностью понять задачу пользователя и направить её нужному исполнителю, пока проблема не будет решена. Для этого нужна умная, но не обязательно самая новая модель. Температура 0.8 обеспечивает творческое осмысление.

Ask | Советник

Советник отвечает на любые вопросы. Требуется умеренная креативность (температура 0.5). Я использую новые, но дорогие модели, чтобы задействовать актуальные знания.

Project Research | Ищейка

Ищейка должен точно находить нужные участки кода. Температура 0.3 минимизирует отклонения. Он не пишет код и не предлагает решений — это не входит в его задачу.

Architect | Архитектор

Архитектор — ключевой исполнитель. Использует самую умную модель и работает с температурой 0.8. От его решений зависит успех всей задачи.

Code | Кодер

Кодер — лёгкая модель, строго следующая инструкциям. Температура 0.3. При проблемах он не зацикливается, а передаёт задачу Дебаггеру.

Debug | Дебаггер

Дебаггер ищет решения, если Кодер не справился. Требуется умная модель и температура 0.8 — возможно, задача была выполнена слишком буквально.

Часть 4: Провайдеры и интеграция

После настройки Модов важно правильно выбрать провайдеров. Использование одной модели для всех Модов лишает гибкости и оптимизации. Тогда проще было бы использовать один Мод с длинным промптом-воркфлоу.

RooCode поддерживает большинство провайдеров, включая локальные модели (например, через API LM Studio). Детали настройки аналогичны другим инструментам — углубляться не буду.

Итоги и рекомендации

Выводы от использования RooCode

RooCode — удобный инструмент агентской разработки для тех, кто ценит синхронное выполнение и предсказуемость. Однако у него есть потенциал для развития.

Цикл итеративной настройки

Процесс настройки можно представить как цикл:

1. Настройка поведения расширения без привязки к моделям.
2. Определение разрешённых и запрещённых инструментов (MCP, консоль).
3. Создание Скиллов для точного выполнения задач.
4. Создание Модов с уникальным поведением.
5. Оптимизация моделей по стоимости и качеству.
6. Повторная настройка предыдущих этапов при необходимости.

Предостережения

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

При создании промптов чётко определяйте границы ответственности каждого Мода. LLM склонны выполнять всё, что просят, даже если это не в их зоне. Настройка промптов — самый трудоёмкий этап, поэтому я привожу свои примеры как ориентир.

Учтите: мои промпты и Скиллы отражают личные предпочтения, которые могут не подойти вам. Адаптируйте под свой рабочий процесс.

Спасибо за внимание!

Эволюция инструментов

Не так давно я публиковалстатьюоб использовании Gemini для написания кода (или для эпохи LLM-копирайтинга это уже считаетсядавно?) . В том эксперименте основным инструментом была веб-версия AI Studio. Это позволяло точно контролировать все детали работы с кодом: я оперировал участками кода и внимательно вчитывался, где какие замены нужно внести. Такой подход позволял вносить правки точечно, без нарушения целостности кода, но процесс доработки был крайне медленным.

Гораздо быстрее — вчитываться в diff изменений. Поэтому далее поиски завели в два направления: расширения для IDE и консольные инструменты.

Сравнение инструментов

Инструмент

Преимущества

Недостатки

Gemini CLI

Очень высокая скорость работы

Чрезмерно расходует токены и лимиты запросов (RPS/RPM)

Расширение для IDE, подключение внешних провайдеров

Улучшения комфорта некритичны относительно консольной версии

Open source, работа с любыми провайдерами, асинхронный вызов Агентов

Слабое IDE-расширение, нестабильное соединение с backend

Удобные настройки, предсказуемость результата, встроенные MCP-серверы

Синхронное выполнение задач (медленнее асинхронных аналогов)

На данный момент я использую три инструмента:VS Code + RooCode,QWEN CodeиOpenCode.

Почему RooCode стал основным инструментом

RooCode — самый часто используемый мной инструмент на данный момент. Он напоминает OpenCode, но удобнее в настройках: когда хочешь подкрутить поведение в моменте, это делается быстрее. RooCode немного теряет в скорости из-за последовательного выполнения задач, но это же даёт определённую предсказуемость результата.

Что даст эта статья

Статья построена по принципу постепенного погружения в ключевые настройки расширения, чтобы минимизировать этапы многоитеративного дополнения конфигурации. Вы получите:

• Пошаговое руководство по настройке всех компонентов
• Готовые промпты для Модов
• Структуру Cкиллов для копирования
• Понимание философии многоагентной системы

В общем, начнём настройку.

Часть 1: Базовая настройка

Будьте готовы: описание ведётся не в порядке размещения настроек и менюшек, а в смысловом порядке удобства настройки расширения от А до Я.

Main Window | Главное Окно

Главное окно после авторизации встречает стандартным видом списка чатов, которых пока ещё нет.

А также в самом низу отображает:

1. Окно ввода сообщения. Сообщения можно вводить в любой момент, но если в данный момент выполняются работы, то сообщение попадёт в очередь и будет отправлено автоматически после получения ближайшего ответа AI-модели.
2. Mode | Выбранный Мод(режим работы, что по смыслу очень похоже на Агента). Настройку можно сменить в любой момент, но фактически переключение произойдёт при следующем запросе от пользователя. Т.е. нужно остановить работу агентского режима или создать очередное сообщение — при отправке которого режим переключится полноценно.
3. AI-модель, которая задействована в данном режиме. Настройки применятся сразу же, как только завершится исполняемый запрос к LLM.
4. Auto-Approve | Выбранные разрешениядля AI-моделей — спрашивать пользователя или самостоятельно выполнять потенциально опасные действия.
5. Indexing | Значок базы данных— вот именно это нам сейчас нужно выбрать, что далее позволит RooCode сканировать файлы и каталоги проекта. Это приведёт к тому, что LLM будет выдавать более точные ответы и, соответственно, целенаправленно вносить правки.

Indexing | Индексация проекта

Нужно настроить подключение к провайдеру, который позволяет выполнять векторную обработку данных и строить графы, а также указать соединение до векторной БД Qdrant, где будут храниться результаты построений графов.

Auto-Approve | Разрешение на выполнение операций

В данном меню выбираем, какие встроенные функции будет разрешено выполнять LLM. Можно ограничить количеством запросов или стоимостью, чтобы в автоматическом режиме LLM не исчерпали все лимиты или баланс.

Если вы дадите разрешение на выполнение команд в консоли (Execute), то появится меню с автоматически разрешёнными командами и всегда запрещёнными для LLM. Данный список вы можете дополнять, зайдя в настройки или непосредственно в ходе работы расширения. При появлении новых видов консольных команд RooCode будет запрашивать разрешение у пользователя — таким образом списки разрешений/блокировок будут постепенно дополняться.

Marketplace | Маркетплейс MCP-серверов и Модов

Вверху главного меню есть кнопка открытия Маркетплейса, откуда можно установить уже преднастроенные соединения с MCP-серверами и новые виды Модов.

Пример списка для моего случая вы видите на скриншоте.

Важно: MCP-сервер для git всегда настраивается внутри проекта, чтобы не смешивать репозитории, поэтому на скриншотах он не отображается установленным.

После установки список настроенных MCP-серверов отображается в отдельной вкладке.

Есть множество преднастроенных Модов, которые вы можете скачать, но я установил только один из них.

Notifications | Уведомления

Очень советую включить уведомления и настроить комфортную громкость, чтобы не пропускать сообщения, когда требуется взаимодействие с расширением. RooCode будет сообщать уведомлением о:

• Необходимости подтверждения команд
• Прерванных операциях (если заподозрит LLM в циклических действиях)
• Полном завершении всех задач

Prompts | Встроенные промпты

Встроенные промпты несколько улучшают взаимодействие с расширением. Например, промпт"Enhance"позволяет с использованием LLM перефразировать запрос пользователя в чате до его отправки на исполнение.

Очень рекомендую все доступные промпты вычитывать и вносить правки согласно своему видению.

Конкретно в моём случае промпт "Enhance" был переписан, текст приведён ниже. Наверняка, я буду его править ещё множество раз в будущем.

Enhance Prompt | Промпт по улучшению запроса пользователя

UI | Полезные функции UI

В моём случае опции изменения UI оказались очень полезными:

• Я выбрал разворачивать размышления моделей, т.к. иногда встречаю логические ошибки на этом этапе — это позволяет превентивно вносить корректировки в дальнейшие действия.
• Включил отправку сообщений по нажатию Ctrl+Enter (фактически же также срабатывает по нажатию Shift+Enter, что меня дико раздражает) — я люблю делать абзацы в тексте и во время быстрой печати без этой настройки могу отправить недописанные сообщения.

Experimental | Экспериментальные функции

Среди экспериментальных функций я обязательно включаю:

• Background editing— устраняет мелькание окон перед глазами с правками кода и текста, что позволяет в это время заниматься другими ручными вычитками и правками
• Выполнение команд через слэшдля Модов, к которым также относятся и Скиллы

Часть 2: Скиллы

Настройку Скиллов я разбил на три категории по мере их дополнения друг друга:

1. Использование MCP-серверов— чтобы LLM минимально использовали консоль и получали больший success-factor. В моём случае все они имеют префикс "mcp-", сами наименования Скиллам вы можете давать любые.
2. Использование консоли— с базовым набором и синтаксисом консольных команд. Префикс "cli-".
3. Пользовательские Скиллы— с пояснениями для различных режимов: что нужно делать для определённых поставленных задач. Префикс "usr-".

Ресурсы: Множество Скиллов доступно в открытых библиотеках:https://claudemarketplaces.com/skillshttps://geminicli.com/extensions

Пример состава Скилла

Путь размещения:~/.roo/skills/mcp-time/SKILL.md

Набор Скиллов для RooCode

Глобальные Скиллы размещаются в~/.roo/skills, Скиллы проекта — в/.roo/skills.

Свои системные Скиллы выложил наGithub.

Часть 3: Моды (Агенты)

RooCode имеет встроенный набор Модов, который можно неограниченно расширять примерами из Маркетплейса или создавая самостоятельно. Каждый Мод имеет привязку конкретной модели LLM для выполнения задач — это одна из двух ключевых характеристик расширения (вторая — агентское поведение Модов, позволяющее им самостоятельно переключаться между собой).

Встроенный набор Модов

Назначение

Orchestrator

Оркестратор

Главный Мод, управляет всеми другими

Отвечает на вопросы любой направленности

Project Research

На самом деле кастомный из маркетплейса, ищет участки кода

Архитектор

Проектирует архитектуру и технические планы

Пишет и модифицирует код

Диагностика и решение проблем

Главным из них являетсяОркестратор, который планирует все работы, но ему не позволено исполнять код и обращаться к файлам. Это ограничение вынуждает его передавать задачи на исполнение другим Модам, что приводит к оптимизации запросов к LLM.

Примечание: Было бы удобнее, если бы появилась возможность запускать несколько параллельных оркестраторов одновременно в раздельных ветках репозитория, но пока имеем только такой вариант. Зато легче следить за качеством исполнения задач.

Modes | Меню Модов

В данном меню настраивается привязка моделей к Модам и детали системных промптов.

Исходные формулировки промптов меня не устроили, и я их переписал. Вносил изменения множеством итераций по мере наблюдения, что они выполняли ожидаемо для меня, а что нет. Наверняка, я их буду корректировать и далее по мере изменения своего видения их применения.

Таблица применяемых температур для Модов

Температура

Обоснование

Orchestrator

Творческое планирование задач

Баланс точности и креативности

Project Research

Минимальные отклонения от задачи

Архитектурное мышление

Точность реализации кода

Диагностическое творчество

Orchestrator | Оркестратор

Оркестратор— главный Мод (агент), который управляет всеми другими.

Идеальная ситуация: он полностью понимает проблематику, которую озвучивает пользователь, и перенаправляет вопросы на нужного исполнителя, пока не убедится, что проблема пользователя полностью решена. Это требует выбора достаточно умной модели, но необязательно самой новой и навороченной. А также требует применения высокой температуры рассуждений (в моём случае это 0.8) для творческого осмысления задач.

Role Definition

When to Use (optional)

Mode-specific Custom Instructions (optional)

Ask | Советник

Советникпомогает ответить на вопросы любой направленности.

Требуется слегка творческое осмысление и режим рассуждения (температура 0.5). Это приводит к тому, что я применяю более новые модели (чтобы использовал наиболее актуальные знания), но все ещё очень дорогие.

Role Definition

When to Use (optional)

Mode-specific Custom Instructions (optional)

Project Research | Ищейка

Ищейкадолжен очень точно найти информацию по поставленной задаче с минимальными отклонениями.

Температура 0.3 — чтобы быстро найти именно те участки кода, которые проясняют озвученную задачу. Но также он не пишет код и не предлагает решений, т.к. это слишком сложно для него.

Role Definition

When to Use (optional)

Mode-specific Custom Instructions (optional)

Architect | Архитектор

Архитекторявляется ключевой фигурой в решении поставленных задач.

Для него выделяется самая умная и актуальная модель и выдаётся возможность более творчески переосмыслить входные данные (температура 0.8). От его решений будет зависеть, будет ли выполнена задача или придётся всё начинать сначала (или с предыдущего checkpoint).

Role Definition

When to Use (optional)

Mode-specific Custom Instructions (optional)

Code | Кодер

Кодер— достаточно легковесная модель, которая должна в точности следовать с поставленным инструкциям.

Температура 0.3 — для обновления кода и документации. А если натыкается на проблемы, то не вгоняет себя в цикл исправлений, а отдаёт более квалифицированному коллеге — Дебаггеру.

Role Definition

When to Use (optional)

Mode-specific Custom Instructions (optional)

Debug | Дебаггер

Дебаггерищет варианты решения проблем, если у Кодера возникли проблемы в реализации.

Это требует более умной модели и возможности творчески осмыслить проблему (температура 0.8) — может быть, Кодер слишком буквально пытался выполнить задачу.

Role Definition

When to Use (optional)

Mode-specific Custom Instructions (optional)

Часть 4: Провайдеры и интеграция

После настройки Модов наступает время настроить провайдеров для выполнения задач.

Можно применить одну и ту же модель с одинаковыми настройками для всех Модов, но тогда теряется гибкость и невозможна оптимизация. Тогда было бы проще применять один Мод с очень длинным промптом-workflow.

RooCode поддерживает большинство провайдеров, а также локальные модели (например, через API LM Studio).

Углубляться в эту тему не буду - все очень похоже на другие приложения и расширения.

Итоги и рекомендации

Выводы от использования RooCode

RooCode — очень удобный инструмент агентской разработки для тех, кого устраивает синхронный вызов Модов и выполнение задач. Но также есть множество направлений для дальнейшего развития этого продукта.

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

Цикл итеративной настройки

Если на весь этот процесс посмотреть верхнеуровнево, то цикл настройки выглядит как:

1. Настройка поведения расширениябез привязки к AI-моделям
2. Настройка инструментовдоступных/запрещённых моделям: MCP и консольные команды
3. Создание Скилловдля использования инструментов и более точного исполнения задач пользователя
4. Создание Модов(или Агентов) со своими характеристиками поведения, которые воспользуются всеми доступными возможностями
5. Оптимизация уровней моделей, которые будут применяться Модами, для минимизации расходов при предсказуемом качестве работы
6. Повторить донастройкулюбого предыдущего этапа и потенциально всех последующих, т.к. они зависимы от предыдущих

Предостережения

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

В ходе написания промптов старайтесь очень точно выделять границы ответственности Мода/Агента, чтобы они не превышали доступные полномочия. LLM модели всячески стараются угодить и выполнить все озвученные задачи, даже если они назначены не на них. На этап шлифовки промптов уходит максимум всего задействованного времени настройки приложения, поэтому в тексте я их и привожу - чтобы было на что ориентироваться при собственной кастомизации.

Также при применении данной инструкции учитывайте, что в промптах и Скиллах упоминаются инструкции по удобному лично для меня процессу работы (в данный момент, но это не навсегда), и вам могут подойти не все из них, а какие-то принципиально недопустимы.

Спасибо за внимание!