GitHub описал механизм canvases в GitHub Copilot app — настраиваемых интерфейсов, которые агент создаёт по текстовому описанию и открывает рядом с рабочей сессией. Такой canvas может выглядеть как канбан-доска, форма, таблица, панель для разбора задач или чеклист подготовки релиза.
Главное отличие от обычного ответа в чате заключается в общей рабочей области. Пользователь может нажимать кнопки, редактировать поля и перемещать карточки, а агент — видеть эти изменения и выполнять доступные в интерфейсе действия. По утверждению GitHub, отдельная отправка обновлённых данных или ручная синхронизация для этого не требуется.
Функция описана в официальной публикации GitHub от 25 сентября 2026 года. Это обучающий материал самой компании, а не независимое тестирование, поэтому заявленные возможности ещё предстоит проверять на реальных проектах.
Интерфейс создаётся командой внутри сессии
Для запуска используется команда `/create-canvas` в сессии агента. После неё разработчик описывает назначение панели, данные, которые нужно показать, и действия, доступные человеку и Copilot.
В качестве примера GitHub предлагает панель для заметок к релизу. Она может собирать сведения о завершённой работе, помогать просматривать и группировать записи, а также разрешать агенту добавлять или обновлять элементы. По описанию компании, Copilot самостоятельно формирует интерфейс и открывает его в правой части приложения: создавать файлы и вручную верстать элементы не нужно.
Первый результат не считается окончательным. Пользователь может попросить добавить колонку, фильтр или новый тип карточек, изменить расположение элементов либо превратить панель в чеклист. Агент должен перестроить canvas в соответствии с уточнением.
Фиксированного каталога макетов у функции нет. Это даёт свободу при проектировании узкого рабочего процесса, но одновременно делает результат зависимым от точности исходного описания. Чем яснее указаны сущности, поля и действия, тем проще проверить, соответствует ли созданная панель задаче.
Пользователь и агент работают с одним состоянием
Canvases, которые GitHub также называет canvas extensions, рассчитаны на двунаправленное взаимодействие. Если разработчик переносит карточку, меняет значение поля или нажимает кнопку, состояние панели обновляется и становится доступно агенту. В обратную сторону работает тот же принцип: Copilot может применить предусмотренное панелью действие, после чего результат появляется в интерфейсе.
Это отличает функцию от сценария, в котором пользователь вручную пересказывает агенту текущее состояние проекта. Например, вместо сообщения «задача перешла на проверку» можно переместить карточку в соответствующую колонку. Агент должен увидеть изменение в общей рабочей области.
Созданный canvas сохраняется как расширение. GitHub указывает два варианта: оставить его в проекте, чтобы использовать вместе с командой, или сохранить как личное расширение. Однако в исходной публикации не раскрыты все детали хранения данных: из неё нельзя определить, где именно сохраняется содержимое панели, как долго оно доступно между сессиями и какие ограничения действуют для командных проектов.
Эти вопросы особенно существенны, если canvas планируется использовать не как временный интерфейс, а как постоянный источник статуса. До переноса рабочего процесса стоит проверить поведение расширения после закрытия сессии, смены пользователя и повторного открытия проекта.
Где canvases могут оказаться полезны
Наиболее понятный сценарий — небольшая задача, для которой чат уже неудобен, а отдельная система управления избыточна. GitHub перечисляет несколько возможных форматов:
- доска для сортировки входящих issues;
- канбан с этапами выполнения задач;
- чеклист подготовки релиза;
- форма для структурированного ввода;
- таблица или дашборд с рабочими данными;
- панель для ведения release notes.
Canvas в таком случае становится визуальным слоем над взаимодействием с агентом. Разработчик получает элементы управления, а Copilot — структурированное состояние вместо длинной переписки.
При этом из анонса не следует, что canvas автоматически заменит GitHub Issues, системы CI/CD или специализированные сервисы управления проектами. Наличие доски ещё не подтверждает поддержку истории изменений, разграничения ролей, обязательных согласований, уведомлений и внешних интеграций. Подключение репозитория или других данных также следует оценивать отдельно с учётом доступных агенту разрешений.
Общие сведения о продукте и его вариантах доступны на странице GitHub Copilot, а требования и параметры использования стоит сверять с официальной документацией GitHub Copilot. Публикация о canvases не уточняет отдельную цену функции, перечень поддерживаемых тарифов или график её доступности для разных типов аккаунтов.
Готовые расширения можно взять из Awesome Copilot
Пользователям, которые не хотят начинать с пустого интерфейса, GitHub рекомендует коллекцию Awesome Copilot. В ней сообщество публикует материалы и расширения для работы с Copilot, включая примеры канбан-досок, инструментов для release notes и обработки issues.
Готовое расширение можно использовать как основу, а затем попросить агента адаптировать его к конкретному процессу. Такой подход позволяет быстрее получить рабочий прототип и одновременно увидеть, как организованы уже существующие canvases.
Установка стороннего расширения всё же требует обычной проверки кода и разрешений. Наличие проекта в публичной коллекции само по себе не гарантирует безопасность, поддержку или пригодность для корпоративной среды. Перед использованием с закрытым репозиторием стоит выяснить, к каким данным обращается расширение и какие действия оно предоставляет агенту.
Как проверить функцию без риска для рабочего проекта
Для первого теста лучше выбрать процесс, который не содержит секретов и не влияет на выпуск продукта. Например, можно создать локальный чеклист проверки небольшой задачи со статусом, ответственным и коротким комментарием.
В описании полезно сразу перечислить:
- назначение панели;
- нужные поля и колонки;
- действия, доступные пользователю;
- действия, которые разрешено выполнять агенту;
- условие, по которому задача считается завершённой.
После создания canvas следует провести двустороннюю проверку. Сначала вручную изменить поле или переместить карточку и убедиться, что Copilot учитывает новое состояние. Затем попросить агента выполнить конкретное действие через интерфейс и проверить, появилось ли изменение на панели. Наконец, нужно закрыть сессию и выяснить, сохраняются ли данные после повторного открытия.
До использования в командном процессе остаётся проверить права доступа, долговременное хранение состояния, журналирование действий и работу с реальными данными репозитория. Официальный материал GitHub объясняет базовую механику canvases, но не даёт достаточных оснований считать их полноценной заменой существующим системам управления разработкой.