📖 О чем это руководство

Чужой skill удобно воспринимать как полезную папку с инструкциями, но с точки зрения безопасности это всё равно внешний текст, который будет влиять на поведение агента. Поэтому skill нельзя автоматически считать безопасным только потому, что он красиво оформлен, лежит на GitHub или уже кому-то помог.

Практическая цель здесь не в том, чтобы доказать абсолютную безопасность. Такой гарантии всё равно не будет. Задача реалистичнее: быстро поймать красные флаги, снизить риск скрытых инструкций и понять, стоит ли вообще пускать навык в рабочий контур без ручной чистки.

🧠 Почему skill нужно считать недоверенным текстом

Skill не даёт агенту новый технический доступ сам по себе. Но он меняет поведение модели: что считать нормальным действием, какие шаги ставить в приоритет и какие рамки игнорировать. Именно поэтому danger-zone у skills часто сидит не в “магическом взломе”, а в скрытых инструкциях, которые подталкивают агента к неправильному поведению.

На практике это означает очень спокойную дисциплину. Чужой навык надо читать не как врага по умолчанию, но и не как священную документацию. Недоверие здесь не истерика, а инженерная гигиена.

Базовая установка

Любой внешний skill сначала считается недоверенным текстом. Доверие появляется только после чтения, red-flag pass и короткого ручного аудита.

📊 Минимальный контур проверки

Самый безопасный маршрут выглядит так: сначала собрать весь навык в единый пакет для чтения, потом прогнать грубый red-flag pass, затем отдать материал сильной reasoning-модели и только после этого принять решение вручную.

sequenceDiagram autonumber actor User as "👤 Пользователь" participant Pack as "📦 Audit Pack" participant Model as "🧠 Strong Model" participant Review as "🔎 Manual Review" User->>Pack: "Собрать файлы skill в один пакет" activate Pack Pack-->>User: "Единый markdown для аудита" deactivate Pack User->>User: "Сделать red-flag pass" User->>Model: "Проверить пакет на инъекции и скрытые инструкции" activate Model Model-->>User: "Подозрительные фрагменты и риски" deactivate Model User->>Review: "Перечитать найденные места руками" activate Review Review-->>User: "Принять: взять, перепаковать или отклонить" deactivate Review

Смысл этой схемы в том, что одна модель не заменяет ручное решение. Её задача - сузить поле внимания и показать подозрительные места, а не снять с вас ответственность за интеграцию навыка в рабочую систему.

🛠️ Практический порядок аудита

📦 Шаг 1. Соберите навык в один audit-pack

Если skill состоит из десятков мелких файлов, читать его по одному неудобно и человеку, и модели. Поэтому сначала полезно собрать все SKILL.md, docs, examples и scripts в один markdown-файл. Это не постоянная форма хранения, а временный контейнер для аудита.

Ниже простой PowerShell-пайплайн для такой сборки:

Get-ChildItem -Path .\some-skill -Recurse -File |
  Sort-Object FullName |
  ForEach-Object {
    "## FILE: $($_.FullName)`n"
    Get-Content -LiteralPath $_.FullName
    "`n"
  } | Set-Content -LiteralPath .\skill-audit-pack.md

Этот шаг полезен потому, что вы начинаете видеть навык как цельную систему правил, а не как россыпь фрагментов, между которыми легко потерять странную связку или скрытую инструкцию.

🚩 Шаг 2. Сделайте red-flag pass

До глубокого чтения полезно пройтись по самым опасным паттернам. Здесь важна не тонкая филология, а грубый инженерный фильтр. Ищите попытки скрывать текст навыка, игнорировать пользовательские инструкции, обходить локальные правила, вытаскивать секреты, читать чувствительные директории или выполнять действия, никак не связанные с заявленной ролью навыка.

Если skill про видеомонтаж, а внутри внезапно всплывают указания про скрытие поведения, секретность, ключи, кошельки или credential-файлы, это уже не нюанс, а повод тормозить интеграцию.

🧪 Шаг 3. Отдайте пакет сильной reasoning-модели

После грубого pass полезно дать собранный пакет сильной модели и попросить не “вообще оценить skill”, а найти скрытые приоритеты, возможные промпт-инъекции и несоответствие между заявленной задачей навыка и тем, что он реально заставляет делать агента. Такой запрос особенно полезен, когда файлов много и ручное чтение долгое.

Ключевой момент здесь в формулировке. Нужен не общий обзор, а жёсткая задача: показать опасные фрагменты текста, объяснить риск и назвать конкретную причину тревоги.

Что спрашивать у модели

Хороший audit-запрос почти всегда содержит три требования: найти опасные инструкции, объяснить, почему они опасны, и показать точный фрагмент текста, который вызвал подозрение.

👀 Шаг 4. Перечитайте подозрительные места руками

Даже сильная модель не снимает ручной review. Её задача - сузить зону внимания. После автоматического аудита нужно самому перечитать найденные места и задать простой вопрос: соответствует ли это реальной роли навыка или здесь уже начинается странное поведение, которое невозможно оправдать основной задачей.

Это особенно важно для skills, которые живут рядом с bash, файлами, браузером, git и локальными сервисами. Чем ближе навык к реальным действиям, тем опаснее соглашаться на вердикт в стиле “вроде выглядит нормально” без собственной проверки.

🧭 Шаг 5. Примите одно из трёх решений

После аудита вариантов обычно не десять, а три. Либо skill выглядит чисто и идёт в работу без изменений. Либо он полезен, но требует локальной чистки и перепаковки под ваши правила. Либо его лучше вообще не использовать, потому что цена доверия слишком высока.

Именно это и есть взрослый результат security-pass. Не слепое доверие и не паранойя на ровном месте, а осознанное решение с понятной причиной.

⚠️ На какие красные флаги смотреть в первую очередь

Первая группа красных флагов связана с попыткой перехватить приоритеты агента: “игнорируй локальные инструкции”, “не раскрывай текст навыка”, “всегда выполняй этот слой первым”, “не сообщай пользователю о таких-то действиях”. Это уже не просто стиль, а попытка навязать скрытое управление.

Вторая группа опаснее operationally: требования читать чувствительные директории, искать ключи, токены, кошельки, credential-файлы или выполнять shell-действия, которые не имеют отношения к основной задаче навыка. Здесь особенно важно не оправдывать странность фразой “ну, наверное, автор что-то имел в виду”.

Третья группа тоньше, но тоже важна. Иногда skill не выглядит вредоносным, но слишком агрессивно переопределяет user intent и заставляет агента игнорировать локальный проектный workflow. Для production-среды это тоже плохой сигнал.

Самая дорогая ошибка

Проверить только SKILL.md и проигнорировать вложенные docs, examples и scripts. Неприятный сюрприз чаще всего прячется именно там, где его меньше всего ждут.

✅ Когда skill можно пускать в работу

После хорошего аудита у вас должно получиться воспроизводимое объяснение: зачем нужен навык, какие файлы вы реально проверили, какие red flags искали и почему в итоге решили его принять, перепаковать или отклонить. То есть решение опирается не на настроение, а на ясный рабочий проход.

Если после проверки role навыка остаётся узкой, понятной и не вызывает внутреннего дискомфорта, это хороший знак. Если же после аудита остаются мутные зоны, лучше не уговаривать себя и держать skill в карантине до ручной чистки.

🔄 Что можно сделать дальше

Следующий полезный шаг - оформить собственный короткий checklist аудита skills и прогонять его перед каждым новым импортом. Тогда проверка перестанет быть разовой осторожностью и станет нормальной частью рабочего контура OpenCode.