Интеграция GitHub в Slack и Teams вышла в общий доступ

GitHub 6 ноября объявила общий выпуск интеграции @GitHub в Slack и Microsoft Teams. Из командной переписки можно начать исследование ошибки, подготовить план, поручить изменение кода и открыть pull request. В Teams добавлен Canvas для совместного просмотра планов, изменений и предпросмотров рядом с беседой. Анонс GitHub от 6 ноября.

Как обсуждение превращается в задачу

Интеграция связывает переписку команды с Copilot cloud agent. Пользователь упоминает @GitHub, указывает репозиторий и описывает, что нужно сделать. Дальше можно уточнять план и проверять результат в той же рабочей беседе. Работа агента выполняется в облачной среде, поэтому участникам не требуется держать локальный терминал открытым.

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

Что нового в выпуске от 6 ноября

GitHub упростила старт сессии: интеграция определяет репозиторий из сообщения и уменьшает число повторных действий при запуске. В анонсе отмечены исправления ответов на последующие сообщения. В описаниях созданных issues и pull requests теперь указывается, из беседы Slack или Teams и по запросу какого пользователя они появились.

Для командной работы такая связь помогает восстановить происхождение изменения. Ревьюер может увидеть, какая переписка стала основанием для задачи, а участники — сопоставить результат с договорённостями. Если обсуждение менялось, полезно зафиксировать итоговую формулировку перед запуском реализации, чтобы противоречащие друг другу сообщения не остались единственным описанием требований.

Slack и Teams показывают работу по-разному

В Slack для задачи создаётся отдельный кодовый канал Slack Code. В нём отображаются репозитории, ветки, ссылки и состояние сессии. Документация предлагает вести дальнейшее управление задачей через этот канал. После завершения канал можно архивировать, сохранив доступ к истории. Работа Copilot cloud agent в Slack.

В Teams ход работы можно отслеживать через Canvas. Рядом с разговором команда получает место для просмотра плана и результата. Это особенно удобно, когда несколько участников уточняют одно изменение: обсуждение требований и проверка артефакта оказываются рядом. Уточнения можно отправлять по мере выполнения сессии. Работа Copilot cloud agent в Teams.

Кому доступна интеграция

Актуальные инструкции GitHub указывают платные планы Copilot. Нужно установить приложение GitHub в рабочее пространство или команду и связать аккаунт GitHub. В организации доступ может ограничиваться её политиками. Поэтому перед первым заданием стоит проверить не только наличие приложения в чате, но и права связанного аккаунта на выбранный репозиторий.

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

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

Какой контекст получает агент

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

Это особенно важно для каналов, в которых смешиваются техническая задача и сведения клиента. Для агента лучше подготовить достаточное описание ошибки, ссылки на нужный код и ожидаемый результат. Тогда при проверке можно сравнить изменение с конкретными условиями. Участникам также проще понять, какие сообщения относятся к выполнению задачи, а какие остаются общим обсуждением.

От плана до pull request

GitHub описывает отдельные этапы исследования, планирования и изменения кода. Можно сначала задать вопрос о репозитории, затем согласовать подход и перейти к реализации. После этого пользователь просматривает diff и решает, нужны ли уточнения или создание pull request. Если PR требуется сразу, это можно включить в задание. Исследование, план и проверка изменений.

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

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

Что проверить команде перед рабочим использованием

Зафиксируйте, кто принимает итоговую правку.

Начните с одного репозитория, одного канала и небольшого изменения. Посмотрите, как выбирается репозиторий, кто может направлять сессию и где виден её статус. Затем проверьте переход от плана к diff и создание pull request. Так получится проследить путь задачи от сообщения до артефакта в GitHub.

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