Superpowers для Claude Code: установка, навыки и процесс разработки

Что такое Superpowers для Claude Code?

Superpowers — это библиотека инженерных навыков, созданная Jesse Vincent, и инструкции, которые побуждают агента применять эти навыки при работе с кодом. В Claude Code, помощнике Anthropic для работы с репозиторием, плагин задаёт порядок разбора требований, планирования изменений, тестирования, отладки, делегирования и завершения работы над веткой. Представьте рабочий регламент мастерской: инструменты уже есть, а регламент определяет последовательность действий и проверки перед сдачей работы. README Superpowers

Проверено 18 октября 2026 года: в манифесте исходного кода указана версия 7.0.0, а в репозитории находятся 15 папок навыков верхнего уровня с файлом SKILL.md. Это состояние исходников, изученных для статьи; отдельно проверьте, какую ревизию устанавливает выбранный вами каталог плагинов. Манифест плагина, каталог навыков

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

Установка Superpowers в Claude Code

Выберите один из способов установки в README проекта и выполните его внутри Claude Code. Команды ниже в точности скопированы из раздела README о Claude Code. Это интерактивные команды со слешем, а не команды для обычного терминала. Инструкция по установке в README

Как установить плагин Superpowers из официального каталога

/plugin install superpowers@claude-plugins-official

Разработчик также описывает установку через собственный каталог плагинов. Если выбираете этот способ, сначала подключите каталог, затем установите плагин:

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

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

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

Что меняется в сессии после установки?

Первым меняется контекст: хук запуска добавляет в диалог инструкции по использованию Superpowers. В настройках SessionStart заданы события startup, clear и compact. Скрипт читает using-superpowers, добавляет его текст в контекст и предписывает Claude загружать остальные навыки через инструмент Skill. Полное содержимое всех навыков в стартовое сообщение не вставляется. Конфигурация хука, скрипт запуска

Как Claude выбирает навык Superpowers

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

Поэтому запрос на создание чего-либо указывает на brainstorming, а падающий тест — на systematic-debugging. Дальнейшую реализацию может направлять навык для конкретной предметной области. Можно и прямо назвать нужный навык: «Используй superpowers:systematic-debugging, чтобы разобраться в этом сбое, прежде чем предлагать исправление». Инструкции по использованию

Автоматический выбор — это инструкция для модели, а не жёсткий переключатель по ключевым словам. Хук передаёт стартовый текст, но агенту ещё нужно распознать ситуацию и выполнить выбранные инструкции. Если он выбрал неподходящий процесс, уточните границы задачи или прямо запросите нужный навык.

Навыки Superpowers: когда какой применяется

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

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

Как Superpowers сочетается со встроенным режимом планирования и вашими навыками

Superpowers задаёт процесс вокруг планирования; его навык writing-plans и встроенный режим планирования Claude Code — разные вещи. Текущие стартовые инструкции прямо требуют вызвать brainstorming перед входом в режим планирования, если этот этап ещё не пройден. Тем самым плагин определяет порядок действий, а не приравнивает встроенный режим к своему навыку написания планов. Текущая инструкция по планированию

writing-plans создаёт документ в репозитории, обычно в docs/superpowers/plans/, с решениями по реализации и проверками. Перед передачей работы дальше он просит пользователя изучить план и выбрать способ выполнения, если выбор не был сделан заранее. Само по себе переключение режима не создаёт ни такого документа, ни инструкций к задачам. Управление встроенным режимом и его поведение разобраны в отдельном руководстве по режиму планирования Claude Code.

Ваши собственные навыки тоже остаются в работе. Файл writing-skills указывает ~/.claude/skills/ как каталог личных навыков Claude Code, а стартовые инструкции явно ставят указания пользователя, включая CLAUDE.md и прямые запросы, выше инструкций навыков. Поэтому навык конкретного проекта может задавать ваши соглашения, а Superpowers — процесс разработки. Чётко разграничьте их роль, если оба источника предписывают, как проводить тестирование или ревью. Файл о создании навыков, приоритет инструкций

Сам механизм файлов с инструкциями разобран в статье о навыках агентов. Superpowers — одна из подборок, построенных на этом механизме, со своим подходом к работе.

Superpowers в Claude Code: одна функция от идеи до слияния

Переключателя «Скрыть завершённые» достаточно, чтобы показать весь процесс. Ниже — учебный пример, составленный по файлам навыков, а не запись реальной тестовой сессии. Имена файлов, приёмочные сценарии и результат вымышлены.

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

Уточняем поведение: brainstorming

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

Claude пересказывает эти границы задачи и получает согласие. Поскольку пользователь выбрал письменный вариант, описание решения сохраняется в документе внутри docs/superpowers/specs/ и перед передачей дальше проходит проверку с точки зрения реализации. Обычный сценарий этого навыка для небольших изменений позволяет оставить описание и согласование в чате. Правила brainstorming

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

