AB synthetic-monitoring
Запланированные проверки, которые выполняются НЕПРЕРЫВНО после релиза. Охватывает проектирование проверок для критически важных пользовательских путей, интеграцию оповещений, проверку SLA, многорегиональный мониторинг и границу между QA и SRE. Используйте, когда: «synthetic monitoring», «uptime testing», «scheduled probes», «SLA validation», «availability monitoring», «post-deploy checks». Не для: техник безопасного выпуска во время развертывания — используйте testing-in-production. Не для: проектирования тестов на основе телеметрии из продакшена — используйте observability-driven-testing. Не для: одноразового пост-деплойного дымового теста, связанного с релизом — используйте release-readiness. Связанные: testing-in-production, release-readiness, performance-testing, qa-metrics.
машинный переводПоказать оригиналСкрыть оригинал«Scheduled probes that run CONTINUOUSLY after release. Covers probe des…»
Scheduled probes that run CONTINUOUSLY after release. Covers probe design for critical user journeys, alerting integration, SLA validation, multi-region monitoring, and the boundary between QA and SRE. Use when: "synthetic monitoring," "uptime testing," "scheduled probes," "SLA validation," "availability monitoring," "post-deploy checks." Not for: safe-release techniques during rollout — use testing-in-production. Not for: designing tests from prod telemetry — use observability-driven-testing. Not for: a one-shot post-deploy smoke gate tied to a release — use release-readiness. Related: testing-in-production, release-readiness, performance-testing, qa-metrics.
Запланированные проверки, которые выполняются НЕПРЕРЫВНО после релиза.
Как процесс B 74/100 · Почти готов — слабые места: входы и предусловия
Как улучшить
- Тело SKILL.md длиннее 5 000 токенов: вынесите справочные детали в references/ и подключайте по необходимости.
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 3. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
- предупреждение
body-longтело SKILL.md ≈ 5557 токенов (рекомендуется < 5000); вынесите детали в references/ - заметка
edit-residueв тексте есть пометки об устаревшем (строки 129): проверьте, не остались ли старые правила рядом с новыми — полная проверка читает текст на противоречия
Процессный рейтинг: все десять параметров 74/100
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 50Когда включается. Не сказано, при каком запросе скилл включается
- 60Инструменты и файлы. Используются инструменты (bash, python, node), но во frontmatter они не объявлены
- 70Стоимость исполнения. Тело инструкции 5557 токенов
- 100Шаги. Шагов: 34
- 100Результат и критерий готовности. Формат результата и критерий готовности описаны
- 100Ошибки и развилки. Развилок: 1, есть раздел про ошибки
- 100Согласованность. Имя и обязательные поля на месте
- 100Повторный запуск. Изменяющие операции проверяют текущее состояние
- 100Отчётность по ходу. Скилл сообщает о ходе работы
- low Разделов верхнего уровня: 14. Похоже на несколько доменов в одном скилле
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +2Инструкции на одном языке
- +5В description 6 примера фраз-триггеров в кавычках
- +4Описание говорит, когда скилл НЕ применять
- +3Длина description 668 символов: достаточно сигнала, не съедает бюджет
- +4Структура: 31 заголовков
- +3Пошаговые инструкции: 34 пунктов
- +3Формат ответа описан явно
- +4Есть примеры (9 блоков кода)
- +4Справочные файлы упоминаются в инструкциях (2 из 2)
- +1Лицензия указана
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 91.