Каждый уважающий себя инженер, помимо дома, дерева и сына, должен сделать свой какой-нибудь стартапчик. В текущих реалиях те, кто недостаточно ленив, наверняка написали себе ряд скиллов для работы, которые постоянно используют. Я решил поделиться своими наработками, которые регулярно использую. Разрешите представить: мой бро… АИ бро!

Это первый же вопрос, который мне задали :D А всё дело в том, что мой опыт работы с этим плагином довольно-таки негативный, сразу по ряду причин:

• TDD — о да! То, что обожает любой инженер, и пропагандируют, наверно, 90% всяких скиллов, — это подход написания тестов до реализации. На бумаге идея хорошая, но на практике это получается очень криво. Пишем e2e-тесты, смотрим, что они валятся, пишем реализацию под эти тесты. В итоге тратим время на то, чтобы написать тесты, проверить, что они красные, написать реализацию, проверить, что тесты зелёные. Затем смотрим глазками сценарий, который нам наделал агент, вносим корректировки и заново начинаем наш весёлый карнавал: тесты — упали — поправили. Просто перекладываем байтики с места на место, потому что TDD.

• Чересчур детализированные планы. Планы — это очень хорошо, но когда каждый шаг плана выглядит как псевдокод, который в итоге будет написан, возникает огромный вопрос: а зачем тогда нужны эти планы? Пиши сразу код — я потом его посмотрю!

Пробовал я использовать весь флоу на 2–3 задачах, и меня эта картина стала сильно удручать. Стоит отметить единственный плюс, который я заметил, — это скилл brainstorming, который обеспечивает хороший и приятный UX при обсуждении.

Концепция этой поделки мне очень понравилась, именно с ними я открыл для себя SDD. Большую часть времени я работал именно с OpenSpec. У него регламентированный и чётко построенный процесс. Минусы, которые я в нём заметил, — это непосредственно спецификации: они слишком многословные, и их много. Для стандартизации работы это хороший подход, но это не очень гибкая история.

Все что меня не устраивало в сторонних инструментах, я попытался порешать в своих собственных скиллах. Тут я убивал сразу же двух зайцев: вникал в скиллостроение (если это можно так назвать :D), и обустраивал свой рабочий флоу, чтобы он стал максимально удобным и эффективным.

Работу над большинство задач можно четко разделить на 3 этапа:

• обсуждаем

• планируем

• делаем

Любое общение с агентом я начинаю непосредственно с обсуждения: я никогда не говорю, что делать сразу (если речь не про что-то мелкое и конкретное), потому что агенты — довольно безвольные существа и побегут делать любую вашу прихоть, даже если она абсолютно неадекватна задаче. При работе с Cursor очень часто использую режим «ask».

Собственно, так и родился скилл bro-think-with-me. Второе, что мне бросилось в глаза при работе с агентами, — так это то, что они вываливают кучу вопросов на тебя сразу же. Первое это конечно же их беспрекословное повиновение. Поэтому в данном скилле заложены правила диалога, когда агент задаёт строго по одному вопросу (да-да, подглядел у brainstorming).

Со временем я понял, что для разных запросов нужна немного разная стратегия работы, поэтому внутри скилла образовались разные workflow в зависимости от запроса пользователя.

Ну и напоследок скилл бережёт контекст агента-оркестратора и максимально делегирует всё субагентам.

Если мы говорим про большую задачу, то следующим этапом хорошо бы сделать план (bro-give-me-plan) или спецификацию (bro-give-me-spec). Разница между артефактами лишь в том, что для спецификации мы фиксируем конечный результат без конкретных шагов реализации. То есть мы обозначаем, что мы хотим получить, и нам не принципиально, каким путём. Тут важно оговориться, что “нам не принципиально” не означает “делай как хочешь”, а лишь ограничивает рамки спецификации. Мы не допускаем говнокод инструкциями самого проекта: с указанными слоями, используемыми архитектурами, модульным разделением и так далее. Качество кода зависит от инструкции на конкретном проекте. Скиллы в это не лезут.

Сами MD-файлы спецификации и плана не привязаны ни к какой обвязке. Они просто в определённом шаблоне формируют техническое задание. Никаких скрытых статусов, или условных связей нет. Все четко пишется внутри самого MD файла, чтобы его можно было скормить любому агенту.

Помимо составления артефакта, в скиллы зашито автоматическое ревью черновика, чтобы глазками человек уже смотрел проверенную, качественную версию спецификации или плана.

Ну и переходим к реализации. Чтобы нам что-то сделать, достаточно просто попросить: bro-do-it :)

