Что считать самопроверкой Agent Skill?
Самопроверка - отдельный детерминированный барьер, а не просьба модели перечитать собственный ответ. Навык сначала сохраняет структурированный план, запускает validator и продолжает работу только после успешного кода завершения.
Для сложной операции удобен цикл plan - validate - execute - verify. План можно исправлять без изменения исходных данных. После выполнения отдельная проверка подтверждает, что ожидаемое состояние действительно получено.
Чем validator отличается от eval и CI?
Validator отвечает, допустима ли конкретная операция сейчас. Eval измеряет поведение навыка на наборе сценариев, а CI решает, можно ли объединить или выпустить новую версию. Эти уровни дополняют друг друга.
| Механизм | Главный вопрос | Момент |
|---|---|---|
| Validator | Можно продолжать эту операцию? | Внутри каждого запуска |
| Eval | Насколько хорошо работает навык? | При разработке и пересмотре |
| CI | Готова ли версия к merge? | При изменении репозитория |
Поведенческие сравнения описаны в статье как оценить эффективность Agent Skill. Автоматический gate версии вынесен в материал про CI.
Как устроить цикл plan - validate - execute - verify?
Разделите планирование, проверку, выполнение и подтверждение результата на отдельные шаги и файлы. Validator не меняет состояние, executor принимает только проверенный план, а verifier сверяет фактический результат с ожидаемым.
- 1. Сформируйте план
Сохраните операцию, цели, ограничения и dry-run в JSON без изменения исходных файлов.
- 2. Проверьте план
Запустите validator и исправляйте только план, пока код завершения не станет нулевым.
- 3. Выполните операцию
Executor сверяет hash или повторно валидирует неизменившийся план перед записью.
- 4. Проверьте результат
Отдельный verifier сравнивает конечное состояние с критериями и сохраняет evidence.
Такое разделение помогает увидеть, на каком этапе возникла ошибка. Один скрипт, который одновременно проверяет и исправляет вход, сложнее остановить и проверить.
Что включить в контракт плана?
План должен иметь версию схемы, закрытый тип операции, список относительных целей, режим пробного запуска и ограничения. Validator отклоняет неизвестные поля или операции, пустые списки, дубли и пути за пределами разрешённого корня.
- schema_version для совместимости validator и executor.
- operation из явного allowlist.
- targets как непустой список относительных путей.
- dry_run: true для первой итерации.
- Лимиты числа файлов, размера и допустимых расширений.
Если план меняется после проверки, прежнее разрешение больше не относится к новой версии. Считайте hash плана или запускайте validator повторно непосредственно перед действием.
Какой интерфейс нужен validator-скрипту?
Validator должен работать без интерактивного ввода, принимать явные аргументы, не менять файлы и возвращать машинно-читаемый результат. Данные проверки идут в stdout, диагностический ход - в stderr, а код завершения однозначно сообщает успех или отказ.
- Команда --help описывает входы, примеры и коды завершения.
- Нормальный и ошибочный результат имеют одну стабильную JSON-схему.
- Каждая ошибка содержит code, field и понятное message.
- Validator не вызывает executor и не исправляет вход молча.
- Базовая проверка не зависит от сети, времени и ответа модели.
Если SKILL.md перегружен кодом и справочниками, сначала используйте инструкцию как разделить большой SKILL.md.
Какие коды завершения возвращать?
Код 0 оставьте только для допустимого плана. Ненулевые коды разделите по причинам: неверные аргументы, недоступный файл, ошибка JSON, нарушение предметных правил и неподходящая среда. Это проектный контракт, который нужно документировать.
| Код | Значение | Следующий шаг агента |
|---|---|---|
| 0 | План допустим | Перейти к executor |
| 2 | Неверные аргументы | Исправить команду |
| 3 | Файл недоступен | Проверить путь и права |
| 4 | JSON не разобран | Исправить структуру |
| 5 | Нарушены правила | Исправить план |
| 6 | Среда не подходит | Остановиться и изменить окружение |
GitHub Actions считает ненулевой код failure. Детальные коды нужны не для изменения бинарного gate, а для быстрой и однозначной диагностики человеком и агентом.
Что сохранять как доказательство проверки?
Сохраняйте статус, версию validator, hash плана, версию набора правил, число проверенных целей и безопасный список находок. Не записывайте в evidence токены, секреты, персональные данные и полное содержимое закрытых документов.
Evidence позволяет связать выполненную операцию с конкретным проверенным планом. Если executor получил другой hash, он должен остановиться. В CI такой JSON можно сохранить как workflow artifact вместе с очищенным отчётом.
- validator_version
- plan_sha256
- ruleset
- checked_targets
- status и findings без чувствительных значений
Какие границы безопасности должен проверять validator?
Проверяйте относительность и нормализацию путей, выход через .. и симлинки, закрытый список операций, защищённые каталоги, лимиты объёма и dry-run. Validator должен иметь только права, необходимые для чтения плана и проверки допустимой области.
Исполняемые scripts расширяют последствия ошибки, поэтому их нужно читать и тестировать в изолированной среде. Ищите скрытую сеть, shell-команды, broad glob, hardcoded credentials и запись вне заявленной папки.
Полный аудит перед установкой описан в практическом чек-листе проверки AI-навыка. Наличие validator не освобождает от этой проверки.
Какие ошибки делают самопроверку фиктивной?
Самопроверка становится фиктивной, если validator запускается после изменения, возвращает 0 вместе с ошибками, смешивает данные и лог, исправляет план молча или выполняет действие сам. Такой барьер нельзя независимо проверить и безопасно повторить.
- Проверять только после выполнения.
- Печатать ошибки и всё равно возвращать 0.
- Давать одно сообщение invalid input без поля и причины.
- Просить пароль или подтверждение через интерактивный prompt.
- Разрешать абсолютные пути и широкие glob.
- Зависеть от сети или ответа другой модели.
- Выполнять старый план после проверки изменённого файла.
- Считать validator доказательством полной безопасности skill.
С чего начать внедрение самопроверки?
Возьмите одну критичную операцию и один известный класс ошибок. Опишите минимальную JSON-схему, создайте validator без записи, добавьте три отрицательных примера и только после этого подключайте executor и проверку результата.
- 1. Выберите риск
Например, выход пути за рабочую папку или пропуск обязательного поля.
- 2. Зафиксируйте контракт
Опишите допустимые поля, типы и ограничения плана.
- 3. Напишите чистый validator
Он только читает, проверяет и возвращает результат.
- 4. Добавьте отрицательные тесты
Проверьте битый JSON, запрещённую операцию и путь вне корня.
- 5. Свяжите шаги в SKILL.md
Запретите executor до exit 0 и потребуйте evidence после verify.
Если процесс затрагивает рабочие данные или внешние системы, Скилловик может помочь собрать ограниченный пилот, контракт проверки и точки человеческого подтверждения.