Делаем работу проверяемой: writing-plans

План разбивает функцию на результаты, которые можно проверить независимо. Одна задача — реализовать функцию фильтрации в условном файле src/tasks/filterTasks.ts и протестировать смешанный, пустой и полностью завершённый списки. Другая — подключить в src/tasks/TaskList.tsx переключатель с поддержкой доступности, используя согласованный интерфейс функции, и проверить видимый результат.

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

Подготавливаем рабочую директорию: using-git-worktrees

Перед выполнением Claude проверяет, изолирована ли работа уже сейчас. Git worktree — это ещё одна рабочая директория репозитория, обычно со своей веткой. Навык отдаёт предпочтение встроенному механизму worktree в среде выполнения и учитывает ранее выраженное пожелание пользователя; в остальных случаях спрашивает перед созданием.

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

Реализуем задачи: subagent-driven-development и test-driven-development

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

Внутри реализации test-driven-development задаёт цикл «красный — зелёный — рефакторинг». В нашем случае тест сначала показывает, что запрос отфильтрованного списка по-прежнему возвращает завершённую задачу. Только увидев это падение, исполнитель добавляет фильтрацию, заново запускает тест и приводит код в порядок, сохраняя успешное прохождение тестов. Инструкции по TDD

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

Альтернатива — executing-plans: Claude сам выполняет план в текущей сессии, а в конце, если субагенты доступны, привлекает отдельного ревьюера для всей ветки. Выбирайте этот вариант, если вам не нужна передача каждой задачи отдельному исполнителю с последующим ревью. Инструкции по выполнению в текущей сессии

Разбираем замечания: навыки ревью и systematic-debugging

На итоговом ревью ветки requesting-code-review задаёт порядок передачи работы ревьюеру. Допустим, тот обнаружил, что после выключения переключателя завершённые задачи не возвращаются. receiving-code-review требует сначала сверить замечание с кодом и ожидаемым поведением и лишь затем что-либо менять. Запрос ревью, работа с замечаниями

Если сбой воспроизводится, исследование направляет systematic-debugging. Его этапы — поиск первопричины, анализ закономерностей, проверка гипотез и реализация. В нашем примере гипотеза может быть такой: код заменил исходную коллекцию отфильтрованной. Нужно проследить этот поток данных, воспроизвести потерю задач и устранить причину, добавив регрессионный тест. Просто подогнать внешний вид переключателя под ожидаемый результат недостаточно. Инструкции по отладке

Подтверждаем результат и выбираем способ слияния

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

Затем finishing-a-development-branch проверяет полный набор тестов и предлагает варианты интеграции. Для обычной именованной ветки текущий файл предлагает локальное слияние, отправку ветки с созданием pull request или сохранение ветки. Навык ждёт решения пользователя: успешное ревью само по себе не даёт разрешения на слияние.

В завершение нашего примера пользователь выбирает локальное слияние в согласованную базовую ветку. Claude выполняет слияние, тестирует объединённый результат и только после успешной проверки удаляет рабочий worktree и ветку функции. Если бы пользователь выбрал pull request, работа осталась бы ждать принятого в репозитории процесса слияния. Инструкции по завершению ветки

Когда небольшой задаче нужен более простой процесс

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

Текущий файл brainstorming различает три масштаба:

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

Тот же файл позволяет пользователю явно отказаться от вопросов и на этом завершить этап brainstorming. Такой отказ сам по себе не отменяет остальные инструкции по тестированию и проверке результата. Правила выбора масштаба и отказа от вопросов

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

Основное ограничение — накладные расходы процесса: дополнительные обсуждения, документы с планами, назначения исполнителей и ревью могут оказаться несоразмерны оставшейся неопределённости. Исходники описывают эти шаги, но не говорят, сколько минут займёт именно ваше изменение. Если сессия раз за разом выходит за заданные рамки, в репозитории есть diagnosing-superpowers: этот навык помогает разобраться в происходящем по записям диалога. Навык диагностики сессии

Какие ожидания от Superpowers завышены?

Заданный порядок работы не доказывает ни корректность программы, ни ускорение разработки. Падающий тест может закреплять неверное требование, план — упускать ограничение интеграции, а агент-ревьюер — не замечать дефект. Оценивайте условия проверок и diff, а не уверенный тон сообщения о завершении.

Работа через субагентов также не означает, что все задачи реализации выполняются одновременно. Текущий навык прямо запрещает параллельный запуск субагентов-исполнителей в этом процессе, чтобы избежать конфликтов. dispatching-parallel-agents — отдельный навык для независимых проблем. Правила назначения исполнителей

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

Кому стоит установить Superpowers и с чего начать

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

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

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

О смежных инструментах, которые решают другие задачи, читайте в подборке лучших плагинов Claude Code.

Вопросы о Superpowers для Claude Code

За практическими советами по разработке с ИИ подписывайтесь на рассылку.