shadcn/improve: агент-аудитор пишет планы для дешёвых моделей

В трендах GitHub на этой неделе — shadcn/improve, агентный скилл под MIT-лицензией. Его автор — shadcn, тот же, чьи UI-компоненты стоят половину современных React-проектов. На 13 ноября у репозитория около 11,6 тыс. звёзд, создан он в июне 2026, последний коммит — в сентябре.

Формулировка в описании репозитория короткая и точная:

«Use your most capable model to audit your codebase and write plans for cheaper models to execute».

То есть: самую дорогую модель ставят туда, где интеллект накапливается — понять код, решить, что вообще стоит делать, написать спецификацию. А исполнение передают дешёвым моделям.

вы            →  /improve                    (дорогая модель, советует)
plans/        →  001-fix-n-plus-one.md       (самодостаточные спеки)
другой агент  →  реализует, тестирует, сдаёт (дешёвая модель, исполняет)

Ключевая мысль автора: продукт — это план, а не код. Сам скилл не реализует ничего.

Как это устроено

Пайплайн из пяти шагов, который README описывает довольно откровенно:

Recon. Скилл составляет карту репозитория: стек, конвенции, точные команды сборки, тестов и линтера — они потом становятся гейтами проверки в каждом плане. Если в проекте есть ADR, PRD, CONTEXT.md, DESIGN.md или PRODUCT.md, скилл их читает, чтобы уже принятые решения не всплывали снова как «находки».

Audit. Параллельные субагенты проходят девять категорий: корректность, безопасность, производительность, покрытие тестами, техдолг, зависимости и миграции, DX, документация и направление развития. Каждая находка несёт file:line, оценку влияния, трудоёмкости и уверенности. Про идеи развития отдельно оговорено: каждая должна опираться на доказательства из самого репозитория — «никакого generic idea-slop».

Vet. Субагенты склонны переотчитываться, поэтому советующая модель перечитывает каждую цитату сама, прежде чем показать список. Ложные срабатывания отбрасываются, ошибочные привязки исправляются, а отказы записываются — чтобы не возвращаться к ним на следующем прогоне.

Prioritize. Находки выстраиваются по «рычагу»: влияние, делённое на трудоёмкость, с поправкой на уверенность. Дальше вы выбираете, что превратить в планы.

Plan. На каждый выбранный пункт — отдельный markdown-файл в plans/, плюс индекс с порядком и графом зависимостей.

Почему такие планы вообще исполняемы

Это самая практичная часть README. План пишется для самого слабого правдоподобного исполнителя — модели, которая не видела сессию советника и может быть заметно меньше. Работают три свойства:

• Самодостаточность. Внутри плана — точные пути, выдержки текущего кода, конвенции репозитория с файлом-образцом и проверенные команды. Никаких «как обсуждали выше».
• Гейты проверки. Каждый шаг заканчивается командой и ожидаемым выводом. Критерий готовности машинно проверяемый — исполнителю не нужно самому решать, получилось ли.
• Жёсткие границы. Явные списки «вне скоупа» и условия STOP — «если X, остановись и доложи», вместо того чтобы маленькая модель импровизировала, когда реальность не совпала с планом.

Плюс каждый план фиксирует git-коммит, против которого написан, — исполнитель сначала механически проверяет, не уехал ли код.

Что умеет по командам

/improve                        полный аудит → приоритизация → планы
/improve quick                  дешёвый проход: горячие точки и топ находок
/improve deep                   исчерпывающе: каждый пакет, каждая категория
/improve security               сфокусированный аудит (также perf, tests, bugs)
/improve branch                 аудит только того, что меняет текущая ветка
/improve next                   идеи развития — куда двигать проект
/improve plan <описание>        без аудита: спецификация одной задачи
/improve review-plan <файл>     критика и затягивание существующего плана
/improve execute <план>         запуск дешёвого исполнителя + ревью его работы
/improve reconcile              обновление бэклога: проверить, разблокировать, списать
/improve ... --issues           опубликовать планы как GitHub issues

Отдельно стоит execute: он поднимает дешёвого субагента в изолированном git worktree, отдаёт ему план, потом ревьюит результат как тимлид — перезапускает каждый критерий готовности, проверяет соблюдение скоупа, читает diff на соответствие замыслу. Вердикт: approve (мерж всё равно за вами), на доработку (максимум два круга) или блок с уточнением плана.

Есть и «жёсткие правила»: скилл сам код не меняет — пишет только в plans/; не выполняет команд, которые мутируют рабочее дерево; не воспроизводит значения секретов (только места и типы, с рекомендацией ротации). Просьбу «просто реализуй» он отклоняет и указывает на план.

Чем это полезно на практике

Идея «дорогая модель думает, дешёвая делает» — это, по сути, разделение труда в агентной разработке. Раньше экономия шла за счёт «сделай всё дешёвой моделью и молись», теперь — за счёт качества постановки задачи. Если спека самодостаточна и проверяема, исполнителю не нужен большой контекст и дорогая модель: ему нужен точный план.

Второй практический эффект — аудит перестаёт быть разовым. Находки и отказы записываются, reconcile возвращается к ним позже: что сделано, что уехало, что разблокировалось. Бэклог техдолга живёт в репозитории, а не в голове разработчика.

Как это может вписаться в наш стек

Сразу оговорюсь честно: мы этот проект в прод не внедряли. Всё ниже — разбор по README и репозиторию, а не отчёт о практике.

Где идея выглядит применимой:

Разработка сайта и CRM. Наш стек — Astro и Next.js на фронте, Python и PHP на бэке. Перед доработками логично прогнать /improve branch: аудит только изменений текущей ветки, без «переписать всё». Для безопасности — /improve security как дополнение к обычному ревью, а не замена сканеру зависимостей.

Контент-завод. Тот же принцип работает и вне кода: сильная модель пишет подробное ТЗ на материал или на изменение пайплайна, рутинное исполнение уходит более дешёвым агентам. Требование «самодостаточный план с проверяемыми гейтами» дисциплинирует постановку задачи не хуже, чем сам аудит.

Мониторинг. Тут важно не перепутать: improve смотрит код, а не конфигурацию серверов. Его security-категория не заменяет отслеживание CVE в nginx, PHP, ядре и зависимостях — это два разных контура, и оба нужны.

Что стоит учесть перед установкой: нужен агент с поддержкой формата Agent Skills (установка — npx skills add shadcn/improve); проект молодой и последняя активность в репозитории — сентябрь 2026, так что API и поведение могут меняться; и главное — это инструмент для разработки, а не для бизнес-аудита. Он не скажет, что вам нужно поменять модель продаж, — он скажет, где в коде N+1-запрос и дублирование конфигурации.

Репозиторий: github.com/shadcn/improve

📞 +7 (906) 311-77-69 · ✉ hello@automata.sale · 💬 Telegram: @automatasale · 🌐 automata.sale

ИП Урядов Евгений Евгеньевич · ИНН 645112058391 · ОГРНИП 312645301900058 Работаем по России, Беларуси и Казахстану