Гайд · TNWS AI

Как проверить источники инструкций через copilot instruction list

6 мин

Аудит custom instructions в GitHub Copilot CLI через copilot instruction list и --json: источники, applyTo и ограничения вывода.

Задача и когда применять

Практическая задача этого руководства — увидеть, какие источники custom instructions обнаружены для текущего рабочего каталога, и сохранить машиночитаемый отчёт для диагностики. Материал рассчитан на разработчика или администратора, который уже установил GitHub Copilot CLI и хочет получить проверяемый результат, а не просто скопировать команду из справки.

Команды CLI исполняются в контексте текущего пользователя, рабочего каталога и активной политики организации. Перед началом сохраните вывод copilot version, pwd и git status --short, если работаете в репозитории. Не вставляйте в prompt, аргументы и диагностические файлы токены, закрытые ключи или содержимое .env.

Что подтверждено официально

Проверено 13 сентября 2026 года. Команда copilot instruction list выводит обнаруженные источники, а copilot instruction list --json возвращает JSON. Элемент имеет поля { id, label, description?, location, type, sourcePath, defaultDisabled, applyTo? }. Устаревший copilot plugins list --kind instruction заменён этой командой.

Первоисточник — 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.

Пошаговые действия

  1. Откройте терминал в том каталоге, для которого диагностируется Copilot CLI.
  2. Выполните copilot instruction list и сохраните человекочитаемый вывод.
  3. Повторите проверку командой copilot instruction list --json > instructions.json.
  4. Проверьте sourcePath и location: источник должен относиться к ожидаемому пользователю, репозиторию или plugin.
  5. Проверьте applyTo, если поле присутствует: шаблон должен охватывать нужные файлы и не быть чрезмерно широким.
  6. Сопоставьте defaultDisabled с ожиданиями команды. Не включайте неизвестный источник до просмотра содержимого.
  7. Повторите команду из корня и из рабочей поддиректории, чтобы увидеть влияние current working directory.
  8. Удалите временный instructions.json, если отчёт содержит внутренние пути, либо храните его только в защищённом артефакте CI.

После выполнения повторите диагностическую команду или откройте новую shell/CLI-сессию, если эффект должен пережить перезапуск. Сравните результат с baseline. Если изменилось больше файлов или источников, чем ожидалось, остановитесь, сохраните diff и выполните откат до продолжения.

Готовый шаблон для копирования

Заполните эту карточку перед изменением. Её можно вставить в issue или change request:

Аудит Copilot instructions
Рабочий каталог: <pwd>
Команда: copilot instruction list --json
Ожидаемые sourcePath: <список>
Неожиданные источники: <список>
Проверяем applyTo: <шаблоны>
Проверяем defaultDisabled: <значения>
Решение: оставить / исправить / удалить источник
Дата проверки документации: 13.09.2026
Официальный источник: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

Для подготовки проверки можно скопировать prompt ниже. Он не разрешает ассистенту придумывать состояние окружения:

Составь план безопасной проверки команды GitHub Copilot CLI по карточке ниже.
Не выполняй запись, сетевую публикацию и изменение прав.
Не придумывай версию, файлы, exit code или успешный результат.
Верни: предпосылки, точную команду, позитивный тест, негативный тест,
наблюдаемые критерии успеха, откат и данные, которые нельзя логировать.

<вставьте заполненную карточку>

Реалистичный пример

Входные условия. В репозитории есть .github/copilot-instructions.md и .github/instructions/tests.instructions.md, применимый к **/*test*.

Ожидаемый результат. JSON содержит отдельные записи с путями и метаданными. Инженер подтверждает охват тестовой инструкции по applyTo и замечает любой источник из неожиданного каталога.

Пример считается успешным только после наблюдаемой проверки: существования и содержимого файла, нового completion в отдельной сессии, записи JSON, списка источников либо явного запрета действия. Не подменяйте ожидаемый результат пересказом документации — зафиксируйте фактический вывод вашей среды.

Позитивный и негативный тест

В позитивном тесте используйте минимальный безопасный объект: одну известную подкоманду, один каталог, один источник или один JSONL-файл. Сначала предскажите наблюдаемый результат, затем запустите действие и сохраните exit code. Если вывод содержит внутренние пути, не публикуйте сырой лог.

Негативный тест должен менять ровно одно условие: запретить конкретную команду, выбрать файл вне scope, убрать сессионный флаг или открыть новый shell. Такой тест доказывает границу настройки. Не используйте production remote, реальные секреты и необратимые операции для демонстрации отказа.

Если позитивный тест не прошёл, проверьте working directory, кавычки shell, версию CLI, организационную policy и права на целевой путь. Если негативный тест неожиданно прошёл, считайте конфигурацию небезопасной, завершите сессию и сузьте разрешения.

Типичные ошибки

  • Использование retired-команды вместо copilot instruction list.
  • Аудит из неверного current working directory.
  • Публикация JSON с внутренними абсолютными путями.
  • Предположение, что список гарантированно отражает все managed settings.

Отдельная ошибка — копировать команду между Bash, Zsh, Fish, PowerShell и CI без адаптации кавычек и перенаправлений. Сначала определите shell. Не сохраняйте секретные аргументы в history; используйте поддерживаемые переменные окружения или защищённое хранилище конкретной CI-системы.

Чек-лист финальной проверки

  • copilot version и рабочий каталог записаны.
  • Команда и названия флагов сверены с официальной документацией на 13.09.2026.
  • В prompt, history и временных файлах нет секретов.
  • Baseline сохранён до изменения.
  • Позитивный тест дал заранее описанный наблюдаемый результат.
  • Негативный тест подтвердил границу настройки.
  • Проверены exit code, stdout и stderr, где это применимо.
  • Неожиданные изменения файлов отсутствуют либо разобраны.
  • Временные логи и конфигурации удалены или защищены.
  • Откат выполнен на тесте или подробно записан.

FAQ

Зачем нужен --json?

Он удобен для скрипта и diff между окружениями, тогда как обычный вывод проще читать вручную.

Показывает ли команда live-применение со стопроцентной полнотой?

Нет. Документация предупреждает: источник, включённый trusted repository или managed settings, может не появиться в этом списке.

Что заменяет эта команда?

Она заменяет retired-вариант copilot plugins list --kind instruction.

Что означает applyTo?

Это условие области применения инструкции; его следует сверять с реальными путями проекта.

Итог

Рабочая настройка — это команда плюс доказательство её эффекта и границы. Храните заполненную карточку рядом с issue, а повторяемую команду — в проверенном wrapper script без секретов. Перед переносом в другую машину или организацию снова проверьте официальную справку: CLI обновляется, а доступность функций может зависеть от политики владельца Copilot.

Читайте также

Комментарии

Пока тихо. Скажите первое слово