Как я использую Copilot-cli: автоматизация контекста и строгие правила игры

ИИ-ассистенты прочно вошли в нашу рутину, но главная проблема при работе с ними — это потеря контекста и склонность ИИ «фантазировать», переписывая половину проекта ради одной мелкой фичи.

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

Шаг 1. Сначала план, потом код: rfc-cli

Самая частая ошибка — сразу просить Copilot написать код. Без четкого плана ИИ быстро уходит в сторону. Поэтому первое, что я делаю перед тем, как вообще открыть чат и сделать промт — создаю RFC (Request for Comments).

Для этого я использую rfc-cli — отличный консольный инструмент для управления архитектурными решениями прямо в репозитории.

Мой воркфлоу с RFC:

  1. Создание: Я инициализирую новый документ через rfc-cli new.
  2. Проработка: Набрасываю структуру, цели и изменения.
  3. Жизненный цикл: Документ строго проходит цепочку статусов: draft → review → accepted → implemented. Пропускать шаги нельзя.
  4. Валидация: После любых правок я проверяю целостность через rfc-cli check NNNN.

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

Шаг 2. Борьба с амнезией: mem-cli

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

Чтобы не терять данные между сессиями, я подключил mem-cli. Это простой, но чертовски эффективный MCP-сервер (Model Context Protocol), который работает как долговременная память.

Каждый раз, когда в процессе работы всплывает важный нюанс (например, “используем только порт 8080” или “компонент X временно не трогаем, он на рефакторинге”), я просто сохраняю этот факт в mem-cli. Copilot обращается к этой памяти и всегда остается в курсе реального положения дел в проекте.

Шаг 3. Свод правил (System Prompt) для Copilot

И последнее по списку, но не по важности — правила игры. Я скормил Copilot жесткий регламент, нарушать который ему строго запрещено. Мой системный промт разделен на три блока:

🛠 Код

Главная беда больших языковых моделей — оверинжиниринг. Чтобы Copilot не “умничал”, я установил для него жесткие рамки:

🌿 Git Workflow

Здесь всё автоматизировано до предела. Copilot знает, как я веду ветки и делаю релизы (на примере Rust-проекта):

  1. Никакой работы в main: Все изменения только через ветки. Перед созданием новой ветки от main создается метка с префиксом pre_.
  2. Дробление задач: Каждая фича — отдельный branch. Каждая подзадача — sub-branch в формате phase-N/X.Y-description.
  3. Контроль качества: Перед каждым коммитом — обязательный запуск тестов. Перед слиянием в main — полный цикл: build + test + lint. main всегда должен оставаться абсолютно “зеленым”.
  4. Релиз: Слияние происходит строго с флагом --no-ff. Перед мержем обновляется версия в Cargo.toml, пишется CHANGELOG.md на английском, а после успешного слияния вешается тег vX.Y.Z.

🧠 Стиль работы

Заключение

Интеграция rfc-cli для планирования, mem-cli для долгосрочной памяти и свода правил для дисциплины превратила Copilot-cli из “продвинутого автодополнения” в полноценного, аккуратного и очень предсказуемого junior-разработчика, который пишет код именно так, как нужно мне.