Гайд · TNWS AI
Как создать copilot-instructions.md командой copilot init
Практический запуск copilot init: анализ репозитория, проверка сгенерированных инструкций, безопасное редактирование и тестирование.
Задача и когда применять
Практическая задача этого руководства — сформировать проектные инструкции для GitHub Copilot CLI на основе реального репозитория и не принять сгенерированный файл вслепую. Материал рассчитан на разработчика или администратора, который уже установил GitHub Copilot CLI и хочет получить проверяемый результат, а не просто скопировать команду из справки.
Команды CLI исполняются в контексте текущего пользователя, рабочего каталога и активной политики организации. Перед началом сохраните вывод copilot version, pwd и git status --short, если работаете в репозитории. Не вставляйте в prompt, аргументы и диагностические файлы токены, закрытые ключи или содержимое .env.
Что подтверждено официально
Проверено 13 сентября 2026 года. Команда copilot init и интерактивная команда /init анализируют кодовую базу и создают либо обновляют .github/copilot-instructions.md. Обычно файл описывает команды build/test/lint, архитектуру и соглашения проекта. Если файл уже существует, CLI предлагает улучшения, которые можно принять или отклонить.
Первоисточник — GitHub Copilot CLI command reference. Для MCP-сценария дополнительно используйте официальную настройку MCP servers. Цены, квоты и список доступных моделей здесь не приводятся: они не нужны для процедуры и могут меняться. Названия команд и параметров взяты из текущей официальной справки.
У CLI есть три разных уровня результата: команда может быть синтаксически принята, фактически выполнена и дать ожидаемый эффект. Проверяйте все три. Нулевой exit code без проверки файла или интерфейса недостаточен; красивый текст ответа при ненулевом exit code тоже нельзя считать успехом.
Перед тестом запишите точную гипотезу в одном предложении: «после команды появится такой-то файл, источник, запрет или набор подсказок». Затем определите независимый способ проверки, который не опирается на объяснение самого ассистента. Для файла это просмотр содержимого и diff, для разрешения — намеренно безопасная попытка запрещённого действия, для списка — сравнение структурированного вывода. Такой подход помогает обнаружить ситуацию, когда команда отработала, но не в том каталоге, не для того пользователя или не в той конфигурации.
Подготовка безопасной среды
Для первого запуска используйте тестовый репозиторий, временный каталог или read-only задачу. Сохраните baseline: существующие файлы конфигурации, список источников, текущий completion или разрешения. Если команда пишет файл, заранее определите точный путь и сделайте резервную копию только этого файла. Если команда предоставляет доступ, перечислите разрешённые и контрольные запрещённые объекты.
Не используйте глобальные разрешения ради удобства, когда задачу решает точный флаг. В CI разделяйте stdout, stderr и exit code. В интерактивной сессии читайте запросы разрешений и не подтверждайте действие только потому, что его предложил Copilot. Любой сгенерированный код или конфигурацию просматривайте как обычный внешний patch.
Пошаговые действия
- Перейдите в корень нужного Git-репозитория и выполните
git status --short, чтобы не смешать результат и чужие изменения. - Запустите
copilot init. В интерактивной сессии эквивалентная команда —/init. - Просмотрите предлагаемый diff
.github/copilot-instructions.md; не принимайте команды сборки, которых нет в проекте. - Сверьте каждую команду с
package.json, Makefile, CI workflow или документацией репозитория. - Удалите секреты, локальные пути и указания, позволяющие публикацию либо деплой без подтверждения.
- Запустите указанные build, test и lint команды вручную в безопасной ветке.
- Сохраните файл в отдельном commit и откройте PR, чтобы владельцы компонентов проверили архитектурные утверждения.
- Начните новую CLI-сессию и дайте небольшую задачу, проверяя, соблюдены ли правила файла.
После выполнения повторите диагностическую команду или откройте новую shell/CLI-сессию, если эффект должен пережить перезапуск. Сравните результат с baseline. Если изменилось больше файлов или источников, чем ожидалось, остановитесь, сохраните diff и выполните откат до продолжения.
Готовый шаблон для копирования
Заполните эту карточку перед изменением. Её можно вставить в issue или change request:
Цель: подготовить .github/copilot-instructions.md
Репозиторий: OWNER/REPO
Проверенные команды:
- build: <команда>
- test: <команда>
- lint: <команда>
Архитектурные границы: <модули>
Запрещённые действия: deploy, push, изменение секретов без подтверждения
Ревьюеры файла: <команда>
Дата проверки документации: 13.09.2026
Официальный источник: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference
Для подготовки проверки можно скопировать prompt ниже. Он не разрешает ассистенту придумывать состояние окружения:
Составь план безопасной проверки команды GitHub Copilot CLI по карточке ниже.
Не выполняй запись, сетевую публикацию и изменение прав.
Не придумывай версию, файлы, exit code или успешный результат.
Верни: предпосылки, точную команду, позитивный тест, негативный тест,
наблюдаемые критерии успеха, откат и данные, которые нельзя логировать.
<вставьте заполненную карточку>
Реалистичный пример
Входные условия. В Node.js-монорепозитории реально существуют npm run lint, npm test и workspace apps/api; команда запускается из корня.
Ожидаемый результат. CLI предлагает .github/copilot-instructions.md с фактическими командами и обзором структуры. Разработчик исправляет неточности, тестирует команды и отправляет отдельный PR; будущая сессия использует проверенные инструкции.
Пример считается успешным только после наблюдаемой проверки: существования и содержимого файла, нового completion в отдельной сессии, записи JSON, списка источников либо явного запрета действия. Не подменяйте ожидаемый результат пересказом документации — зафиксируйте фактический вывод вашей среды.
Позитивный и негативный тест
В позитивном тесте используйте минимальный безопасный объект: одну известную подкоманду, один каталог, один источник или один JSONL-файл. Сначала предскажите наблюдаемый результат, затем запустите действие и сохраните exit code. Если вывод содержит внутренние пути, не публикуйте сырой лог.
Негативный тест должен менять ровно одно условие: запретить конкретную команду, выбрать файл вне scope, убрать сессионный флаг или открыть новый shell. Такой тест доказывает границу настройки. Не используйте production remote, реальные секреты и необратимые операции для демонстрации отказа.
Если позитивный тест не прошёл, проверьте working directory, кавычки shell, версию CLI, организационную policy и права на целевой путь. Если негативный тест неожиданно прошёл, считайте конфигурацию небезопасной, завершите сессию и сузьте разрешения.
Типичные ошибки
- Запуск из подкаталога вместо корня репозитория.
- Принятие выдуманной команды тестов без запуска.
- Попадание токенов или абсолютных локальных путей в tracked-файл.
- Смешивание инструкций с функциональным изменением в одном commit.
Отдельная ошибка — копировать команду между Bash, Zsh, Fish, PowerShell и CI без адаптации кавычек и перенаправлений. Сначала определите shell. Не сохраняйте секретные аргументы в history; используйте поддерживаемые переменные окружения или защищённое хранилище конкретной CI-системы.
Чек-лист финальной проверки
- copilot version и рабочий каталог записаны.
- Команда и названия флагов сверены с официальной документацией на 13.09.2026.
- В prompt, history и временных файлах нет секретов.
- Baseline сохранён до изменения.
- Позитивный тест дал заранее описанный наблюдаемый результат.
- Негативный тест подтвердил границу настройки.
- Проверены exit code, stdout и stderr, где это применимо.
- Неожиданные изменения файлов отсутствуют либо разобраны.
- Временные логи и конфигурации удалены или защищены.
- Откат выполнен на тесте или подробно записан.
FAQ
Что делает /init?
В интерактивной сессии он выполняет проектную инициализацию, аналогичную copilot init.
Что будет при существующем файле?
CLI предлагает улучшения, которые пользователь может принять либо отклонить.
Можно ли отключить подсказку об отсутствии файла?
Да, официальная справка указывает /init suppress для текущего репозитория.
Нужно ли коммитить файл?
Если инструкции должны быть общими для команды, разумно проверить их через PR и хранить в репозитории.
Итог
Рабочая настройка — это команда плюс доказательство её эффекта и границы. Храните заполненную карточку рядом с issue, а повторяемую команду — в проверенном wrapper script без секретов. Перед переносом в другую машину или организацию снова проверьте официальную справку: CLI обновляется, а доступность функций может зависеть от политики владельца Copilot.
Читайте также
Как добавить второй каталог в Copilot CLI через --add-dir
Безопасное использование --add-dir в GitHub Copilot CLI: доступ к файлам, доверенные skills/agents, относительные пути и проверка.
Как подключить MCP на одну сессию через --additional-mcp-config
Сессионное подключение MCP в Copilot CLI через --additional-mcp-config: JSON-файл, приоритет имени, проверка tools и очистка секретов.
Как получить JSONL из Copilot CLI через --output-format=json
Программный запуск Copilot CLI с -p и --output-format=json: поток JSONL, валидация строк, stderr, exit code и resume hint.
Комментарии
Пока тихо. Скажите первое слово