GitHub опубликовал материал о том, как автоматизировать маркетинговые процессы с помощью GitHub Copilot и GitHub Actions, практически не пиша код. В центре кейса — работа регионального маркетолога GitHub по Японии и Корее, который отвечает за вебинары, митапы и закрытые мероприятия для разработчиков и ИТ‑руководителей.
Автор объясняет, что после утверждения события всегда запускается фиксированная цепочка действий: настройка страниц регистрации, кампаний в CRM, рассылок, списков участников и отчётности. Каждое действие само по себе простое, но легко ошибиться с ссылкой, датой или названием кампании, от которого зависят десятки отчётов.
Основная идея подхода — рассматривать GitHub Issue как «единицу работы» и превратить её в точку автоматизации. Маркетинговая команда и раньше открывала по одному Issue на проект, где велись планирование, обсуждение и статус. Теперь Issue не только описывает процесс, но и запускает его: при появлении определённой метки GitHub Actions берет задачу в работу.
Ключевое условие — у используемых инструментов должен быть скриптуемый доступ. В примере это платформа управления мероприятиями с API и CRM‑система с официальной CLI‑утилитой, которая авторизуется через браузер и не требует ручной настройки ключей. Такой подход можно перенести на любые сервисы с API или CLI: формы, аналитику, платформы событий.
Автор признаёт, что классические маркетинговые платформы автоматизации могли бы закрыть часть задач, но объясняет выбор собственного сценария. В регионе APAC каждое направление использует разные языки, сегменты и критерии лидов, а настройка готового решения под все варианты потребовала бы бюджетов на доработку и ожидания реализации в чужой продуктовой дорожной карте. Внутренняя сборка на GitHub позволяет вносить изменения через pull request: маркетолог описывает желаемое поведение, коллега проводит ревью, а изменения попадают в основную ветку так же, как код.
Пайплайн начинается ещё до создания Issue. Маркетолог открывает GitHub Copilot и в свободной форме формулирует задачу, например: «провести в ноябре вебинар об AI‑ассистированном развитии». На этом этапе Copilot опирается на файл AGENTS.md в корне репозитория. В нём в формате Markdown описаны правила именования кампаний, календарь кварталов, часовые пояса по регионам и структура удачного письма‑приглашения.
GitHub Copilot читает AGENTS.md, находит похожие прошлые события, предлагает имя кампании по правилам, подготавливает несколько вариантов писем и задаёт уточняющие вопросы, которые предусмотрены «руководством». Оформленная в виде диалога стадия решает сразу две задачи: уменьшает число ошибок в данных и сохраняет гибкость, позволяя отклоняться от шаблона для отдельных событий, не ломая автоматизацию дальше по цепочке.
Первоначально эта беседа проходила в GitHub Copilot CLI через терминал. Позже её перенесли в настольное приложение GitHub Copilot, чтобы снять барьер для коллег, которым некомфортно работать в консоли. Требование к навыкам снизилось с «уметь пользоваться shell» до «уметь печатать запросы в обычном окне».
Маркетолог подчёркивает разделение ролей между человеком и ИИ. GitHub Copilot только предлагает черновики: названия кампаний, темы писем, даты. Каждое ключевое решение остаётся за человеком и проходит явное согласование. Лишь после этого Copilot создаёт GitHub Issue с нужными метками, после чего управление переходит к GitHub Actions.
Как только Issue получает метку event-setup, автоматически запускается workflow в GitHub Actions. За несколько минут он выполняет то, на что раньше уходил почти целый день: создаёт страницу события, настраивает кампанию в CRM, готовит списки рассылок, связанные задачи и необходимые артефакты.
Скрининг регистраций вынесен в отдельный сценарий, который работает по расписанию. Каждое утро срабатывает cron‑триггер: Action получает новый список зарегистрировавшихся для всех активных событий, очищает данные и публикует результат. Для мероприятий по приглашению та же процедура проверяет waitlist по заданным критериям (например, разработчик из крупной компании, студент или конкурент) до одобрения участия.
Важное элемент архитектуры — единый переключатель DRY_RUN, реализованный как переменная репозитория. Каждый workflow перед выполнением проверяет его значение. Если DRY_RUN включен, сценарии проходят все шаги без внешних эффектов: не создаются посадочные страницы, не открываются Issue в других репозиториях, не рассылаются списки. Такой режим «репетиции» позволил маркетинговой команде уверенно экспериментировать с автоматизацией и отлаживать её без риска.
Послевыставочная работа раньше была самым трудоёмким этапом: выгрузка участников, приведение таблиц к формату CRM, сопоставление компаний с учётными записями и написание отчёта. Сейчас этот блок свели к двум командам. Команда /lead-upload получает список посетителей, подгоняет формат под требования маркетинговой операционной команды, создаёт запрос в виде Issue и закрывает трекинговые задачи. Команда /event-report собирает показатели посещаемости и результаты опросов, а затем публикует отчет в комментарии к тому же Issue, где хранится вся история события.
Эти действия реализованы как навыки (skills) GitHub Copilot. Каждый навык — это файл SKILL.md с текстовой инструкцией, которая описывает последовательность действий и важные нюансы. По сути, это те же runbook‑описания, которыми раньше пользовались инженеры, только теперь их выполняет агент GitHub Copilot.
Навыки обеспечивают гибкость системы. В разных странах APAC‑региона отличаются аудитории, сегменты и подходы к последующей коммуникации. Жёстко зашитый конвейер заставил бы всех работать по одному шаблону. Пошаговое описание в Markdown можно подстроить под локальные требования, не трогая базовую инфраструктуру. Поэтому особенно вариативные части — например, пост‑ивент — вынесены в skills, а не в фиксированные workflow.
К навыкам применяются те же правила, что и к коду. Новые SKILL.md попадают в репозиторий только через pull request, проходят ревью и действуют после слияния. Файл CODEOWNERS направляет запросы на проверку к ответственным. В результате маркетинговая автоматизация получает встроенный процесс согласования без отдельной системы управления изменениями.
Автор отмечает, что смог автоматизировать работу с клиентскими данными и учётными записями в репозитории, доступном всей команде, почти без написания кода. Раньше такой сценарий казался рискованным, но на практике сыграли защитные механизмы, уже присутствующие в платформе. К самодельным защите относятся DRY_RUN, тесты на каждый pull request и обязательный код‑ревью, которые одинаково хорошо страхуют и программный код, и маркетинговые сценарии.
Отдельно перечисляются защитные механизмы, которые предоставляет сам GitHub. Они включают управление доступом к репозиториям и секретам, стандартные средства аудита и наблюдаемости, а также инфраструктуру для безопасного запуска GitHub Actions. Эти возможности не пришлось разрабатывать с нуля, достаточно было встроиться в них.
Формат skills дал ещё одно преимущество. Поскольку каждый навык — определённая, именованная задача, можно выбирать подходящую модель ИИ под конкретную операцию из перечня, одобренного в организации. Например, более быстрая и дешёвая модель обрабатывает ежедневную очистку списков, а более мощная используется для подготовки текстов кампаний.
Автор честно описывает и сбой: утренний сценарий проверки регистраций пять дней не выполнялся, а команда заметила проблему только по устаревшим спискам. Вывод: автоматизацию нужно мониторить, иначе она превращается в отложенный источник сбоев. Для всех задач по расписанию необходимо предусмотреть механизм громких уведомлений о неуспехе.
В заключении автор предлагает подход коллегам, чья работа включает повторяющиеся действия. Рекомендуется выбрать самую рутинную задачу недели и проверить, есть ли у используемых инструментов API или CLI. Далее — собрать минимально жизнеспособную версию: форму Issue для входных данных, метку, которая означает запуск, и Action, выполняющий хотя бы один шаг процесса.
Альтернативный старт — сразу описать процедуру в SKILL.md и поручить её выполнение GitHub Copilot с включенным режимом DRY_RUN до появления доверия к автоматизации. Потом можно постепенно расширять покрытие. По сути, достаточно формализовать знания о том, как выполняется работа, в виде понятного runbook, а платформа возьмёт на себя остальное.
В материале также напоминается, что GitHub развивает GitHub Copilot как платформу для агентных сценариев, в том числе с параллельным выполнением агентов, встроенной проверкой кода, интеграцией с терминалом и предпросмотром веб‑приложений. Отдельно подчёркивается роль GitHub Actions как базового инструмента для автоматизации рабочих процессов в крупных организациях.
Источник: материалы GitHub.
