Если вы хоть раз просили нейросеть «сделай мне сайт», «почини скрипт» или «допиши функцию», то наверняка видели эту странную магию. Сначала всё бодро: агент уверенно пишет код, создаёт файлы, объясняет, что почти готово. А потом начинается бытовая часть: тесты не запускались, ошибка спряталась в соседнем файле, безопасность никто не проверял, а итоговый проект похож на ремонт, который начали с покупки красивых обоев.
Проблема не в том, что ИИ «глупый». Проблема в том, что ему часто дают задачу как человеку без привычек. Он старается быстрее дойти до ответа. А хорошие инженеры обычно работают иначе: сначала уточняют, что именно строим, потом дробят задачу, затем делают маленькими кусками, проверяют, ревьюят и только после этого выпускают.
Именно под это Адди Османи из Google Cloud AI выложил репозиторий Agent Skills. Это не очередной список «100 волшебных промптов». Больше похоже на набор рабочих инструкций, которые заставляют ИИ-агента вести себя не как болтливый стажёр, а как аккуратный инженер с чек-листом.
Что внутри
Идея простая: разработка делится на шесть этапов.
Сначала Define. Агент не бросается писать код, а уточняет идею и помогает превратить «хочу удобную штуку» в нормальное описание задачи. Для этого есть команда /spec.
Потом Plan. Большая задача режется на маленькие шаги, у каждого шага есть понятный результат. Здесь работает /plan.
Дальше Build. Код пишется не одним гигантским полотном, а небольшими кусками. Это снижает шанс, что агент уедет в сторону и сломает половину проекта. За это отвечает /build.
После этого Verify. Агент должен доказать, что всё работает: запустить тесты, проверить интерфейс, посмотреть ошибки в браузере через DevTools, а не просто написать «готово». Для этого есть /test.
Потом Review. Код проверяется на качество, безопасность, производительность и читаемость. Здесь пригодится /review и отдельная команда /code-simplify, если проект начал обрастать лишней хитростью.
Финальный этап — Ship. Подготовка к выпуску, документация, откат, флаги функций, CI/CD и прочие скучные вещи, которые становятся очень нескучными, когда сервис падает в самый неподходящий момент. Для этого есть /ship.
Почему это полезно обычному пользователю
На первый взгляд кажется, что репозиторий только для разработчиков. Но сейчас многие люди делают небольшие программы с помощью Cursor, Claude Code, Gemini CLI или других ИИ-агентов. Кто-то собирает сайт для проекта, кто-то пишет парсер, кто-то автоматизирует работу с файлами, кто-то чинит старый скрипт.
Главная беда таких задач — не написать первую версию. Её нейросеть обычно выдаёт быстро. Сложнее не утонуть потом в хаосе. Агент забыл, что уже менял. Исправил одно, сломал другое. Добавил библиотеку, хотя можно было обойтись без неё. Пообещал тесты, но не запустил. Уверенно придумал API, которого нет.
Agent Skills как раз ставит рамки. Он напоминает агенту: не фантазируй, сначала проверь источник. Не лепи всё сразу, сделай маленький кусок. Не говори «похоже, работает», покажи результат проверки. Не тащи сложность ради красоты. Не выпускай без плана отката.
Мне особенно понравилась не сама идея слэш-команд, а внутренняя дисциплина. В навыках есть проверочные ворота и борьба с типичными отговорками агента. Например, когда ИИ хочет пропустить тесты под видом «изменение маленькое», ему прямо объясняют, почему так делать нельзя. Это звучит почти комично, но на практике именно такие мелочи отличают рабочий проект от набора красивых файлов.
Где это можно применить
Допустим, вы хотите сделать простую веб-страницу для домашнего проекта. Обычный путь: написать агенту «сделай сайт» и потом ловить ошибки. Более спокойный путь: сначала /spec, чтобы описать страницы, кнопки, данные и ограничения. Потом /plan, чтобы разбить работу. Потом /build, но по одному блоку. После каждого блока — /test, а перед финалом — /review.
Да, это медленнее на старте. Зато меньше шансов получить проект, который красиво выглядит в чате, но не запускается у вас на компьютере.
Ещё один пример — чужой код с GitHub. Вместо просьбы «почини всё» можно сначала попросить агента изучить контекст, составить план, выделить минимальный воспроизводимый сбой и только потом менять файлы. Это особенно важно, когда проект большой, а вы сами не хотите разбираться в каждой строчке.
Чем не стоит обманываться
Это не кнопка «сделать хороший софт». Навыки не заменяют понимание задачи и не превращают слабую модель в сильную. Если агент не умеет пользоваться терминалом, читать логи или запускать браузерные проверки, часть пользы потеряется.
Ещё нюанс: инструкции на английском, и новичку может быть непривычно. Но сами файлы — обычный Markdown. Их можно читать, копировать, адаптировать под Cursor, правила проекта, Gemini CLI, OpenCode, Windsurf, GitHub Copilot или вообще любой агент, который принимает системные инструкции.
Третий момент — токены. Чем больше правил вы подсовываете агенту, тем больше контекста он тратит. Хороший подход — не грузить всё подряд, а подключать нужный навык под конкретную задачу. Для интерфейса — frontend, для API — контракт, для безопасности — hardening, для выпуска — shipping.
Кому стоит сохранить репозиторий
Если вы просто иногда спрашиваете ChatGPT «как написать команду для Linux», репозиторий может показаться избыточным. А вот если вы уже пробовали делать код через ИИ-агента, он точно пригодится.
Особенно тем, кто хочет не «вайбкодить до первой ошибки», а выстроить нормальный процесс. Сначала понять, что строим. Потом разложить. Потом собрать. Потом доказать, что работает. Потом упростить. Потом выпустить.
В этом и есть главная польза Agent Skills: он не обещает чудо. Он добавляет ИИ-агенту инженерные привычки. А привычки, как ни странно, часто важнее очередной новой модели.
Источник: Agent Skills
Похожие статьи
Если вам интересны ИИ-инструменты для разработки и проверки кода, посмотрите также: