Если ты хоть раз пробовал поручить автономному ИИ-агенту написать не просто изолированную функцию, а законченный кусок логики для реального проекта, то наверняка помнишь этот эффект обманчивой эйфории. Первые пять минут всё выглядит как магия: модель бодро шуршит по файлам, генерирует компоненты, правит роуты и рапортует: «Всё готово, босс!». Но стоит заглянуть в git diff, как накатывает холодный пот. Вместо чистой архитектуры там нагромождение костылей, граничные условия проигнорированы, а тесты либо не написаны вовсе, либо заботливо закомментированы, чтобы не мешали компиляции.
В индустрии это явление метко окрестили «вайбкодингом» — когда код пишется на чистом ощущении легкости, но моментально разваливается при первом же столкновении с продакшеном. Беда больших языковых моделей не в знании синтаксиса: синтаксис они знают отлично. Проблема в отсутствии инженерной дисциплины: LLM по своей природе ленива и выбирает путь наименьшего сопротивления, оптимизируя ответ под локальный контекст текущего окна сообщений.
Чтобы обуздать этот хаос, Эдди Османи (Addy Osmani), ведущий инженер Google Chrome и автор фундаментальных руководств по архитектуре JavaScript, опубликовал открытую систему инженерных навыков addyosmani/agent-skills. Это не очередной плагин для автокомплита, а полноценный фреймворк из 25 стандартизированных модулей, который заставляет более 70 сред разработки и агентов (включая Claude Code, Cursor, Windsurf, Cline и Copilot Workspace) работать по строгим правилам сеньор-разработчиков.
От хаотичных промптов к шести фазам жизненного цикла
Давай честно: пытаться привить модели дисциплину через гигантский системный промпт — тупиковый путь. Если скормить агенту инструкцию на тридцать страниц, он быстро потеряет фокус и начнет игнорировать критические детали из середины текста. Да и контекстное окно стоит денег и вычислительных ресурсов.
Османи подошел к задаче как системный архитектор. Он разбил весь жизненный цикл разработки ПО (SDLC) на шесть последовательных фаз, которыми управляют девять коротких слэш-команд. Модель не держит все правила в голове одновременно, а подключает специализированные инструкции по принципу Progressive Disclosure — ровно в тот момент, когда переходит к соответствующему шагу.
- Фаза DEFINE (Фиксация требований): Прежде чем агент тронет рабочий код, команда
/specактивирует модуль спецификацийspec-driven-development. Агент составляет документ требований (PRD): описывает пользовательские сценарии, контракты данных и явные границы системы. Если задача размыта, скиллinterview-meзадает уточняющие вопросы по одному за раз, пока контекст не станет кристально ясен. А модульconstraint-driven-development(команда/constraints) фиксирует пороги качества вCONSTRAINTS.md(например, запрет внешних зависимостей без явного согласования). - Фаза PLAN (Декомпозиция): Команда
/planактивирует скиллplanning-and-task-breakdownи делит спецификацию на обозримые атомарные шаги с критериями приемки. Никаких слепых прыжков на сотни строк — каждый пункт проверяется независимо. - Фаза BUILD (Инкрементальная реализация): Скиллы сборки (
incremental-implementationиtest-driven-development) навязывают агенту цикл TDD: сначала падающий тест, затем минимальный рабочий код и атомарный коммит. На критических развилках скиллdoubt-driven-developmentзаставляет модель сомневаться в собственных предположениях по протоколу CLAIM -> EXTRACT -> DOUBT -> RECONCILE -> STOP. - Фаза VERIFY (Инструментальная проверка): Команда
/testпрогоняет пирамиду тестов (80% unit, 15% integration, 5% e2e). При необходимости агент поднимает браузер через Chrome DevTools MCP (browser-testing-with-devtools) и визуально подтверждает рендеринг интерфейса. - Фаза REVIEW (Гейты качества): Модуль
code-review-and-quality(в среде Claude Code:/agent-skills:review) беспристрастно аудирует дифф. Патчи длиннее 100 строк отправляются на повторное дробление,/code-simplifyвычищает оверинжиниринг, а/webperfзамеряет влияние на метрики Core Web Vitals. - Фаза SHIP (Безопасный релиз): Команда
/shipпроверяет корректность миграций баз данных и защищает публичные интерфейсы от регрессий по закону Хайрама: если у системы есть наблюдаемое поведение, кто-то обязательно на него завяжется.
Ранее мы уже разбирали, как стандарт Agent Skills: как модульные навыки расширяют возможности кодинг-агентов создает общий язык для разных сред разработки, но в версии Османи эта концепция впервые получила завершенную производственную обкатку.
Таблицы анти-рационализации: как отучить нейросеть врать
Самая остроумная инженерная находка в проекте — это так называемые Anti-Rationalization Tables (таблицы анти-рационализации).
Я регулярно замечал, как нейросети виртуозно находят оправдания собственным огрехам. Агент пишет: «Этот модуль слишком прост, поэтому я не стал писать для него тесты, всё очевидно из кода». Или: «Линтер выдает предупреждение на строке 42, поэтому я временно отключил правило через комментарий eslint-disable, чтобы не блокировать процесс». Это чистой воды рационализация лени, которую модель переняла из миллионов небрежных репозиториев на GitHub.
Османи внедрил в манифесты навыков таблицы, где каждой типичной отговорке LLM противопоставлено категорическое правило-контраргумент:
- На отговорку «Код тривиален, тесты можно дописать позже» следует жесткий запрет: «Тесты, написанные постфактум, страдают предвзятостью подтверждения. Сначала пиши тест».
- На отговорку «Тестовый набор идет слишком долго, пропустим запуск» агент получает команду: «Запусти только изолированный файл тестов через таргетированные флаги тест-раннера».
- На жалобу «Сложно замокать сетевой вызов к внешнему API» дается четкое архитектурное указание: «Если зависимость нельзя изолировать в тесте, вынеси бизнес-логику в чистые функции».
Когда такие контраргументы вшиты непосредственно в исполняемый контекст, модель лишается пространства для маневра и вынуждена следовать правилам.
Анатомия спецификации навыка: заглядываем под капот SKILL.md
Давай разберем, как устроен манифест навыка изнутри. Каждый навык хранится в виде отдельной папки с файлом SKILL.md. В заголовке расположен стандартный YAML frontmatter с метаданными и триггерами вызова, а тело документа содержит операционные правила, таблицы анти-рационализации и гейты проверки:
---
name: test-driven-development
description: Enforce Red-Green-Refactor, test pyramid (80/15/5), and boundary verification.
triggers:
- "implement feature"
- "fix bug"
- "refactor"
---
# Test-Driven Development (TDD) Skill
## Operating Rules
1. Write the test BEFORE writing any production code.
2. Run the test suite and verify that the test FAILS for the expected reason (Red).
3. Write the minimal amount of code to make the test pass (Green).
4. Refactor the code for clarity and maintainability without altering behavior.
## Verification Gate
- Run `npm test -- --watch=false`
- Capture stdout and stderr into execution log.
- Confirm zero failing assertions and test coverage threshold >= 85%.
Агент парсит этот файл, понимает границы своей ответственности и приступает к выполнению. Если гейт верификации не пройден (например, тесты упали или покрытие ниже 85%), переход к следующей задаче блокируется на уровне протокола.
Как развернуть навыки в своем проекте за одну минуту
Для интеграции навыков в свой проект не нужно вручную копировать десятки файлов или настраивать сложные конфигурации. Всё разворачивается с помощью кросс-платформенной консольной утилиты skills через npx:
# Установка полного набора скиллов в текущий проект
npx skills add addyosmani/agent-skills
# Выборочная установка только скиллов TDD и код-ревью
npx skills add addyosmani/agent-skills --skill test-driven-development
npx skills add addyosmani/agent-skills --skill code-review-and-quality
При выборочной установке обрати внимание на одну важную деталь: в текущей версии утилиты флаг --skill копирует только директорию конкретного навыка, не захватывая общую папку глобальных справочников references/ (эта проблема сейчас активно решается в issue #361 репозитория). Поэтому для серьезных проектов я рекомендую ставить комплект целиком либо клонировать репозиторий напрямую.
Упаковка инженерного опыта в структурированные скиллы наглядно доказывает: будущее автономной разработки зависит не от слепого наращивания параметров нейросетей, а от жесткости и чистоты процессов, в которые эти модели помещены.