B auditd
Linux Audit Framework reference. auditctl rules for file watches and syscall auditing, auditd.conf configuration, ausearch log queries, aureport summaries, audit.log format, CIS/PCI-DSS compliance rules, and audit tools.
- Безопасность 60%
- Качество 40%
- Тесты бонус
Чем это грозит
Находки средней серьёзности: скорее всего скилл честный, но прочитайте, что именно насторожило сканер.
Ниже описан худший случай для этой категории. Здесь находка средней серьёзности: guard увидел признак, но не доказательство.
Инструкции или скрипты отправляют данные наружу: переменные окружения, ключи, содержимое файлов, историю чата. Вы можете не заметить этого в диалоге, потому что агент выполнит отправку как «часть задачи».
Если отправка не нужна для задачи, уберите её: каталоги помечают такие скиллы как подозрительные и снимают с выдачи. Если нужна, назовите адрес явно, объясните, что именно уходит, и дайте пользователю выключатель.
Как улучшить
- Скажите в description, КОГДА применять скилл («используй, когда…», примеры запросов): это главный сигнал для срабатывания.
- Для Hermes description должен быть одним предложением до 60 символов; условия применения вынесите в раздел «## When to Use».
- Добавьте evals/evals.json с 4–6 реальными запросами и ожидаемыми ответами: тогда полная проверка использует ваши кейсы, а не черновик модели.
- Добавьте spec.yaml с триггерами и утверждениями (skilltest init): это контракт поведения для CI.
Находки guard · 1
✓ Критических и высоких находок нет
Средние и низкие: 1
-
средняя Утечка данных
exfil-read-secret-filesscripts/script.sh:405Чтение файлов с учётными данными / секретами (в кавычках — упоминание, а не команда)type=PATH msg=audit(1711267200.123:456): item=0 name="/etc/shadow"
в кавычках
Просканировано файлов: 3. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
Lint
- предупреждение
description-long-hermesdescription 220 символов, а стандарт Hermes требует ≤ 60 (одно предложение, с точкой) - предупреждение
description-no-whenни description, ни раздел "## When to Use" не говорят, когда применять скилл - заметка
dialect-hermesдиалект Hermes: description ≤ 60 символов, «когда применять» в разделе "## When to Use", метаданные в metadata.hermes - заметка
frontmatter-keyнеизвестное поле фронтматтера "homepage" - заметка
frontmatter-keyнеизвестное поле фронтматтера "source"
Процессная зрелость 40/100
- 0Шаги. Инструкция сплошным текстом, шаги не выделены
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 0Ошибки и развилки. Линейный процесс без обработки сбоев
- 20Когда включается. Не сказано, при каком запросе скилл включается
- 100Инструменты и файлы. Внешние инструменты не нужны
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 142 токенов
- 100Повторный запуск. Изменяющих операций нет
- 100Отчётность по ходу. Скилл сообщает о ходе работы
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +5В description нет примеров фраз, по которым скилл должен срабатывать
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +4Структура: 2 заголовков, инструкции сложно сканировать
- +3Нет пошаговых инструкций или чек-листа
- +3Формат ответа не описан: модель каждый раз решает сама
- +4Нет примеров входа/выхода
- -31 из 1 скриптов не упомянуты в SKILL.md
- +1Лицензия не указана
- +2Инструкции на одном языке
- +3Длина description 220 символов: достаточно сигнала, не съедает бюджет
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 50.