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

Как устроен самый популярный набор скилов для AI-агентов, что делают brainstorming, writing-plans и subagent-driven-development, как его поставить и пройти первую задачу.

- Автор: Guide DAO
- Опубликовано: 2026-10-24
- Теги: Claude, Вайбкодинг
- Страница: https://www.guidedao.xyz/blog/superpowers-dlya-claude-code

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

В README автор называет Superpowers методологией разработки для AI-агентов, собранной из скилов. С ним агент не пишет код сразу: сначала он расспрашивает, чего вы хотите на самом деле. Японский аккаунт opensourcelab9 в [подборке](https://x.com/opensourcelab9/status/2111343980743098541) для Claude Code и Codex описал это одной строкой: агент переспрашивает о задаче и идёт по порядку от дизайна к плану, реализации и проверке. Как Claude Code вообще подгружает скилы, мы разбирали в [отдельной статье](https://www.guidedao.xyz/blog/skily-v-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` стоят выше скилов, так что любой шаг можно отменить своим правилом.

Как работают такие хуки, есть в нашей [статье о хуках](https://www.guidedao.xyz/blog/huki-v-claude-code).

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

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

```bash
/plugin install superpowers@claude-plugins-official
```

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

```bash
/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 нашли ещё одну ловушку. По [заметкам к релизу](https://github.com/obra/superpowers/blob/main/RELEASE-NOTES.md), после компактинга Claude Code заново прикладывает каждый скил, обрезанный до 20 тысяч символов. В одном сеансе `subagent-driven-development` потерял из-за этого правило о пяти раундах исправлений и прогнал 18 раундов на одной задаче. Длинные разделы трёх скилов вынесли в папку `references/`, агент читает их с диска на нужном шаге, а тест в репозитории теперь падает, если `SKILL.md` дорастает до 20 тысяч байт.

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

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

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

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

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

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

Второй приём из `writing-skills` касается собственных скилов. Автор предлагает писать их по TDD: сначала дать субагенту задачу без скила и записать, какими словами он оправдывает нарушение правила, потом написать скил против этих оправданий и проверить снова. Отсюда в скилах Superpowers таблицы Red Flags, где мысль агента вроде «это слишком простая задача» стоит рядом с ответом на неё. Как разделять работу между субагентами, мы разбирали в статье «[Один агент или субагенты](https://www.guidedao.xyz/blog/odin-agent-ili-subagenty)».

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

Набор тяжёлый. В пятнадцати `SKILL.md` около 22 тысяч слов, и для правки на десять строк полный путь от расспроса до выбора способа слияния займёт больше времени, чем сама правка. Правило одного процента заставляет агента открывать скилы даже на простых вопросах, и README признаёт, что скил иногда срабатывает там, где не нужен. Для таких случаев есть `diagnosing-superpowers`: попросите агента выяснить, что пошло не так с Superpowers в этом сеансе, и он разберёт транскрипт со ссылками на строки.

Вариант subagent-driven стоит свежего контекста на каждую задачу и каждое ревью. Если план подробный, а модель сеанса дорогая, native обойдётся дешевле, и `writing-plans` сам предлагает этот выбор. Сами вопросы `brainstorming` автор продолжает настраивать: в 7.0.0 пользователи жаловались, что они однообразны и быстро надоедают, и в 7.0.1 скил переписали.

Ещё одна деталь из README: опциональный визуальный помощник брейншторма грузит логотип Prime Radiant с сайта компании и передаёт номер версии. Отключается это переменной окружения `SUPERPOWERS_DISABLE_TELEMETRY`, набор учитывает и стандартные `DISABLE_TELEMETRY` и `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC`.

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

Курс Guide DAO: [Основы Claude Code](https://www.guidedao.xyz/claude)