AB api-contract-review
Проверка контракта API: Проверяет контракт API как обещание потребителям — обнаруживает критические изменения, сравнивая поверхности до и после (удаленные/переименованные поля, изменения типов, ужесточение обязательности, изменения кодов состояния), и оценивает дизайн по ПРЕЦЕДЕНТАМ репозитория (конверт ошибок, именование, пагинация, размещение аутентификации) с каждым выводом о согласованности, ссылаясь на нарушаемое соглашение в репозитории. Охватывает версионирование, идемпотентность при повторных записях, пагинацию коллекций и семантику кодов состояния. Используйте этот навык всякий раз, когда пользователь говорит "проверить этот API", "проверить конечную точку", "обзор дизайна API", "является ли это критическим изменением", "проверить обратную совместимость", "проверить контракт", "проверить спецификацию OpenAPI/swagger" или "/api-contract-review" — даже если они не называют навык. Отличается от code-review (качество реализации); этот проверяет ПОВЕРХНОСТЬ, от которой зависят потребители.
машинный переводПоказать оригиналСкрыть оригинал«Review an API's contract as a promise to consumers — detects breaking…»
Review an API's contract as a promise to consumers — detects breaking changes by diffing the before/after surface (removed/renamed fields, type changes, tightened requiredness, status-code changes), and judges design by the repo's OWN precedent (error envelope, naming, pagination, auth placement) with every consistency finding citing the in-repo convention being violated. Covers versioning, idempotency on retryable writes, pagination on collections, and status-code semantics. Use this skill whenever the user says "review this API", "review the endpoint", "API design review", "is this a breaking change", "check backward compatibility", "review the contract", "review this OpenAPI/swagger spec", or "/api-contract-review" — even if they don't name the skill. Distinct from code-review (implementation quality); this reviews the SURFACE consumers depend on.
Проверка контракта API: Проверяет контракт API как обещание потребителям — обнаруживает критические изменения, сравнивая поверхности до и после…
Как процесс B 69/100 · Почти готов — слабые места: результат и критерий готовности, входы и предусловия, отчётность по ходу
Как улучшить
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 2. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
✓ По спецификации Agent Skills замечаний нет
Процессный рейтинг: все десять параметров 69/100
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 0Отчётность по ходу. Скилл ничего не сообщает по ходу работы
- 70Когда включается. Сказано, когда применять, но не сказано, когда не стоит
- 100Инструменты и файлы. Внешние инструменты не нужны
- 100Шаги. Шагов: 31
- 100Ошибки и развилки. Развилок: 1, есть раздел про ошибки
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 2108 токенов
- 100Повторный запуск. Изменяющие операции проверяют текущее состояние
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Длина description 862: рекомендуется 120–800 символов
- +3Формат ответа не описан: модель каждый раз решает сама
- +1Лицензия не указана
- +2Инструкции на одном языке
- +5В description 8 примера фраз-триггеров в кавычках
- +4Структура: 8 заголовков
- +3Пошаговые инструкции: 31 пунктов
- +4Есть примеры (0 блоков кода)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 86.