Superpowers: скилы Джесси Винсента для Claude Code

Superpowers написал Джесси Винсент (Jesse Vincent, в X @obra) из компании Prime Radiant. Первый коммит в репозитории obra/superpowers появился 9 октября 2025 года, и за год он стал самым звёздным набором скилов на GitHub. В подборках самых звёздных наборов, которые в октябре расходились в X, он стоит первым, например в списке от 11 октября с 292 тысячами звёзд. 16 октября Винсент написал, что проект скоро станет двенадцатым в истории GitHub со 300 тысячами звёзд, а за две недели его клонировали больше 56 миллионов раз с 2 миллионов уникальных адресов. 24 октября GitHub показывал 304 тысячи звёзд. Статья описывает версию 7.0.1 от 21 октября, лицензия MIT.

В README автор называет Superpowers методологией разработки для AI-агентов, собранной из скилов. С ним агент не пишет код сразу: сначала он расспрашивает, чего вы хотите на самом деле. Японский аккаунт opensourcelab9 в подборке для Claude Code и Codex описал это одной строкой: агент переспрашивает о задаче и идёт по порядку от дизайна к плану, реализации и проверке. Как Claude Code вообще подгружает скилы, мы разбирали в отдельной статье.

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

В репозитории 15 скилов. Процесс ведут brainstorming, writing-plans, executing-plans, subagent-driven-development, dispatching-parallel-agents, using-git-worktrees, requesting-code-review, receiving-code-review и finishing-a-development-branch. Дисциплину задают test-driven-development, systematic-debugging и verification-before-completion. Ещё три служебные: using-superpowers объясняет агенту правила, writing-skills учит писать новые скилы, diagnosing-superpowers разбирает сеанс, в котором что-то пошло не так.

Точка входа здесь не команда, а хук SessionStart. При старте сеанса, после /clear и после компактинга он вставляет в контекст полный текст using-superpowers. Правило этого скила такое: если есть хотя бы один процент вероятности, что скил подходит к задаче, агент обязан его вызвать, причём до любого ответа, даже до уточняющего вопроса. Процессные скилы идут первыми: на «сделай X» агент открывает brainstorming, на «почини баг» открывает systematic-debugging. Инструкции пользователя из CLAUDE.md или AGENTS.md стоят выше скилов, так что любой шаг можно отменить своим правилом.

Как работают такие хуки, есть в нашей статье о хуках.

Как поставить

В Claude Code набор есть в официальном маркетплейсе плагинов:

/plugin install superpowers@claude-plugins-official

У автора есть и свой маркетплейс, где рядом лежат связанные плагины:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

В Codex CLI плагин ищут через /plugins, в приложении Codex он лежит в разделе Coding среди плагинов. В Cursor его ставят командой /add-plugin superpowers в чате агента. README описывает ещё дюжину агентов, от Gemini CLI до OpenCode, и предупреждает, что в каждый харнес Superpowers ставится отдельно.

В README есть простая проверка установки: откройте новый сеанс и попросите сделать список задач на React. Если всё работает, агент начнёт с brainstorming, а не с кода.

Первая задача по шагам

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

Второе: подходы и дизайн. Когда агент понял, что вы хотите, он отдельным сообщением показывает два-три способа сделать задачу, говорит, чем каждый жертвует, и рекомендует один. Потом оценивает размер работы. Для маленькой правки дизайн-документ занимает пару строк, для проекта это полный документ в docs/superpowers/specs/. Перед тем как отдать полный документ вам, агент отправляет его свежему субагенту, который читает текст как будущий исполнитель и выписывает, что ему пришлось бы уточнить. Пока вы не одобрили документ, агент не пишет код, не ставит зависимости и не создаёт проект: это правило в скиле так и называется, HARD-GATE.

Третье: план. using-git-worktrees создаёт отдельный ворктри на новой ветке и проверяет, что тесты зелёные до начала работы. writing-plans пишет план, в README его требования описаны так:

clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow.

