12 октября 2026 года GitHub разобрал, куда положить правила своего репозитория, чтобы Copilot подхватывал их сам, а не ждал тот же абзац в каждом новом чате. Инструкции, skill, отдельный агент и MCP. Пост Кристофера Харрисона, евангелиста GitHub, из серии Copilot app for Beginners: How to teach Copilot about your codebase.
У проекта и так есть свои договорённости. Как собраны компоненты, какие скрипты запускать, что принято для какого фреймворка и типа файла. Пока это живёт только в переписке с моделью, каждая новая задача начинается с нуля. Харрисон раскладывает это по четырём местам в репозитории и рядом с ним. Общие правила. Повторяемая процедура. Роль на широкую задачу. Внешний инструмент.
copilot-instructions.md
Общий слой называется repository custom instructions. Файл .github/copilot-instructions.md задаёт то, что относится ко всему репозиторию: какая архитектура предпочтительна, как называть вещи, чего вы ждёте от тестов и проверки. GitHub отдельно описывает этот файл: add repository instructions.
Пример в тексте бытовой. Просите добавить свой размер страницы. Написать код мало. Новый кусок ещё должен лечь в шаблоны, которые команда уже использует. Файл инструкций как раз отдаёт эту базу, и её не надо вставлять в запрос.
Узкий слой лежит отдельно, в .github/instructions. У таких файлов есть поле applyTo. Оно говорит, к каким путям правило относится. Copilot берётся за подходящий файл и может взять оба слоя сразу, общий и этот. Широкие договорённости остаются в одном месте. PHP, шаблоны и стили не обязаны жить по одной записке.
Поле applyTo здесь и есть развилка. Маска не попала в файл, над которым идёт работа, и узкое правило в этот заход молчит. Общий copilot-instructions.md при этом на месте.
Skill quality-checks
Инструкции держат стандарты, которые касаются многих задач. Другое дело процедура, нужная не всегда: прогнать проверки качества, собрать релиз, разобрать упавший workflow. Такое GitHub называет agent skill. Кратко про устройство: about agent skills.
Skill это папка. Внутри инструкция и, если надо, скрипты и другие файлы. На уровне проекта папки лежат в .github/skills, у каждого skill свой подкаталог.
В посте пример .github/skills/quality-checks и файл SKILL.md. Внутри четыре вещи:
- когда skill вообще включать;
- какими скриптами у проекта идут тесты и линт;
- что каждый скрипт проверяет;
- как разбирать типичные падения.
Copilot смотрит на описание в SKILL.md и по нему решает, относится ли skill к текущей задаче. Дальше у Харрисона так. Интерфейс уже поправлен, Copilot открывает quality-checks и идёт по принятому в проекте порядку, а не угадывает команды.
Для сайта или бота это как раз команда, которую все и так помнят вслух. Линт темы, сборка, прогон тестов формы. Один раз записали в skill. Дальше её не вставляют в каждый чат и не надеются, что модель сама вспомнит npm test, если у вас другой скрипт. Размытое описание эту связку ломает. Папка в репозитории есть, а Copilot её не берёт, потому что не понял, что задача про неё.
Агент в .github/agents
Дальше работа шире одной процедуры. Обзор доступности из поста: компоненты, шаблоны, стили и то, как элементы друг с другом работают. И это сразу несколько файлов.
Для такого делают custom agent, по сути отдельную роль Copilot. Профиль на уровне репозитория кладут в .github/agents. В нём цель, инструкции, инструменты и контекст проекта, который этой роли нужен. Про профили агентов у них отдельная страница: about custom agents.
Имеет смысл, когда один и тот же тип работы повторяется и ему нужна своя роль. Особенно если задача расползается по файлам и тянет несколько инструментов. Разовая правка опечатки сюда не просится. Повторяемый разбор шаблонов темы или писем бота уже ближе.
Skill и агента легко смешать. Оба лежат в .github, оба про то, как Copilot должен себя вести. Разница в размере задачи. Skill подгружают под конкретную процедуру, когда она подошла. Агент это роль на работу, которая сама шире одного скрипта.
MCP Playwright
Три слоя выше объясняют, как работать внутри репозитория. MCP-сервер подключает то, чего в репозитории нет: внешний инструмент, данные, сервис. Общая схема у GitHub: Model Context Protocol в Copilot.
Харрисон приводит два понятных случая. Сервер документации отдаёт гайд по фреймворку. Сервер вроде Playwright открывает ваше приложение в браузере и ходит по нему.
Готовые MCP-серверы смотрят в приложении Copilot. Свой добавляют отдельно. Пока Playwright не настроен, фраза из поста ничего не запустит. Когда настроен, запрос прямой.
Use the Playwright MCP server to test the functionality manually.
Дальше Copilot открывает приложение и действует примерно так, как это сделали бы вы. Автотесты остаются автотестами. Браузер отвечает на другой вопрос: обновлённый интерфейс ведёт себя так, как вы ждёте, а не только проходит скрипт.
На сайте это как раз экран. Форма, кнопка, вёрстка после правки. Skill quality-checks говорит, какой линт гонять. Playwright MCP показывает, открывается ли страница и нажимается ли то, что поменяли. Одно другое не заменяет.
Одно соглашение, не весь каталог
Четыре механизма решают разные задачи, и пост как раз про то, чтобы их не сваливать в одну кучу. GitHub сводит выбор к четырём вопросам.
- Какое соглашение проекта вы объясняете снова и снова?
- Какую многошаговую процедуру повторяете?
- Какая сложная задача просит отдельного агента?
- Какой внешний инструмент или источник Copilot сейчас не видит?
Чужие заготовки собраны в Awesome Copilot: инструкции, skills, агенты и прочее, чем поделилось сообщество. Харрисон советует найти то, что закрывает уже повторяющийся у вас ход, посмотреть, что внутри, и подогнать под свои скрипты и стандарты. Каталог целиком в репозиторий тащить незачем.
Старт он предлагает маленький. Одно соглашение, которое вы и так проговариваете, кладёте в .github/copilot-instructions.md. На следующей задаче видно, подхватил Copilot его или снова пишет по-своему.
Серия про приложение. Ссылка из поста: GitHub Copilot app.
