Начало работы с Conductor для Gemini CLI

Когда вы запускаете Gemini CLI, описываете фичу, которую нужно реализовать, и агент немедленно приступает к написанию кода. Без вопросов, без уточнений, без плана. Через десять минут вы получаете сотню строк реализации в четырёх файлах, но ни одна из них не соответствует вашей реальной архитектуре, потому что агент её никогда не знал. Он делал правдоподобные предположения. Часть из них оказалась верной, но большинство — нет. Теперь вы разбираете сгенерированный ИИ код, гадая, не быстрее ли было написать всё самому.

Это не проблема самого Gemini. Это проблема контекста. Агент не знает, что вы строите, какие библиотеки выбрали, каких стандартов кодирования придерживаетесь и что именно должна делать фича. Каждый сеанс начинается с нуля.

Conductor, выпущенный в предварительной версии 17 декабря 2025 года, — это расширение Gemini CLI, созданное для решения этой проблемы. Он предлагает рабочий процесс под названием Context-Driven Development (CDD) — структурный подход, при котором контекст проекта, спецификации и планы реализации живут в Markdown-файлах внутри репозитория, а не внутри эфемерного окна чата. Агент читает эти файлы каждый раз, когда обращается к проекту. Ваши руководства по стилю, решения о технологическом стеке, продуктовые цели — всё это сохраняется и перемещается вместе с кодом.

На момент публикации репозиторий Conductor на GitHub собрал более 3600 звёзд и 284 форка. В апреле 2026 года вышел Google Codelab с полным разбором создания проекта с нуля при помощи Conductor. Эта статья охватывает всё, что нужно, чтобы пройти путь от нуля до запуска первого трека реализации.

Что на самом деле представляет собой Conductor

Прежде чем переходить к командам, полезно понять модель, на которой построен Conductor, потому что она меняет взгляд на разработку с помощью ИИ.

Стандартные процессы AI-кодинга не имеют состояния. Вы открываете сеанс, описываете, что хотите, агент работает, вы закрываете сеанс. В следующий раз агент ничего не помнит о том, что вы построили, зачем и что будет дальше. Как выразился один из разработчиков Google Cloud, модель «мимолётна, забывчива и немного ковбой».

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

Анонс Google цитирует фразу Бенджамина Франклина «не планировать — значит планировать провал», описывая философию Conductor, и это верно. Рабочий процесс Conductor таков: сначала строите контекст, затем описываете фичу, планируете реализацию и только потом пишете код. Именно в таком порядке, каждый раз.

Архитектурно Conductor работает как три слоя, действующих совместно.

• Слой команд — то, с чем вы взаимодействуете: шесть слэш-команд внутри Gemini CLI.
• Слой артефактов — каталог conductor/ в вашем репозитории, содержащий Markdown- и JSON-файлы, хранящие состояние проекта.
• Слой контроля версий — Git, который Conductor использует для создания коммитов на каждую задачу и поддержки функциональности отката.

Это работает как для greenfield-проектов (с нуля), так и для brownfield-проектов (существующие кодовые базы). Поддержка brownfield стоит внимания, потому что большинство уроков демонстрируют только проекты с чистого листа. Когда вы выполняете /conductor:setup в существующем репозитории, Conductor анализирует кодовую базу, учитывает шаблоны из .gitignore и .geminiignore и определяет технологический стек и архитектуру — поэтому вам не придется вручную заполнять контекст, который Conductor способен выяснить сам.

Необходимые условия и установка

Перед установкой Conductor вам понадобятся три вещи.

Gemini CLI должен быть установлен и работать. Установите его глобально через npm:

# Устанавливаем Gemini CLI глобально
npm install -g @google/gemini-cli
# Проверяем установку
gemini --version

Если возникнут ошибки прав доступа, используйте менеджер версий Node, например nvm, вместо запуска от root. После установки перезапустите терминал, чтобы бинарный файл gemini оказался в вашем PATH.

