GitHub Copilot работает лучше, когда знает правила конкретной кодовой базы, с которой взаимодействует, а не полагается только на общие инструкции. GitHub отмечает, что значительную часть этого контекста можно хранить внутри репозитория, чтобы Copilot автоматически распознавал способы организации компонентов, используемые команды, а также стандарты именования и тестирования.
Общие инструкции и инструкции для определённых путей
Настройка начинается с создания файла .github/copilot-instructions.md, в котором указываются правила, действующие для всего репозитория, например предпочтительная архитектура, соглашения об именовании, а также требования к тестированию и проверке.
GitHub также позволяет создавать файлы инструкций, связанные с определёнными путями, внутри .github/instructions. В этих файлах используется поле applyTo для указания файлов или случаев, к которым применяются инструкции. Благодаря этому можно сочетать общие рекомендации с более специализированными правилами, не навязывая единый стиль всем типам файлов.
Преобразование повторяющихся процедур в навыки
Общие инструкции подходят не для каждой процедуры. Такие операции, как запуск проверок качества, подготовка релиза или диагностика сбоя рабочего процесса, требуют повторяемых шагов. Для этой цели GitHub предлагает использовать навыки агентов — каталоги, которые могут содержать инструкции, скрипты и дополнительные ресурсы.
Навыки, предназначенные для проекта, можно размещать в .github/skills, выделяя отдельный каталог для каждого навыка. Например, каталог quality-checks может содержать файл SKILL.md, в котором указано, когда следует использовать навык, приведены команды для тестирования и проверки стиля кода, описано, что проверяет каждая команда, а также объяснено, как обрабатывать распространённые случаи сбоев.
Когда нужен пользовательский агент?
Некоторые задачи выходят за рамки одной процедуры и охватывают несколько файлов и инструментов. GitHub приводит в качестве примера проверку доступности, которая может потребовать анализа компонентов, шаблонов, стилей и взаимодействий. В таких случаях можно создать пользовательского агента внутри .github/agents, указав его цель, инструкции, инструменты и контекст, относящийся к проекту.
Этот вариант подходит, когда определённый вид работы повторяется и выигрывает от специализированной роли или конкретной точки зрения, особенно если он требует взаимодействия с несколькими файлами и источниками контекста.
Расширение возможностей Copilot с помощью серверов MCP
Инструкции, навыки и агенты помогают Copilot понять, как работать внутри проекта, а серверы Model Context Protocol (MCP) связывают его с инструментами, источниками данных и сервисами за пределами репозитория. Сервер документации может предоставлять рекомендации по фреймворку, тогда как сервер, например Playwright, позволяет открывать приложение и взаимодействовать с ним через браузер.
После настройки Playwright можно вручную запросить тестирование функций с использованием сервера MCP. Таким образом, проверка не ограничивается успешным прохождением автоматических тестов: Copilot также может проверить поведение интерфейса после изменения и взаимодействовать с ним в браузере.
Что меняется на практике?
Основная польза заключается в переносе повторяющихся знаний из чата в доступные для проверки файлы внутри репозитория. Инструкции определяют стандарты, навыки документируют процедуры, агенты сосредотачиваются на сложных задачах, а серверы MCP добавляют возможность использовать внешние инструменты. GitHub рекомендует начинать постепенно: выберите одно правило, которое вам приходится объяснять снова и снова, поместите его в .github/copilot-instructions.md, а затем наблюдайте за тем, как Copilot его применяет.
В материале также упоминается репозиторий Awesome Copilot, содержащий готовые инструкции, навыки и агентов для совместного использования. Однако перед их внедрением по-прежнему необходимо адаптировать эти ресурсы к инструментам и стандартам проекта.