Скилл может работать как с артефактами, созданными из раздела выше, так и с другими MD-файлами, а может работать вообще без артефактов: в чатике просто написали ему задачу — и он пошёл делать.

Главная цель скилла — это выстроить процесс для качественной реализации задачи, а как именно она поставлена — это неважно. В ранних версиях я привязывал данный скилл к артефактам плана и спецификации, чтобы он лучше понимал, какие есть разделы у планов, какие там есть статусы, за что отвечают. По итогу это всё ненужная обвязка, ведь спеки и планы должны быть самодосточными сами по себе, и поэтому я сконцентрировал скилл на процессе разработки.

Внутри агент работает строго по итерациям. Чтобы агенты не сжигали токены, бесконечного цикла я не делал, а ограничил 10 итерациями. Сначала я поставил 5, но на сложных задачах практически всегда агент в них упирался.

Механика итераций:

1. определили задачу;

2. запустили субагента на реализацию;

3. выполнили ревью кода, в случае проблем — шаг 2;

4. выполнили проверку реализации, в случае проблем — шаг 2;

5. дописали в базу знаний проекта результаты нашей работы.

Шаги 3 и 4 отличаются глубиной проверки:

• на шаге 3 — классическая детальная проверка кода с разных сторон;

• на шаге 4 — проверка реализации на соответствие поставленной задаче.

В случае каких-то непоняток, даже при работе в режиме автопилота, агент выполняет эскалацию до человека для решения проблем. По моему опыту, это происходит крайне редко и чаще всего тогда, когда агент выжег все 10 итераций на ревью кода, не добираясь даже до верификации на шаге 4.

Необязательный шаг, который появился благодаря тому, что я в очередной раз забыл удалить спеки после принятия PR :) Спецификация и план — это временные документы, которые нет необходимости хранить вечно: это, наоборот, только мешает агенту, когда он начинает исследовать слой знаний и может путаться, не разбирая статусы артефактов. К тому же спеки и планы вполне успешно трансформируются в постоянный слой знаний проекта. В случае работы по полному флоу ai-bro после окончания работ нам необходимо прибрать за собой все артефакты через bro-finish-it.

На последок поговорим немного про оркестрацию. Мой основной инструмент — это Cursor. Я искренне не понимаю, почему всем нравится Claude Code и Codex Desktop в качестве harness (про модели я не говорю), и меня чертовски удручает, когда начинают восхищаться какой-то функцией Claude, которая живёт в Cursor уже много месяцев. Короче, в вопросах harness я типичный владелец Android, у которого «за 5 тыщ всё то же самое, что и в iPhone!» :D

Для тех, кто не знает, Cursor позволяет работать с большим количеством моделей от разных провайдеров внутри себя, поэтому вопрос оркестрации моделей под задачу встаёт сам собой.

В рамках скиллов я разделил модели на тиры с вполне очевидным уровнем ответственности для них:

• junior — простые, понятные задачи с чёткими шагами;

• middle — задачи со средним уровнем неопределённости, не очень объёмные;

• senior — всё остальное.

Вполне понятное разделение, которое сразу же поддерживал Claude (Haiku, Sonnet, Opus). Чуть позже к ним подключился Codex (Luna, Terra, Sol). А для остальных приходится страдать с настройкой усилия (effort) модели.

Через какое-то время мне пришлось добавить ещё и тир critical, который занимается исключительно вопросами безопасности и денег на моделях Fable, Astra и Argon. Отчасти потому, что жалко было их грузить сеньорскими задачами :D

ai-bro - это инструмент, который позволяет удобно и гибко выстроить работу с агентом. В первую очередь я делаю его для себя, чтобы облегчался мой ежедневный флоу. По ряду моментов он достаточно похож на существующие инструменты. В каких-то вещах он идёт вразрез с общими трендами (TDD я не добавлю никогда :D). Но, на мой взгляд, скиллы получились довольно универсальными и пригодятся наверняка не только мне.

Проект регулярно развивается. Любые проблемы, с которыми сталкиваюсь при моей работе, я стараюсь максимально быстро поправить, чтобы больше не страдать. Как бонус: если вам интересна тема скиллов и логики их составления, можете заглянуть внутрь на GitHub: всё написано на понятном и нормальном русском языке.

Репка с исходниками: https://github.com/irpsv/ai-bro

Лендос с картинками и описанием всех скиллов: https://irpsv.github.io/ai-bro/

Проголосовали 2 пользователя. Воздержавшихся нет.