Дополнительные источники: https://mokevnin.github.io/agentic-coding-design-patterns/ru/superpowers.html, https://lzw.me/docs/opencodedocs/obra/superpowers/start/superpowers-intro/index.html
Зачем это нужно
В уроке 2.7 Superpowers уже появлялся как один из инструментов на карте specification-driven разработки: там была дана общая карточка — идея «процедуры вместо советов», базовый workflow, риски. С этого урока начинается полное погружение: весь модуль 17 — структурированный перевод документации самого проекта — его README.md, пятнадцати скиллов из каталога skills/ и вспомогательных документов.
Знать Superpowers важно по двум причинам. Во-первых, это самый популярный проект в своем классе: около 295 тысяч звезд GitHub на дату среза документации (2026-10-03) — то есть подход, который выбрали сотни тысяч разработчиков, стоит понимать из первоисточника, а не по пересказам. Во-вторых, Superpowers — редкий пример методологии, упакованной не в книгу и не в CLI-инструмент, а в набор поведенческих инструкций для агента: сам репозиторий — это и есть «продукт», и его устройство учит проектировать поведение агентов лучше, чем большинство туториалов.
Прежде чем разбирать установку (урок 17.2) и первый запуск (урок 17.3), нужно ответить на три вопроса: что это такое на самом деле, почему оно так устроено и где проходит граница между Superpowers и альтернативами из уроков 2.8 и 2.10.
Основная идея
Superpowers — это полная методология разработки ПО для coding-агентов, построенная поверх двух вещей: набора композируемых скиллов и начальных инструкций, которые заставляют агента эти скиллы использовать. Формулировка авторов: «An agentic skills framework & software development methodology that works».
Ключевой водораздел — не «более умный агент», а дисциплина процесса. Обычные правила проекта говорят агенту «пиши тесты, делай ревью, не усложняй» — и агент пропускает их, когда торопится. Superpowers задает обязательные контрольные точки (HARD-GATE): между замыслом и реализацией агент обязан остановиться, предъявить дизайн, дождаться вашего согласования. Скиллы срабатывают автоматически, по описанным в них триггерам, — и это не пожелания, а процедуры.
Что это такое и кто за этим стоит
Superpowers создал Джесси Винсент (Jesse Vincent, GitHub-ник obra) и команда Prime Radiant. Проект начался как набор скиллов для собственного workflow автора и вырос в фреймворк, который сегодня распространяется как плагины примерно для шестнадцати каркасов coding-агентов — от Claude Code и Codex до OpenCode, Cursor и Gemini CLI.
Масштаб на дату среза (2026-10-03, ветка main): ~295k звезд, ~26.3k форков, 683 коммита, 15 скиллов в ядре. Проект распространяется под лицензией MIT, развивается быстро, и детали могли измениться после среза — в каждом уроке модуля приведены прямые ссылки «Оригинал» для сверки.
Для курса важно, что Superpowers решает ту же задачу, что OpenSpec (модуль 15) и Spec Kit (урок 2.8) — заставить агента работать по процессу, а не наобум, — но другим механизмом: не через файлы спецификаций и CLI-команды, а через поведенческие инструкции, которые агент обязан применять в нужный момент.
Как это работает: путь одной задачи
README проекта описывает жизненный цикл так (перевод с сокращениями, детали — в уроках 17.6–17.12):
- Агент не бросается писать код. Как только агент видит, что вы что-то строите, он делает шаг назад и спрашивает, чего вы на самом деле пытаетесь достичь.
- Спека выуживается из диалога. Скилл brainstorming уточняет замысел вопросами и показывает дизайн порциями — короткими настолько, что их реально прочесть и переварить.
- План пишется для «джуниора без контекста». После вашего согласования дизайна агент составляет план реализации, понятный «энтузиасту-джуниору без вкуса, без суждений, без знания проекта и с отвращением к тестированию». План подчеркивает настоящий red/green TDD, YAGNI и DRY.
- Исполнение — сабагентами. После команды «go» запускается subagent-driven development: сабагенты проходят задачи одну за другой, контроллер инспектирует и ревьюит их работу. Агенты нередко работают автономно по несколько часов, не отклоняясь от согласованного плана.
- Скиллы срабатывают сами. Вам не нужно ничего особенного делать или запоминать — ваш coding-агент «просто имеет Superpowers».
Из этой схемы видно главное архитектурное решение: Superpowers не пытается заменить агента или каркас, он задает поведение поверх любого поддерживаемого harness-каркаса. Подробно механика срабатывания — формат SKILL.md, хук SessionStart, бутстрап — разобрана в уроке 17.4.
Базовый workflow: семь шагов
README фиксирует «The Basic Workflow» — каноническую последовательность семи скиллов. Она — каркас всего модуля; приведем ее с указанием уроков, где каждый шаг разобран детально.
| № | Скилл | Когда активируется | Что делает | Урок |
|---|---|---|---|---|
| 1 | brainstorming |
перед любой творческой работой | уточняет идею вопросами, исследует альтернативы, предъявляет дизайн секциями для валидации, сохраняет дизайн-документ | 17.6 |
| 2 | using-git-worktrees |
после согласования дизайна | создает изолированное рабочее дерево и ветку, запускает setup, проверяет чистый бейзлайн тестов | 17.7 |
| 3 | writing-plans |
с согласованным дизайном | разбивает работу на задачи по 2-5 минут; каждая задача — точные пути файлов, полный код, шаги верификации | 17.8 |
| 4 | subagent-driven-development или executing-plans |
с готовым планом | либо свежий сабагент на каждую задачу с ревью после каждой (основательнее), либо все задачи инлайн в текущей сессии с одним финальным ревью ветки (дешевле) | 17.9 |
| 5 | test-driven-development |
во время реализации | цикл RED-GREEN-REFACTOR: падающий тест → минимальный код → рефакторинг → коммит; код, написанный до теста, удаляется | 17.10 |
| 6 | requesting-code-review |
между задачами | ревью против плана, замечания по критичности; критические блокируют переход к следующей задаче | 17.11 |
| 7 | finishing-a-development-branch |
когда задачи завершены | проверяет тесты, предлагает опции (merge / PR / оставить / удалить), вычищает worktree | 17.12 |
И ключевая фраза README, которую стоит запомнить как определение всего проекта: «The agent checks for relevant skills before any task. Mandatory workflows, not suggestions» — агент проверяет применимость скиллов перед любой задачей. Это обязательные workflow, а не советы.
HARD-GATE: обязательные контрольные точки
Глава книги «Agentic Design Patterns» (уже на русском, см. источник) описывает Superpowers через понятие HARD-GATE — так в инструкциях проекта названы обязательные контрольные точки между дизайном и реализацией. Суть механизма:
- согласование требуется до начала реализации — для небольшой правки достаточно краткого дизайна в чате, для архитектурной задачи нужна письменная спецификация и план;
- «одобрил идею» не означает «одобрил спецификацию»: ответ агента согласовывает именно тот этап, который предъявлен, и не дает права пропустить остальные;
- while prerequisites не выполнены, агенту разрешена только read-only разведка проекта.
Это и есть операционализация принципа «процедуры, а не советы»: ворота нельзя перескочить, потому что следующий скилл не активируется, пока не закрыт предыдущий этап. Как HARD-GATE устроены внутри скилла brainstorming — в уроке 17.6.
Библиотека скиллов: карта
Весь Superpowers — это 15 скиллов в четырех категориях (полный справочник — урок 17.5):
| Категория | Скиллы |
|---|---|
| Testing | test-driven-development — цикл RED-GREEN-REFACTOR и справочник антипаттернов тестирования |
| Debugging | systematic-debugging (4-фазный процесс поиска корневой причины, включает root-cause-tracing, defense-in-depth, condition-based-waiting), verification-before-completion, diagnosing-superpowers |
| Collaboration | brainstorming, writing-plans, executing-plans, dispatching-parallel-agents, requesting-code-review, receiving-code-review, using-git-worktrees, finishing-a-development-branch, subagent-driven-development |
| Meta | writing-skills (как создавать скиллы по их же методологии), using-superpowers (введение в систему скиллов, бутстрап) |
Заметьте симметрию: на каждую «рабочую» дисциплину (TDD, ревью, отладка) приходится скилл, который ее принудительно включает, а на систему в целом — метаскиллы для воспроизводства самой себя.
Философия проекта
README сводит философию Superpowers к четырем пунктам. Они короткие, но за каждым — годы опыта авторов с агентами, и каждый развернут в отдельный урок модуля:
- Test-Driven Development — «Write tests first, always» (урок 17.10). Не «когда удобно», а всегда: тест — единственный честный сигнал, что код делает то, что должен.
- Systematic over ad-hoc — процесс вместо угадывания (уроки 17.13, 17.14). Любой баг проходит систематическую процедуру поиска корневой причины, а не «попробуем еще раз».
- Complexity reduction — простота как главная цель. Дизайн, план и код проверяются на избыточность (YAGNI), файлы держатся маленькими, задачи — крошечными.
- Evidence over claims — доказательства вместо заявлений (урок 17.13). Ничто не объявляется сделанным, пока не запущена свежая верификация и не прочитан ее вывод.
Оригинальный анонс проекта: https://blog.fsck.com/2025/10/09/superpowers/.
Сообщество и коммерческая поддержка
- Discord — сообщество, вопросы и обмен опытом: https://discord.gg/35wsABTejz.
- Issues — баг-репорты и предложения: https://github.com/obra/superpowers/issues.
- Анонсы релизов — по подписке: https://primeradiant.com/superpowers/.
- Коммерческая поддержка — enterprise-контакт Prime Radiant: sales@primeradiant.com.
Отдельно зафиксируем телеметрию: логотип «визуального компаньона» brainstorming подгружается с сайта авторов и передает версию Superpowers (без данных о проекте, промпте или каркасе); отключается переменной окружения SUPERPOWERS_DISABLE_TELEMETRY. Подробности — в уроке 17.4.
Место на карте SDD-инструментов
Сопоставим три подхода, разобранных в курсе (детальное сравнение — урок 17.17):
| Подход | Механизм | Что дисциплинирует агента |
|---|---|---|
| Superpowers (этот модуль) | поведенческие скиллы + HARD-GATE | агент обязан пройти этапы: уточнить, спроектировать, согласовать, спланировать, TDD, ревью |
| OpenSpec (модуль 15) | файлы изменений: proposal → delta specs → archive | договоренность о том, что строится, фиксируется в файлах и архивируется |
| Spec Kit (урок 2.8) | constitution + слэш-команды /speckit.* |
фазы specify → clarify → plan → tasks → implement с конституцией проекта |
Общий знаменатель — все три не дают агенту начать с кода. Разница — в носителе процесса: у Superpowers это поведение агента, у OpenSpec — файлы в репозитории, у Spec Kit — CLI и командный ритуал.
Карта модуля 17
Модуль устроен в пять блоков, по жизненному циклу разработки:
| Блок | Уроки | Тема |
|---|---|---|
| A. Основы и запуск | 17.1–17.3 | философия, установка на разные каркасы, быстрый старт |
| B. Устройство | 17.4–17.5 | формат SKILL.md, хуки, бутстрап; справочник всех скиллов |
| C. Основной процесс | 17.6–17.12 | семь шагов базового workflow по порядку |
| D. Качество и диагноз | 17.13–17.14 | систематическая отладка, верификация, диагностика сессий |
| E. Расширение и место | 17.15–17.17 | собственные скиллы, артефакты полного цикла, сравнение и выбор |
Практика
Не устанавливая Superpowers, протестируйте главную идею на себе: возьмите задачу из своего бэклога и письменно ответьте на три вопроса, которые задал бы скилл brainstorming:
- Каков желаемый результат, для кого он и как выглядит успех?
- Это spike (проверить идею), bounded (небольшая правка существующего кода) или architectural (новая подсистема)? Почему?
- Что вы запретили агенту делать до вашего явного согласования?
Если на третий вопрос нет ответа — это и есть то окно, в которое обычно «врывается» код до дизайна.
Краткое резюме
Superpowers — методология разработки для coding-агентов: библиотека из 15 композируемых скиллов плюс инструкции, заставляющие агента их применять. Она не делает агента умнее — она делает его дисциплинированным: обязательные контрольные точки (HARD-GATE) между дизайном и реализацией, автоматические триггеры скиллов, TDD как норма, доказательства вместо заявлений.
- Superpowers = «методология + скиллы», а не CLI и не генератор спек; процесс живет в поведении агента.
- Базовый workflow — семь шагов: brainstorming → worktree → план → исполнение → TDD → ревью → завершение ветки.
- Философия из четырех пунктов: TDD всегда; систематичность вместо ad-hoc; упрощение; доказательства вместо заявлений.
- HARD-GATE: согласование каждого этапа — до реализации; одобрение идеи ≠ одобрение спецификации.
- Проект огромен (~295k звезд на 2026-10-03), развивается быстро — сверяйтесь с оригиналом.
Вопросы для самопроверки
- Почему Superpowers описывается как «методология + скиллы», а не как инструмент? Что из этого следует для установки на разные каркасы?
- Перечислите семь шагов базового workflow. Какие из них обязательны всегда, а какие выбираются?
- Что такое HARD-GATE и почему «одобрение идеи» не открывает ворота к написанию спецификации?
- Как связаны четыре пункта философии проекта и структура библиотеки скиллов? Приведите пару «принцип → скилл».
- Чем механизм дисциплины Superpowers отличается от OpenSpec и Spec Kit?
- Почему «агент работает автономно несколько часов» считается достоинством, а не риском? Что удерживает его в рамках плана?
Что дальше
В следующем уроке — 17.2 — разберем установку: почему она делается отдельно для каждого harness-каркаса, как поставить Superpowers в Claude Code, OpenCode и Codex, что делать с остальными четырнадцатью каркасами и как проверить, что скиллы действительно срабатывают.