API-ключ Google или настройка Vertex AI необходимы для аутентификации Gemini CLI. При первом запуске gemini вам будет предложено пройти аутентификацию. Выберите Vertex AI и следуйте инструкции, чтобы задать переменную окружения GOOGLE_API_KEY, или выполните OAuth-авторизацию в браузере для личного использования.

Git должен быть инициализирован в каталоге вашего проекта. Conductor создаёт коммит для каждой задачи и полагается на Git для функции отката. Если вы начинаете новый проект:

# Инициализируем новый git-репозиторий, если ещё не сделали
mkdir my-project && cd my-project
git init
git commit --allow-empty -m "Initial commit"

Когда всё готово, установите Conductor:

# Устанавливаем расширение Conductor
gemini extensions install https://github.com/gemini-cli-extensions/conductor
# Флаг --auto-update обеспечивает автоматическое обновление Conductor до новых версий.
# Рекомендуется для большинства пользователей.
gemini extensions install https://github.com/gemini-cli-extensions/conductor --auto-update

Установка загружает расширение из репозитория GitHub, регистрирует шесть команд Conductor, настраивает контекстный файл GEMINI.md как точку входа и задаёт /conductor в качестве каталога планов. Весь процесс занимает несколько секунд.

Проверьте успешность установки, запустив Gemini CLI и введя /conductor:

gemini

Затем внутри сеанса Gemini CLI:

/conductor

Вы должны увидеть полный список подкоманд: setup, newTrack, implement, status, revert и review. Если они появились — вы готовы к работе.

Настройка проекта с помощью /conductor:setup

Запустите эту команду один раз для каждого проекта. Именно она строит фундамент, от которого зависит всё остальное. В сеансе Gemini CLI из каталога вашего проекта выполните:

/conductor:setup

Conductor сразу же начнёт анализировать проект. Для brownfield-проекта он сканирует кодовую базу, чтобы определить, с чем работает, учитывая .gitignore для исключения тяжёлых по токенам каталогов вроде node_modules или __pycache__. Для нового проекта он попросит вас описать, что вы создаёте.

В любом случае затем он проведёт вас через управляемый опросник, чтобы заполнить шесть артефактов, которые создаст внутри нового каталога conductor/:

conductor/
├── product.md            # Концепция продукта, пользователи, цели, ключевые функции, критерии успеха
├── product-guidelines.md # Стандарты интерфейса, тон общения, обработка ошибок
├── tech-stack.md         # Языки, фреймворки, базы данных, инфраструктура
├── workflow.md           # Предпочтения по TDD, стратегия коммитов, протокол верификации
├── code_styleguides/     # Руководства по стилю для конкретных языков (автоматически генерируются под найденные языки)
│   ├── python.md
│   ├── typescript.md
│   └── ...
└── tracks.md             # Главный реестр всех треков (изначально пуст)

Каждый артефакт играет свою роль. product.md отвечает на вопрос «что мы строим и для кого». tech-stack.md гарантирует, что агент никогда не предложит библиотеку или паттерн за пределами вашего стека. workflow.md — это место, где вы определяете, хотите ли вы разработку через тестирование (TDD), как выглядит стратегия коммитов и какие шаги ручной проверки требуются перед переходом между этапами. В code_styleguides/ лежат руководства по стилю для конкретных языков, для которых Conductor поставляется с предзаполненными шаблонами, а вы можете их настроить.

Когда настройка завершится, вы увидите каталог conductor/ в вашем проекте. Зафиксируйте его:

# Коммитим контекст Conductor в репозиторий
git add conductor/
git commit -m "chore: initialize Conductor context-driven development"

С этого момента любой член команды, клонировавший репозиторий и открывший Gemini CLI, сразу получает полный контекст проекта — никаких дополнительных онбординговых бесед.

Запуск фичи командой /conductor:newTrack

Трек — это то, как Conductor представляет единицу работы. Одна фича, одно исправление ошибки, одно архитектурное изменение — один трек. Треки задают агенту чёткие границы, что не позволяет ему отклоняться от задачи.