Каждая задача в плане занимает две-пять минут работы и содержит точные пути файлов, сигнатуры, которые она отдаёт соседним задачам, падающий тест и команду проверки с ожидаемым выводом. Отдельный раздел Review Focus перечисляет пять входных данных или сбоев, которые спека подразумевает, но не покрывает ни одна задача, и к каждому добавляется тест. План сохраняется в docs/superpowers/plans/, агент просит его прочитать и выбрать способ выполнения.

Четвёртое: выполнение. Вариант subagent-driven отдаёт каждую задачу свежему субагенту-исполнителю, а после неё запускает ревьюера, который сначала сверяет код со спекой, потом оценивает качество. Вариант native делает все задачи в текущем сеансе и зовёт одного ревьюера на всю ветку в конце, он дешевле. В обоих случаях агент не спрашивает «продолжать?» между задачами. Спорные места он решает сам и записывает в журнал строкой Ruling:: что решил, почему и чего будет стоить ошибка. Остановиться он может только в четырёх случаях: необратимая операция, действие, связанное с безопасностью, побочный эффект за пределами ворктри вроде пуша в общую ветку и план, в котором любое продолжение будет догадкой.

Пятое: завершение. finishing-a-development-branch прогоняет все тесты и предлагает на выбор слить ветку локально, открыть пул-реквест, оставить ветку как есть или выбросить работу, а потом убирает ворктри.

Тест до кода, причина до исправления

test-driven-development устроен жёстко. Его железное правило: никакого кода без падающего теста. Если агент написал код раньше теста, скил велит удалить его и начать заново, не оставляя «для справки». Обоснование в одну строку: если вы не видели, как тест падает, вы не знаете, проверяет ли он нужное. Исключения (одноразовые прототипы, сгенерированный код, конфиги) агент согласует с человеком.

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

verification-before-completion закрывает самую частую жалобу на агентов, преждевременное «готово». Прежде чем заявить, что тесты проходят, агент должен запустить команду в этом же сообщении и прочитать вывод целиком. В таблице скила прямо сказано, что отчёт субагента об успехе ничего не доказывает, доказательство даёт diff в системе контроля версий.

Журнал, который переживает компактинг

Самая инженерная часть набора касается длинных сеансов. Контекст не переживает компактинг, и в реальных сеансах, как пишет автор в subagent-driven-development, агент терял место и заново раздавал субагентам уже сделанные задачи. Поэтому прогресс ведётся в файле progress.md внутри .superpowers/sdd/, а после компактинга агент верит журналу и git log, а не своей памяти.

В версии 7.0.1 нашли ещё одну ловушку. По заметкам к релизу, после компактинга Claude Code заново прикладывает каждый скил, обрезанный до 20 тысяч символов. В одном сеансе subagent-driven-development потерял из-за этого правило о пяти раундах исправлений и прогнал 18 раундов на одной задаче. Длинные разделы трёх скилов вынесли в папку references/, агент читает их с диска на нужном шаге, а тест в репозитории теперь падает, если SKILL.md дорастает до 20 тысяч байт.

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

Что взять, даже если не ставить

На наш взгляд, самое полезное в Superpowers переносится в свой CLAUDE.md без плагина: запрет на «готово» без свежего вывода команды, правило трёх неудачных исправлений и одобрение дизайна до кода. Примерно так:

## Готово
Прежде чем написать «готово» или «тесты проходят», запусти проверку в этом же ответе и процитируй итог. Отчёт субагента не доказательство, смотри diff.

## Баги
Сначала найди причину и покажи, где ломается. После трёх неудачных исправлений остановись и опиши, какое допущение может быть неверным.

## Новая фича
Перед кодом предложи два-три подхода с рекомендацией и дождись моего выбора.

Второй приём из writing-skills касается собственных скилов. Автор предлагает писать их по TDD: сначала дать субагенту задачу без скила и записать, какими словами он оправдывает нарушение правила, потом написать скил против этих оправданий и проверить снова. Отсюда в скилах Superpowers таблицы Red Flags, где мысль агента вроде «это слишком простая задача» стоит рядом с ответом на неё. Как разделять работу между субагентами, мы разбирали в статье «Один агент или субагенты».

Когда это лишнее