Superpowers для Claude Code: 4 плюса и одна реальная цена

Superpowers, это плагин для Claude Code, написанный Джесси Винсентом, который выпускает open source инструменты для разработчиков с 1990-х. Он опубликовал его в октябре, и меньше чем через год у репозитория 280 000 звёзд и 25 000 форков, а последний пуш случился за два дня до нашей записи. Проект уже на шестой мажорной версии с 681 коммитом в основной ветке, так что это не сборник промптов, брошенный после всплеска на запуске.

Показатель	Значение
Звёзды на GitHub	280 000
Форки	25 000
Мажорная версия	6
Коммиты в main	681
Открытые issues	125

Ставка Винсента умещается в одну фразу: кодинг-агентам не хватает не способностей, а дисциплины. Эта дисциплина поставляется в виде простых markdown-файлов, которые каждый может прочитать, форкнуть и адаптировать. Мы установили плагин, прочитали все четырнадцать скиллов строчка за строчкой и посмотрели, что он меняет по четырём направлениям: продуктивность, надёжность кода, расход токенов и документация.

Superpowers, это бесплатный open source плагин для Claude Code. Он живёт в официальном маркетплейсе плагинов Anthropic и устанавливается одной командой. Та же методология существует для более чем десятка других харнессов, включая Cursor, Codex и Gemini, у каждого свой путь установки.

Ядро составляют четырнадцать скиллов: markdown-файлы с инструкциями, которые агент загружает, когда ситуация им соответствует. Брейншторм, написание планов, разработка через субагентов, разработка через тестирование и систематическая отладка описывают каждый свой полный способ работы, со своими чеклистами и ограничителями. Скилл отладки запрещает предлагать исправление, пока не изолирована первопричина. Скилл верификации заставляет агента доказать, что работа завершена, а не просто заявить об этом. Каждый скилл объявляет о себе при загрузке, так что вы всегда знаете, в каком режиме работает агент.

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

Винсент описывает происхождение проекта в своём блоге. Он собрал скиллы, перебрав 2 249 markdown-файлов с уроками, которые усвоили его собственные агенты, а затем проверил черновики на прочность по тем же архивам. Методология извлечена из реальных провалов агентов, а не написана из теории.

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

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

Путь	Определение	Результат
Спайк	Вопрос о выполнимости	Ответ, а не код, который вы оставляете
Ограниченная	Небольшая правка в потоке, который уже существует в репозитории	Изменение с чёткими рамками
Архитектурная	Всё, что перестраивает то, как проект собран воедино	Спека, которую вы утверждаете, затем план реализации

Агент озвучивает свою классификацию, чтобы вы могли её переопределить, а храповик крутится только в одну сторону: скрытая сложность, обнаруженная посреди задачи, повышает путь, но никогда не понижает. В файле есть таблица тревожных сигналов, мыслей вроде «это слишком просто, чтобы нуждаться в дизайне», и рядом контраргумент: именно на простых задачах непроверенные допущения обходятся дороже всего. Даже у спайка остаётся ограничитель. Всё, что агент строит ради ответа на вопрос, помечено как одноразовое, а желание оставить этот код становится новым запросом на классификацию.

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

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

Конкретно работа режется на задачи, где каждый шаг занимает от двух до пяти минут: написать падающий тест, запустить его и убедиться, что он падает, написать минимальный код, который его проходит, снова прогнать тесты, закоммитить. Одно действие, одна проверка, и работа двигается частыми коммитами. Это цикл разработки через тестирование, который навязывает другой скилл плагина, так что у каждой задачи свой тестовый цикл.

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

Размер задачи, это сердце аргумента о надёжности. Короткая задача означает агента, который заканчивает работу с почти пустым контекстным окном. Он никогда не доходит до момента, когда сессия переполняется, агент теряет нить и начинает выдумывать несуществующие функции. Ни одна пятиминутная демка этой проблемы не показывает, но на реальном проекте она решает всё: качество агента в конце сессии не имеет ничего общего с его качеством на первом промпте. Менее насыщенный контекст механически означает меньше галлюцинаций и код, который делает то, что сказано в плане.

На этапе исполнения отдельный скилл изолирует работу в Git worktree, отдельной рабочей копии репозитория, так что план выполняется, не мешая тому, чем вы занимаетесь рядом.

Исполняющий скилл ведёт разработку через субагентов. Его принцип умещается в одну строку файла: свежий субагент на каждую задачу, ревью после каждой задачи и общее ревью всей ветки в конце. Ваша основная сессия становится оркестратором. Она больше не кодит, она раздаёт задачи. Каждый субагент получает ровно тот контекст, который нужен его задаче, и никогда историю вашей сессии, что избавляет от загрязнения контекста и оставляет ваше собственное окно свободным для координации.

