Гайд · TNWS AI
Как настроить автоматическую разметку issue через Copilot Automations
Создание Copilot Automation для triage новых issue: trigger, search filter, prompt, минимальные tools, Run now и контроль результата.
Проверено 13 сентября 2026 года. Этот материал решает конкретную задачу: автоматически классифицировать новые issue как bug, enhancement или needs-info, не давая агенту права менять код. Все команды, пути и названия элементов интерфейса ниже сверены с официальной документацией GitHub на дату проверки. Функции со статусом preview могут измениться, поэтому перед внедрением в рабочий процесс повторно откройте первоисточник.
Когда этот сценарий действительно нужен
Используйте подход, когда задача повторяется, имеет проверяемый результат и требует заранее ограничить область действий агента. Он особенно полезен для репозитория, где изменения проходят через pull request, тесты и ревью. Не начинайте с широкого поручения «улучши проект»: зафиксируйте один наблюдаемый результат, допустимые файлы, запрещённые действия и способ проверки.
Практический ориентир: Copilot Automations доступны для private и internal repositories при включённом cloud agent; их создают Repository → Agents → Automations → Create new. Триггер When an issue is created поддерживает search query filter. Инструменты определяют возможные действия, а Run now запускает немедленный тест.
Перед началом сохраните чистое состояние ветки, убедитесь, что тестовый пример не содержит реальных секретов, и выберите небольшой репозиторий или отдельную ветку. GitHub Copilot ускоряет действия, но не заменяет контроль прав, review diff и проверку фактического результата.
Подготовка рабочего примера
Создайте тестовую задачу, по которой можно однозначно сказать «выполнено» или «не выполнено». Запишите исходное состояние: ветку, команду git status --short, относящиеся файлы и одну команду проверки. Если работа происходит в интерфейсе GitHub, заранее создайте отдельный issue или pull request без чувствительных данных. Не используйте production-token в тексте prompt, issue, комментарии или session log.
Определите границы в четырёх строках: цель; разрешённые файлы или действия; прямые запреты; проверка. Такая структура снижает риск красивого, но непроверяемого результата. Для примера этой статьи исходная задача выглядит так:
Title: Checkout returns 500. Body: После обновления POST /checkout падает. Версия приложения не указана, шаги и request ID отсутствуют.
Пошаговая настройка
- Проверьте, что repository private или internal, Copilot cloud agent включён, а у вас есть write access.
- Откройте главную страницу repository, затем Agents → Automations → Create new.
- Назовите автоматизацию
Issue triage, выберите When an issue is created и при необходимости задайте search query filter. - Вставьте строгий prompt классификации и разрешите только инструмент обновления labels; не включайте push changes или create pull request.
- Нажмите Create automation, затем откройте её и выполните Run now. Проверьте session log и тестовый issue.
После каждого значимого шага проверяйте не только сообщение агента, но и состояние системы: содержимое файла, список разрешений, session log, diff или метки issue. Успешная фраза в интерфейсе не доказывает, что ограничение действительно сработало.
Готовый шаблон для копирования
Скопируйте шаблон и замените только предметную часть. Не удаляйте ограничения и блок проверки, пока не получите стабильный результат на тестовом кейсе.
Классифицируй новый issue, используя только его title и body.
Разрешён ровно один основной label: bug, enhancement или needs-info.
bug — описано наблюдаемое неправильное поведение и ожидаемый результат.
enhancement — запрошена новая возможность без текущей неисправности.
needs-info — недостаточно шагов, окружения или ожидаемого результата.
Не меняй код, не создавай pull request и не закрывай issue.
Добавь короткий комментарий с причиной выбора. Если уверенности нет, выбери needs-info и перечисли недостающие данные.
Если в шаблоне указан путь, команда или имя label, они должны существовать в вашем репозитории. Не просите модель «догадаться» о названии теста или utility, когда это можно проверить поиском по коду. Любое разрешение на изменение стоит связывать с узкой папкой или типом объекта.
Реалистичный вход и ожидаемый результат
Вход: Title: Checkout returns 500. Body: После обновления POST /checkout падает. Версия приложения не указана, шаги и request ID отсутствуют.
Ожидаемый результат: Automation выбирает needs-info, добавляет краткое объяснение и просит версию, воспроизводимые шаги и идентификатор запроса; код и статус issue не меняются.
Сравнивайте результат по наблюдаемым признакам. Для файловой задачи это состав diff и exit code теста; для настройки — фактический effective policy; для GitHub UI — созданная session, выбранные tools, label или связанный pull request. Формулировка «вроде сработало» не годится для приёмки.
Как провести негативный тест
Сессии automation видимы участникам с доступом к repository. Не помещайте токены или пароли в prompt; для чувствительных значений используйте repository secrets.
Негативный тест нужен до распространения настройки на команду. Он должен пытаться нарушить ровно одну границу: изменить запрещённый файл, обратиться к сети, исполнить текст как команду, добавить лишнюю метку или расширить diff. Хорошая конфигурация либо блокирует действие, либо требует явного подтверждения, либо останавливается и объясняет ограничение.
Сохраните результат негативного теста рядом с документацией процесса: исходный prompt, дату, ожидаемое ограничение, фактическое поведение и решение. Это помогает повторить аудит после обновления Copilot или GitHub CLI.
Проверка безопасности и качества
Принцип минимальных прав важнее удобства первого запуска. Разрешайте только те tools, каталоги и сетевые направления, без которых задача действительно не выполняется. Не вставляйте секреты в prompt: сообщения, журналы сессии, issue и pull request могут быть доступны другим участникам репозитория в соответствии с настройками GitHub.
Перед merge прочитайте весь diff. Проверьте новые зависимости, workflow, конфигурацию, lock-файлы, скрипты и обращения к сети. Запускайте узкие тесты, связанные с изменением, а затем обязательный набор проекта. Если агент сообщает о тесте, убедитесь, что в логе есть точная команда и успешный код завершения, а не только пересказ.
Для preview-возможностей заведите владельца настройки и дату следующей проверки документации. Не фиксируйте цены или квоты в постоянной инструкции: они меняются. В этой статье наличие и статус функций проверены 13 сентября 2026 года; актуальные условия следует смотреть по ссылкам ниже.
Чек-лист финальной проверки
- Цель описана одним измеримым результатом.
- Указаны допустимые файлы, объекты или действия.
- Явно перечислены запрещённые действия.
- Команды, пути и названия UI сверены с официальной документацией.
- В prompt и тестовых данных нет токенов, паролей и персональных данных.
- Выданы только минимально необходимые permissions или tools.
- Исходное состояние ветки или объекта сохранено.
- Выполнен позитивный тест на реалистичном входе.
- Выполнен негативный тест на нарушение одной границы.
- Проверен фактический diff, log, policy или набор labels.
- Записана точная команда проверки и её exit code.
- Не появились неожиданные зависимости, workflow или сетевые обращения.
- Результат прошёл человеческое ревью.
- Для preview-функции назначена дата повторной сверки документации.
Частые вопросы
Можно ли считать сообщение Copilot доказательством успешной настройки?
Нет. Проверяйте внешний результат: файл и diff, вывод команды, effective policy, session log, label или pull request. Текстовый отчёт агента — только указатель, а не доказательство.
Нужно ли давать агенту все доступные tools для надёжности?
Нет. Избыточные инструменты увеличивают область возможной ошибки. Начните с минимального набора и добавляйте разрешение только после воспроизводимого блокера.
Где хранить секрет, если он нужен задаче?
Не помещайте его в prompt, issue или комментарий. Используйте поддерживаемый механизм secrets для выбранного окружения и ограничьте доступ конкретной задачей. Логи также проверяйте на случайный вывод значения.
Что делать, если интерфейс или команда отличаются от статьи?
Остановитесь и откройте официальный источник. Функция могла измениться после 13 сентября 2026 года, особенно если помечена preview или experimental. Не подбирайте похожую кнопку наугад.
Как понять, что инструкция слишком широкая?
Признаки: агент меняет несвязанные файлы, устанавливает пакеты без необходимости, создаёт новые архитектурные слои или не может назвать точную проверку. Сузьте цель, область файлов и критерии приёмки.
Официальные источники
Источники проверены 13 сентября 2026 года. Текст выше является самостоятельной практической инструкцией и не заменяет чтение актуальных требований GitHub для вашей организации и плана.
Читайте также
Как архивировать остановленную сессию Copilot cloud agent
Пошаговое архивирование stopped-сессии Copilot cloud agent без потери pushed commits и с предварительной проверкой pull request.
Как найти прошлую сессию Copilot по естественному запросу
Поиск синхронизированных Copilot-сессий по смыслу: условия remoteExport, точные запросы, проверка владельца и восстановление контекста.
Как безопасно настроить allowed-tools в GitHub Copilot Agent Skill
Практическая настройка allowed-tools для Agent Skill: минимальные разрешения, shell-риски, проверка скрипта и негативный тест.
Комментарии
Пока тихо. Скажите первое слово