Warp открыла код своих agent skills. Я заглянул внутрь и делюсь находками
Недавно я убил полчаса на то, чтобы переобъяснить своему AI-агенту, как оформлять описания pull request'ов. В другой ветке — как разбирать упавший CI. Знакомая ситуация? Каждый раз приходится заново проговаривать агенту правила, которые у команды и так есть в головах.
Команда Warp (да, та самая, что делает терминал) apparently решила эту проблему для себя и выложила решение в открытый доступ. Репозиторий называется common-skills — коллекция общих скиллов для AI-агентов, которые Warp использует во всех своих проектах. MIT-лицензия, ~350 звёзд, установка одной командой через npx.
Что такое «скилл» и зачем он агенту
Скилл — это по сути инструкция-процедура в формате Markdown. Один файл SKILL.md с YAML-фронтматтером (имя и описание), плюс опциональные скрипты, справочные документы и ассеты. Агент читает описание и понимает, когда применить скилл.
Аналогия простая: скилл — это чек-лист для стажёра, который вы написали один раз, а он потом экономит всем время. Только стажёр у нас — языковая модель, и она действительно следует инструкции.
Кстати, Warp чётко разделяет общие и локальные скиллы. Если процедура полезна больше чем в одном репозитории — она живёт в common-skills. Если относится к конкретному проекту — остаётся в самом проекте. Звучит очевидно, но в моей практике мало кто в командах так систематизирует знания для агентов.
Что внутри — самое интересное
Сейчас в репозитории около 15 скиллов, разбитых на несколько групп. Пройдусь по тому, что зацепило лично меня.
Спеки вместо «напиши мне фичу»
Группа spec workflow — четыре скилла вокруг подхода spec-first:
write-product-spec— пишет пользовательские спеки в PRODUCT.mdwrite-tech-spec— технический спек в TECH.mdspec-driven-implementation— ведёт весь спек-first воркфлоу для крупных фичimplement-specs— реализует approved-спеки, не давая коду разъехаться с документацией
Идея в том, что агент сначала формализует задачу в документ, вы его согласовываете, и только потом начинается код. Лично я скептически отношусь к бюрократии в мелких задачах, но для чего-то серьёзного (тащить платёжку, миграцию, новый модуль) такой порядок реально спасает от «агент понял не то».
Работа с pull request'ами
Скиллов под ревью и PR здесь пять штук. create-pr и write-pr-description помогают готовить и открывать PR с внятным описанием и подсказками для ревьюера. review-pr генерирует структурированный фидбек из локальных diff-артефактов, а check-impl-against-spec сравнивает изменения в PR с тем, что было написано в спеке. То есть можно буквально проверить: код соответствует документу или агент Again «улучшил» архитектуру по своему вкусу.
Отдельно нравится resolve-merge-conflicts — воркфлоу со вспомогательным скриптом для разрешения git-конфликтов с компактным контекстом. Конфликты — это как раз то место, где агенты часто ломают логику чужого кода, и выверенная процедура тут нужна как воздух.
Диагностика и исследования
diagnose-ci-failures — процедура разбора упавших GitHub CI джоб с выдачей плана фикса. fix-errors — похожая история для билдов, линтеров, форматирования и тестов. Часто сталкиваюсь с тем, что агент при ошибке сборки начинает хаотично пробовать варианты. Скилл задаёт порядок действий.
Два скилла стоят чуть в стороне — они про мышление, а не про код:
research— делегирует малополезные (low signal-to-noise) исследования субагентам и возвращает выжимку с доказательствамиcross-critique— несколько а��ентов независимо готовят предложения и критикуют друг друга, потом всё синтезируется в решение
Cross-critique выглядит как спор двух мидлов на архитектурном ревью, только быстрее и без обид. Не проверял на практике, но идея любопытная.
Скиллы для самих скиллов
Вот это, по-моему, самое остроумное в репозитории. skill-doctor оценивает установленные в репозитории скиллы, анализируя недавние локальные разговоры с агентами, и предлагает правки — на основе реальных данных о том, где скиллы помогли, а где агента загнали в тупик. update-skill — гайд по созданию и поддержке скилл-директорий.
То есть Warp метаподход: скиллы тоже проходят «код-ревью», основанное на телеметрии сессий. Не уверен, что без их внутренней инфраструктуры это сработает так же гладко, но направление правильное.
Как ставить
Установка идёт через CLI skills:
# посмотреть список доступных скиллов
npx skills@latest add warpdotdev/common-skills --list
# поставить один конкретный
npx skills@latest add warpdotdev/common-skills --skill write-tech-spec --agent warp --global
# поставить всё сразу для Warp глобально
npx skills@latest add warpdotdev/common-skills --skill '*' --agent warp --global
# обновить позже
npx skills@latest update --global --agent warp
Флаг --agent warp намекает, что основной адресат — Warp-терминал с его AI-агентами. Но скиллы это обычные Markdown-файлы, так что можно просто скопировать нужные директории из .agents/skills/ в свой проект — или вручную, или через sync. Claude Code, Cursor и прочие инструменты, читающие такие файлы, тоже смогут их использовать, хотя README про это прямо не пишет.
Как они советуют писать свои скиллы
Даже если ничего не устанавливать, README полезен как мини-гайд по архитектуре скиллов. Несколько принципов, которые Warp формулирует:
- Один скилл — одна директория под
.agents/skills/<имя>/с обязательным SKILL.md - Скилл описывает переиспользуемый воркфлоу, а не приватные детали конкретного репозитория
- Крупные справочные материалы уезжают в
references/, автоматизация — вscripts/ - При миграции скилла из другого репозитория сначала копировать, потом обобщать отдельным коммитом — чтобы легко отследить происхождение
Отдельно про обобщение: захардкоженные пути и названия заменяются на плейсхолдеры, локальные переопределения возвращаются в родной репозиторий, а описание скилла должно быть достаточно широким, чтобы срабатывать в нескол��ких проектах, но достаточно узким, чтобы не срабатывать на нерелевантных задачах. Это тонкий баланс, и Warp прямо пишет, что на этапе миграции допускаются неточности.
Кому это пригодится. Если вы всерьёз используете AI-агентов в ежедневной работе (Warp, Claude Code, что угодно) и хотите не переписывать одни и те же инструкции в каждом проекте — ставьте пару скиллов и смотрите. Мой выбор для старта: write-pr-description и diagnose-ci-failures, они приносят пользу сразу и не требуют перестройки процесса.
Если вы строите собственную систему знаний для агентов в команде — репозиторий стоит почитать целиком ради структуры и принципов обобщения скиллов. MIT-лицензия позволяет брать и адаптировать свободно.
Честности ради: проект молодой, звёзд около 350, документа��ия в README скупая — про интеграцию с агентами кроме Warp придётся думать самому. И судя по репозиторию, язык основного кода — Python, так что при желании можно копнуть и в скрипты. Но как образец того, как организация упаковывает свои AI-процедуры в переиспользуемые артефакты, это одна из самых внятных вещей, что я видел за последнее время.