Запустите трек, описав, что вы хотите построить:

/conductor:newTrack "Добавить переключатель тёмной темы на страницу настроек и сохранять выбор в localStorage"

Вы также можете вызвать /conductor:newTrack без аргумента и описать фичу интерактивно, когда Conductor запросит описание.

Conductor берёт ваше описание, считывает полный контекст проекта из conductor/ и генерирует три файла внутри нового каталога conductor/tracks/<track_id>/:

conductor/tracks/
└── dark_mode_20260614/
    ├── spec.md        # «Что и зачем» — требования, цели, технические ограничения, вне рамок
    ├── plan.md        # Поэтапный чеклист реализации с задачами
    └── metadata.json   # Идентификатор трека, дата создания, текущий статус

Формат идентификатора трека — shortname_YYYYMMDD, например dark_mode_20260614 для трека тёмной темы, созданного 14 июня 2026 года. Это сохраняет треки в хронологическом порядке в файловой системе.

spec.md содержит спецификацию: какую проблему это решает, каковы цели, технические требования и — что особенно важно — что НЕ входит в задачу. Раздел «out of scope» ценнее, чем кажется: он не даёт агенту начать украшать фичу вместо того, чтобы её выпустить.

plan.md — это чеклист реализации, организованный по фазам. Для переключателя тёмной темы он может выглядеть так:

# План реализации — Переключатель тёмной темы

## Фаза 1: Фундамент
- [ ] Задача: Добавить ключ `theme` в схему localStorage и описать его в README проекта
- [ ] Задача: Создать хук `useTheme`, который читает/записывает значение `theme` и по умолчанию ориентируется на системные настройки
- [ ] Задача: Написать модульные тесты для `useTheme` — проверить поведение по умолчанию, чтение из localStorage, запись в localStorage
- [ ] Задача: Conductor — Ручная проверка 'Фундамент' (протокол из workflow.md)

## Фаза 2: UI-компонент
- [ ] Задача: Создать компонент `ThemeToggle` с доступной кнопкой переключения (aria-label, поддержка клавиатуры)
- [ ] Задача: Применить условные CSS-классы в зависимости от текущей темы из `useTheme`
- [ ] Задача: Написать компонентные тесты для `ThemeToggle` — проверка отрисовки, отработка клика
- [ ] Задача: Conductor — Ручная проверка 'UI-компонент' (протокол из workflow.md)

## Фаза 3: Интеграция в страницу настроек
- [ ] Задача: Импортировать `ThemeToggle` в компонент страницы настроек
- [ ] Задача: Проверить, что настройка сохраняется при обновлении страницы и в новых вкладках браузера
- [ ] Задача: Написать интеграционный тест для страницы настроек с включённой тёмной темой
- [ ] Задача: Conductor — Ручная проверка 'Интеграция страницы настроек' (протокол из workflow.md)

Прочитайте этот план до того, как выполните /conductor:implement. Это специально заложенный момент участия человека. Если фазы неверны, задача пропущена или объём шире, чем вы предполагали, отредактируйте plan.md сейчас. Как только вы запустите implement, Conductor начнёт коммитить код по этому плану. Изменить курс на середине реализации можно, но это сложнее, чем заметить проблему на этом этапе.

Реализация: команда /conductor:implement

Когда план вас устраивает:

/conductor:implement

Именно здесь Conductor раскрывает себя по-настоящему. Он читает plan.md, берёт первую невыполненную задачу и начинает методично проходить список. Приступая к задаче, он меняет флажок с [ ] на [~] (в процессе). По завершении задачи он ставит [x] и создаёт git-коммит — один коммит на каждую выполненную задачу. Не на фазу, не на сеанс, а на задачу.

Вы увидите, как накапливаются коммиты по мере работы Conductor:

git log --oneline

Пример вывода:

a3f9c12 feat(theme): write integration test for settings page dark mode
b7e2d45 feat(theme): import ThemeToggle into Settings page
c1a8f90 feat(theme): add accessible toggle button with aria-label and keyboard support