Субагент может задать вопросы перед стартом, затем реализует, тестирует, коммитит и сам ревьюит свою работу. Когда он закончил, оркестратор проводит ревью в две части: сначала соответствие спеке, потом качество кода, с отдельным ревьюером на каждую задачу. Ничего не импровизируется: у скилла есть шаблон промпта для каждой роли (исполнитель, ревьюер задачи и ревьюер, который перепроверяет исправления), и оркестратор заполняет его контекстом задачи.

Итог ревью	Что происходит
Пройдено	Оркестратор отмечает выполнение в журнале и идёт дальше по плану
Провал, раунды с 1 по 3	Исходный исполнитель продолжает, поскольку уже знает код и свои решения
Провал, раунд 4	Отправляется свежий исполнитель на более способной модели
Провал, раунд 5	Срабатывает предохранитель, и оркестратор сам выносит решение по каждому открытому замечанию

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

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

Задача	Уровень модели
Хорошо описанная механическая задача, затрагивающая один-два файла, или план, в котором уже есть код для написания	Самый дешёвый уровень (реализация превращается в переписывание плюс тестирование)
Координация между несколькими файлами, отладка	Стандартная модель
Архитектура, финальное ревью ветки	Самая способная из доступных моделей

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

Такая настройка делает жизнеспособным нечто контринтуитивное: гонять Opus или Fable, самые дорогие модели в каталоге, на Pro-плане за 20 долларов. Дорогая модель работает только над теми немногими решениями, которые этого заслуживают, а остальная часть плана выполняется на моделях, потребляющих долю вашей квоты.

Последний выигрыш тот, о котором никто не думает, устанавливая плагин. Спеки и планы, это не сообщения в чате, исчезающие с концом сессии. Это markdown-файлы, сохранённые внутри репозитория и закоммиченные вместе с работой. Скилл фиксирует расположение: папка планов с датами, один файл на фичу, с целью, архитектурой и ссылкой на спеку в шапке.

Спека путешествует вместе с планом, и конфликты между ними решаются в пользу спеки: авторитет у документа, а не у памяти агента. История Git теперь рассказывает не только о том, что изменилось. Она рассказывает, почему, и что агент решил в тот момент. Полгода спустя упоминание файла плана в промпте позволяет агенту сразу подхватить контекст исходной фичи, а новая фича, затрагивающая ту же подсистему, строится на существующей спеке, а не открывает территорию заново.

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

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

На правке в две строки это значит отвечать на вопросы о рамках, утверждать дизайн из двух фраз, а потом ждать полного цикла, прежде чем увидеть исправление. Для опечатки в конфиге полный процесс попросту медленнее, чем поправить самому. Сама оркестрация тоже тратит токены: брифы для раздачи, два ревью на задачу и журнал оплачиваются каждый раз, и сильнее всего это чувствуется на самых мелких задачах.

Есть и обратный симптом, и он напрямую отвечает на вопрос с Reddit. Если статистика использования показывает плагин на паре процентов, ваши запросы почти никогда не запускают скиллы, так что вы платите за входную проверку в каждой сессии, не касаясь выигрышей. Цикл исправлений, дошедший до всех пяти раундов, это пять диффов, ещё пять ревью и арбитраж ради задачи, которая должна была занять минуты. Проект к тому же не стоит на месте: он прошёл от первой версии до шестой меньше чем за год, и у него всё ещё 125 открытых issues, так что скиллы, которые вы читаете сегодня, изменятся к следующему обновлению.

Плагин сам планирует свой выход. Его инструкции ставят ваши указания выше скиллов, так что вы можете явно сказать агенту пропустить процесс. Наше правило: Superpowers включён по умолчанию для любой работы над фичами и осознанный skip для мелких фиксов.

Как вы используете Claude Code	Вердикт
Фичи, которые занимают часы	Ставьте: рамки удерживают вас от реализации не того, короткие задачи держат агента вдали от насыщения контекста, выбор модели растягивает квоту, и вы получаете документацию, которую никогда бы не написали
Одноразовые скрипты и мелкие фиксы	Проходите мимо: вы заплатили бы фиксированную стоимость процесса на задачах, которым он не нужен
Между ними	Ставьте и учитесь говорить skip: одна фраза в промпте возвращает контроль вам

Если хотите протестировать его, не принимая всё сразу, дайте на несколько дней работать только скиллу брейншторма. Он несёт большую часть выигрыша, а остальные скиллы естественно подтянутся за ним. Плагин держит четыре обещания, пока вы кормите его фичами, достойными его церемонии. Он теперь работает на наших собственных проектах, и фазу брейншторма мы бы уже не отключили. Репозиторий бесплатный и open source, а в очереди перед вами 280 000 человек.