11 сентября 2026 года GitHub в официальном блоге разобрала, как региональный маркетинг APAC собирает события из одного Issue: Copilot пишет черновик, Actions ставят лендинг и UTM, skills закрывают выгрузку в CRM. Пост Tomoko Tanaka, маркетингового лида GitHub по Японии и Корее: Marketing ops as code: Automating events from planning to follow-up on GitHub.
Это не новый id модели и не смена тарифа API. Внутренний контур на GitHub Copilot, GitHub Actions и issue forms. Автор прямо пишет: код она почти не писала. Она записала runbook, как уже делается работа, и отдала его Copilot.
Событие как Issue
У маркетинга GitHub уже была привычка открывать одно Issue на проект. Там живут план, обсуждение и статус. Tanaka сделала следующий шаг: Issue не описывает работу, а запускает её.
Три примитива, которые уже есть в репозитории:
- Issue forms вместо пустого текста: название события, дата, регион, имя кампании, аудитория. Отдельная форма на вебинар и на офлайн, дальше одна и та же машина.
- Лейблы как выключатели.
event-setupне метка «для красоты», а условие, по которому стартует workflow. - GitHub Actions разбирают поля формы и делают работу.
Без scriptable-входа схема не встанет. У их площадки событий есть API. CRM, по тексту, обошлась официальным CLI: ключ API не настраивали, вход через браузер. Формула одна: API или CLI. Если рутина ходит через инструмент без того и другого, этот пост её не автоматизирует.
Сначала разговор, потом машины
Пайплайн начинается до Issue. В Copilot roughly звучит так: хочу вебинар про AI-assisted development в ноябре. Дальше решает не «общая модель из головы», а файл AGENTS.md в корне репозитория: как называют кампании, как фискальные кварталы ложатся на даты, какой часовой пояс у региона, как выглядит нормальное приглашение.
Copilot читает runbook, находит похожее прошлое событие, предлагает имя кампании по правилам, набрасывает два варианта письма и задаёт вопросы, которые runbook велит задать. Жёсткий пайплайн ломается в день, когда это событие чуть другое. Ручное заполнение всех полей даёт опечатки в имени кампании, от которого зависят пятнадцать отчётов. Разговор стоит между двумя крайностями: шаблон держит формат, человек гнёт детали.
Деление труда Tanaka формулирует коротко: GitHub Copilot drafts, I decide. Имя кампании, тема письма, дата не уезжают дальше без подписи человека. В конце Copilot открывает Issue с нужными лейблами, и дальше работают машины.
Сначала этот разговор шёл в GitHub Copilot CLI, в терминале. Для автора это нормально, для части команды «открой терминал» уже барьер. Сейчас тот же разговор стоит в GitHub Copilot app: обычное десктоп-окно. На продуктовой странице приложение заявлено для macOS, Windows и Linux, на любом плане Copilot или со своим ключом.
Лейбл event-setup
Как только на Issue появляется event-setup, workflow за минуты делает то, что раньше занимало почти день:
- дублирует прошлое событие на площадке и получает новый лендинг;
- собирает полный набор UTM-ссылок, по одной на канал, в одном формате;
- кладёт приглашение в Word-документ и коммитит его в репозиторий;
- открывает request-Issue командам, которые рассылают письма и ведут региональный маркетинг;
- добавляет событие на project boards и заполняет поля;
- пишет summary-комментарий обратно в Issue, чтобы следующий человек видел всё в одном URL.
Скрининг регистраций идёт не от лейбла, а по расписанию. Каждое утро cron-workflow забирает свежий список по всем открытым событиям и публикует уже почищенный. Для закрытых сессий отдельно проверяет waitlist: разработчик с enterprise-аккаунта, студент или конкурент, которому очень хочется на executive briefing.
Отдельный выключатель: репозиторная переменная DRY_RUN. Если она включена, workflow проходит все шаги и не трогает внешние системы: ни лендинг, ни чужие Issue, ни расшаренные списки. Для команды, которая автоматизирует свою же работу, это репетиция, а не «сразу в бой».
Follow-up двумя командами
После события раньше была самая противная часть: выгрузка участников, перекладка колонок под CRM, сопоставление компаний с аккаунтами, отчёт. Теперь две команды.
/lead-uploadзабирает список, приводит его к формату маркетинговых операций, открывает request-Issue и закрывает трекинг./event-reportтянет метрики посещаемости и опросы и кладёт отчёт комментарием в то же Issue.
Это GitHub Copilot agent skills. Skill в этом тексте не «магический агент», а Markdown-файл SKILL.md: процедура, в каком порядке что делать и на что смотреть. По доке GitHub skill живёт в папке инструкций, скриптов и ресурсов; Copilot подхватывает его, когда задача подходит. Проектные skills кладут в репозиторий (.github/skills, .claude/skills или .agents/skills), личные в домашний каталог.
Почему follow-up не зашили в жёсткий Actions-пайплайн: в APAC нет одного рынка. Япония и Корея, разные сегменты, разные поля в CRM, разное определение «хорошего лида». Markdown-процедуру можно подогнать под рынок, не ломая машину под ним. Новые skills приходят pull request и проходят review, маршрутизация через CODEOWNERS.
Ещё побочный эффект skills: процедура стала именованной единицей работы, и модель можно подобрать под задачу из линейки, которую организация уже разрешила. Дешёвая быстрая чистит утренние списки, более сильная пишет тексты кампании. Какие именно id моделей Tanaka не публикует.
Если у вас сайт, бот или повторяющаяся рутина
Практический смысл не в слове marketing. Если у вас есть повторяющаяся цепочка через инструменты с API или CLI, лендинг, UTM, письмо, статус на доске, выгрузка в CRM, тот же каркас собирается без отдельной «маркетинговой платформы под ключ».
Tanaka предлагает начать с одной самой нудной задачи недели. Минимальная версия: issue form на входы, лейбл «поехали», Action на один шаг. Или сразу записать runbook как SKILL.md и дать Copilot его исполнять. Пока не доверяете, гоняйте с DRY_RUN.
Контур живёт в GitHub: Copilot, Actions, Issue, секреты репозитория. Боевой wp-admin, SSH и root в этом посте не фигурируют, и я бы не тащил туда списки регистраций и ключи площадки «на пробу».
Где обычно ломается ожидание. Пост не отдаёт их репозиторий, не публикует готовый SKILL.md для /lead-upload и не обещает, что ваш Bitrix24 или самописная форма заведутся сами. Нужны API или CLI у тех систем, которые вы трогаете. Skill Copilot не заменяет GitHub Actions: у них лейбл поднимает лендинг, skill закрывает follow-up. По доке skills работают с Copilot cloud agent, code review, CLI, Copilot app и agent mode в VS Code и JetBrains; cloud agent в этой же доке указан для платных планов Copilot. Весов модели нет. Self-host LLM в тексте нет.
Охрана, которую автор считает важной, уже была на платформе: secret scanning с push protection, чтобы токен не уехал в git; на бизнес-планах Copilot промпты не сохраняют и не пускают в обучение модели, поэтому разовый срез регистраций не надо нести в соседнюю вкладку с потребительским чатом. Какие модели доступны, решает политика организации, не личный вкус.
И честный сбой: утренний скрининг однажды молча не работал пять дней, пока списки не протухли. Автоматизация без сигнала «мне плохо» это бомба с задержкой. У каждого scheduled workflow должен быть способ пожаловаться громко.
Проверить руками, если Copilot и Actions у вас уже есть, можно на копии репозитория: одна форма, один лейбл, один шаг с DRY_RUN, один тестовый skill без боевых списков. Если внешняя система всё равно создала объект, выключатель не выключатель. Про доступ из России в первоисточнике ничего нет, гадать не буду.
Итог Tanaka спокойный: если умеете записать, как делается работа, её можно автоматизировать. Утренний список регистраций, скорее всего, на один записанный runbook ближе к тому, чтобы собираться сам. Это продуктовый кейс GitHub, не обещание, что агент сам ведёт ваши вебинары.