Вспомогательные команды

Три основные команды — setup, newTrack, implement — покрывают главный рабочий процесс. Эти четыре обслуживают всё, что вокруг него.

/conductor:status

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

/conductor:status

Conductor читает conductor/tracks.md и plan.md каждого активного трека и возвращает сводку:

Current Date/Time: Saturday, June 14, 2026
Project Status: 🟡 Active
Active Tracks:
  * dark_mode_20260614 -- Phase 2 of 3 | 7/12 tasks complete (58%)
  * api_auth_20260610 -- Phase 1 of 4 | 3/5 tasks complete (60%)
Next Action Needed:
  * Run /conductor:implement to continue dark_mode_20260614 (current track)

Это та команда, которую нужно выполнить, когда вы возвращаетесь после перерыва и хотите вспомнить, на чём остановились.

/conductor:revert

Если что-то пошло не так и нужно отменить работу:

/conductor:revert

Conductor осознаёт Git так, как не способен чистый git revert. Он понимает логические единицы работы — треки, фазы, отдельные задачи, а не просто хеши коммитов. Если вы хотите откатить последнюю фазу трека, Conductor определяет коммиты, относящиеся к этой фазе (благодаря своей структуре «один коммит на задачу»), и чисто их отменяет. Он также обновляет plan.md, снимая галочки с затронутых задач, так что вы можете снова запустить /conductor:implement, чтобы переделать работу.

Это важно на практике, потому что откат по хешам коммитов, когда агент затронул 11 файлов в 14 коммитах за три фазы, превращается в ручную пытку. Conductor делает всю «археологию» за вас.

/conductor:review

После завершения реализации, перед созданием pull request:

/conductor:review

Conductor считывает завершённый plan.md вместе с conductor/product-guidelines.md и выполняет проверку качества. Он ищет расхождения между тем, что было указано в плане, и тем, что реализовано, а также нарушения продуктовых рекомендаций — непоследовательную обработку ошибок, отсутствие атрибутов доступности, отступления от руководства по стилю.

Представьте это как ИИ-рецензента, который прочёл всю вашу продуктовую спецификацию и точно знает, что фича должна была делать. На выходе — отчёт о проверке, который вы можете учесть до слияния кода.

Проверка расхода токенов

Контекстно-ориентированный подход Conductor читает файлы проекта при каждой команде, что увеличивает потребление токенов — особенно для крупных проектов на этапах настройки и планирования. Проверьте использование в текущем сеансе командой:

/stats model

Как Conductor работает в команде

Одна из самых недооценённых особенностей рабочего процесса Conductor заключается в том, что происходит, когда вы коммитите каталог conductor/.

Каждый файл, который создаёт Conductor — product.md, tech-stack.md, workflow.md, руководства по стилю, каждый трек и план — живёт в репозитории как любой другой файл. Когда коллега подтягивает репозиторий, он мгновенно получает весь контекст проекта. Открыв Gemini CLI и запустив /conductor:status, он видит все активные треки и точный прогресс по каждому.

Это меняет онбординг. Новому разработчику, присоединившемуся к проекту, не нужен двухчасовой обзор, чтобы понять выбор технологического стека, стандарты кодирования или то, какие фичи находятся в работе. Достаточно прочесть conductor/product.md и conductor/tech-stack.md, запустить /conductor:status — и у него есть полная оперативная картина.

Преимущество в согласованности не менее значимо. Каждый вклад в проект, сделанный с помощью ИИ, следует одним и тем же стандартам, потому что каждый сеанс агента читает одни и те же контекстные файлы. Conductor-сессия одного разработчика пишет код в том же стиле, что и сессия другого, поскольку обе привязаны к одной и той же директории code_styleguides/. Это то свойство «командной гармонии», которое становится всё труднее поддерживать с ростом масштаба, — Conductor встраивает его в рабочий процесс структурно, а не полагается на ручные усилия разработчиков.

Полный пошаговый пример: добавляем переключатель тёмной темы

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

Шаг 1: Откройте Gemini CLI из каталога проекта

cd your-project
gemini

Шаг 2: Если вы ещё не настраивали Conductor для этого проекта, выполните setup

/conductor:setup

Ответьте на задаваемые вопросы. Когда закончите, закоммитьте каталог conductor/.

Шаг 3: Создайте трек

/conductor:newTrack "Добавить переключатель тёмной темы на страницу настроек, сохраняя выбор пользователя в localStorage и используя системную тему по умолчанию при первом визите"

Conductor сгенерирует spec.md и plan.md в conductor/tracks/dark_mode_20260614/.

Шаг 4: Прочитайте план до запуска чего-либо

Откройте plan.md в редакторе. Прочитайте каждую задачу. Убедитесь, что фазы логичны. Если что-то не так — пропущена задача, неверная фаза, слишком широкий объём — отредактируйте файл сейчас и сохраните. Conductor читает файл заново при каждом запуске, поэтому ваши правки вступят в силу немедленно.

Шаг 5: Запустите реализацию

/conductor:implement

Смотрите, как Conductor проходит по задачам, создавая коммиты. В конце Фазы 1 он сделает паузу и попросит вас проверить результат вручную. Протестируйте работу. Когда вы подтвердите, что всё в порядке, Conductor перейдёт к Фазе 2.

Шаг 6: Проверяйте прогресс в любой момент

/conductor:status

Шаг 7: Проверьте завершённую реализацию

/conductor:review

Устраните замечания, выявленные при проверке. Затем создайте pull request с чистой реализацией, полным набором тестов, историей Git, организованной по задачам, и спецификацией, которая документирует, что именно было построено и почему.

Весь поток — от настройки до ревью — повторяем для каждой следующей фичи. Каталог conductor/ разрастается как живая история того, что было построено, почему было принято каждое решение и каких стандартов придерживается проект.

Несколько важных моментов перед началом

• Потребление токенов реально. Conductor читает файлы контекста проекта при каждой команде. Для небольшого проекта это незначительно. Для крупного brownfield-проекта со множеством треков в каталоге conductor/ расход заметен — особенно на этапах настройки и планирования. Используйте /stats model, чтобы отслеживать использование, и подумайте о регулярной архивации завершённых треков, чтобы поддерживать активный tracks.md компактным.
• Флаг --auto-update стоит использовать. Conductor находится в режиме предварительного просмотра, и с декабря 2025 года релизы выходят часто. Флаг --auto-update означает, что вы будете получать улучшения автоматически, без ручной переустановки.
• Качество контекста определяет качество результата. Это обратная сторона контекстно-ориентированной разработки. Расплывчатый product.md порождает расплывчатое планирование. tech-stack.md, в котором не указан используемый фреймворк тестирования, приводит к планам, которые его угадывают. Время, потраченное на артефакты настройки, окупается на каждом последующем треке.
• Conductor не заменяет код-ревью. /conductor:review — полезный инструмент для выявления очевидных расхождений и проблем со стилем, но он не подменяет ревью человеком перед слиянием кода. Относитесь к нему как к первой проверке, а не к финальному фильтру.

Заключение

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

Google формулирует роль Conductor так: он «относится к вашей документации как к источнику истины» и «позволяет Gemini действовать как подлинное расширение вашей инженерной команды». Это верно, но более практично думать о нём так: Conductor делает поведение агента предсказуемым. А предсказуемость — именно то, что нужно, когда агент пишет код, который пойдёт в продакшен.

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

Установите его, выполните /conductor:setup на вашем следующем проекте и посмотрите, как выглядит план до того, как будет написана первая строка кода.

Ресурсы

• Репозиторий Conductor на GitHub
• Блог Google Developers — анонс Conductor
• Google Codelab — Планирование и создание приложений с Gemini CLI Conductor
• Директория расширений Gemini CLI