Claude флоу
Как вести задачу в Claude Code так, чтобы результат не приходилось переделывать. Плагин superpowers добавляет «скиллы» — сценарии, которые заставляют модель сначала разобраться, потом спланировать, потом писать код и показать доказательства, что всё работает. Заметка отвечает на один вопрос: какой сценарий брать под конкретную задачу.
Что это и как поставить
Скилл — готовый сценарий работы, который подключается по имени. Пишешь в чат обычным текстом: Use superpowers:brainstorming. Скиллы срабатывают и сами, если задача очевидна; явный вызов нужен, когда хочешь заставить фазу или наоборот пропустить.
Установка (один раз):
/plugin install superpowers@claude-plugins-official
После установки перезапусти сессию.
Слэш-команд (
/brainstorm,/write-plan,/execute-plan) больше нет — их удалили ещё в 5.1. Только вызовы по имени:superpowers:brainstorming,superpowers:writing-plans,superpowers:executing-plans.
Шаг 0 — один раз на проект
Заведи в корне репозитория CLAUDE.md: команды тестов и линтера, структура каталогов, конвенции. Без него любой режим работает хуже — модель и субагенты переоткрывают проект заново на каждой задаче. Это самая дешёвая правка с самым большим эффектом.
Как выбрать режим
Не считай строки — спроси себя: сколько неизвестных?
| Что ты знаешь | Режим |
|---|---|
| Знаю ровно, что менять | Режим 1 |
| Знаю, что менять, не знаю почему сломано | Режим 2 |
| Знаю, чего хочу, не знаю, как разложить | Режим 3, но с шага 3 — брейнсторм пропускаешь |
| Не знаю толком, чего хочу | Режим 3 целиком |
Объёмы в заголовках ниже — грубый ориентир, а не критерий. Критерий — неизвестные.
Режим 1 — знаю ровно, что менять
(ориентир: 1 файл, до 50 строк)
Голая модель. Просто описываешь конкретную правку.
Один обязательный гейт в конце — всегда, а не только на проде:
Use superpowers:verification-before-completion
Заставляет показать доказательство (прогон тестов/команды), а не «готово, должно работать». Именно одиночная правка чаще всего уезжает непроверенной — это самый дешёвый гейт во всём флоу, одна строка в чат.
Режим 2 — знаю, что менять, но не знаю почему сломано
(ориентир: 1–3 файла, до 300 строк, одна сессия)
Точечно, без брейнсторма и плана.
| Ситуация | Что писать |
|---|---|
| Баг, непонятная причина | Use superpowers:systematic-debugging |
| Новая логика/фича в существующем коде | Use superpowers:test-driven-development |
| Рефакторинг без изменения поведения | Сначала Use superpowers:test-driven-development — зафиксировать текущее поведение тестами, потом рефакторить |
| Разбираю чужой код или чужое ревью | Use superpowers:receiving-code-review |
| Перед коммитом | Use superpowers:verification-before-completion |
systematic-debugging — 4 фазы, запрещает чинить до нахождения корневой причины. test-driven-development — жёсткий RED-GREEN-REFACTOR: код, написанный до теста, удаляется. receiving-code-review — не даёт соглашаться с замечаниями механически, требует проверить каждое.
Не запускай тут brainstorming — он потребует спеку на задачу, которая её не стоит.
Режим 3 — не знаю, как разложить (или чего хочу)
(ориентир: 3–15 файлов, 300–2000 строк, 2+ часа)
Полный цикл: спека → план → исполнение → ревью → закрытие. Порядок жёсткий, между фазами ты читаешь и апрувишь.
Два способа вести цикл
Скиллы связаны: каждый в конце сам передаёт следующему. Обычно хватает одной команды на входе.
Use superpowers:brainstorming
Дальше едет само: спека → план (переход автоматический) → вопрос «каким способом исполнять», отвечаешь 1 → исполнение субагентами, которое само проверит worktree, само позовёт финального ревьюера и само перейдёт к закрытию ветки.
Участвуешь ты на тех же границах, но отвечаешь, а не командуешь: утверждаешь куски спеки, принимаешь или правишь план, решаешь по замечаниям ревью, выбираешь мердж/PR. Гейты те же — набор команд другой. Если начал с brainstorming и потом руками пишешь Use superpowers:writing-plans, ты дублируешь уже случившееся.
Руками (по шагам ниже) — когда надо вклиниться: зайти не с начала (спека уже есть → сразу writing-plans); остановиться после плана и не исполнять сегодня; поднять worktree заранее, чтобы увидеть baseline до вложений в план; перезапустить одну фазу.
Шаги по отдельности
1. Спека
Use superpowers:brainstorming
Сократический диалог, выдаёт дизайн кусками на утверждение. Результат ложится в docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md.
2. Изолированная ветка — необязательный шаг
Use superpowers:using-git-worktrees
Спросит разрешения, создаст worktree в .worktrees/, прогонит чистый baseline тестов.
Необязательный он потому, что исполнение (шаг 4) само проверит worktree и создаст его, если нет. Смысл делать заранее один: увидеть baseline тестов до того, как вложился в план. Если baseline красный, узнать об этом лучше сейчас, а не после часа планирования.
3. План
Use superpowers:writing-plans
Разбивка на задачи по 2–5 минут с точными путями файлов. Ложится в docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md.
Прочитай план целиком перед «go» — это единственная точка, где дешевле всего чинить ошибки. Чеклист приёмки:
- Каждая задача проверяема — понятно, что считать «сделано», и это можно прогнать командой
- Пути файлов настоящие — открой пару штук и убедись, что они существуют
- Есть отдельные задачи на тесты, а не одна общая «покрыть тестами» в конце
- Нет задач вида «отрефакторить всё» / «привести в порядок» — это не задача, а намерение
- Порядок такой, что после каждой задачи репозиторий в рабочем состоянии
4. Исполнение
Use superpowers:subagent-driven-development
Свежий субагент на каждую задачу + ревьюер, который читает дифф и выдаёт два вердикта (соответствие спеке + качество). На Claude Code и Codex это основной путь; superpowers:executing-plans остался только для харнесов без субагентов. TDD внутри включается сам.
5. Ревью всей ветки
Use superpowers:requesting-code-review
Ревьюер читает дифф ветки целиком, а не по одной задаче. Здесь ловится то, что не видно изнутри отдельной задачи: разъехавшиеся между задачами имена, дублирующаяся логика, забытый край спеки.
Прочитай замечания и реши по каждому: чиню, не чиню, спорю. Не соглашайся механически — на несогласие есть Use superpowers:receiving-code-review, он заставляет проверить замечание, а не принять его из вежливости. После фиксов прогони verification-before-completion ещё раз: правки по ревью — такой же непроверенный код, как любой другой.
6. Закрытие ветки
Use superpowers:finishing-a-development-branch
Предложит мердж / PR / оставить как есть и почистит worktree. Создание PR идёт через CLI твоего форджа или по ссылке, которую печатает git push.
Закоммить спеку и план из docs/superpowers/ вместе с кодом — это единственная запись о том, почему сделано именно так; рабочие файлы из .superpowers/sdd/ не коммитятся и удаляются сами.
«Выбросить работу» из меню убрали в 6.2.0 — только по явному запросу и с подтверждением вводом.
Если пошло не так
- План не нравится — правь промптом в том же диалоге («задача 4 слишком крупная, разбей»), а не руками в файле. Руками — только мелкие формулировки, иначе исполнитель будет работать по одной версии, а ты держать в голове другую.
- Ревьюер зарубил задачу — цикл «ревью → фикс» ограничен пятью кругами, после чего решение эскалируется тебе. Если дошло до пятого — проблема почти всегда в постановке задачи в плане, а не в коде: возвращайся на шаг 3.
- Рабочие файлы исполнения лежат в
.superpowers/sdd/<имя-плана>/и удаляются сами после чистого финального ревью.
git clean -fdxсносит журнал прогресса из.superpowers/sdd/— незакоммиченный прогресс придётся восстанавливать изgit log.
- Конфликт в worktree — не чини вручную из основного дерева; заходи в сам worktree, там же и разрешай, потом возвращайся к
finishing-a-development-branch.
Про цену
Режим 3 расходует кратно больше токенов, чем голая модель: субагенты не переиспользуют контекст, а ревьюер перечитывает дифф. Это часть критерия выбора — гонять полный цикл на задаче Режима 1 бессмысленно и дорого.
Как это выглядит целиком
Задача-пример: в парсере теги банятся по одному через Add tag. По абузам прилетают списки на 50–200 тегов, иногда на все сиджи, иногда на один. Нужна массовая загрузка и журнал — кто и когда забанил.
Неизвестных много (как хранить область применения, что делать с уже забаненными, нужен ли откат) → Режим 3 целиком.
Ниже шесть фаз с командой каждой — чтобы было видно, что за что отвечает. В реальном прогоне ты печатаешь только первую, остальные скиллы вызовут друг друга сами; твои реплики на границах — ответы и правки, а не команды. Команды пригодятся, если заходишь в цикл не с начала.
1 — Спека
Use superpowers:brainstorming
В thumbs-parser на вкладке Tags теги банятся по одному через Add tag.
По абузам прилетают списки на 50–200 тегов, иногда на конкретный сидж,
иногда на все. Хочу массовую загрузку и чтобы было видно, кто и когда забанил.
Что происходит. Кода не пишется. Идут вопросы по одному: «что делать с тегом, который уже забанен на другом сидже — перезаписать область или добавить?», «нужен ли откат пачкой?», «список приходит как текст или файлом?», «журнал нужен для отчёта или для отката?». Отвечаешь. Дальше дизайн выдаётся кусками на утверждение и ложится в docs/superpowers/specs/2026-08-12-massovyi-ban-tegov-design.md.
Твоя работа. Не соглашаться быстро. Каждый непроговорённый вопрос вернётся на шаге 4 переделкой, а там он стоит на порядок дороже.
2 — Ветка
Use superpowers:using-git-worktrees
Что происходит. Спросит разрешения, создаст worktree в .worktrees/, прогонит baseline тестов. В автоцепочке этой фазы отдельно не будет — worktree поднимется на шаге 4; команду выше даёшь, только если хочешь baseline заранее.
Твоя работа. Посмотреть на baseline. Если он красный до твоих правок — останавливайся здесь и чини отдельно. Иначе на шаге 4 ты не отличишь свою поломку от чужой, и весь цикл превращается в угадайку.
3 — План
Use superpowers:writing-plans
Что происходит. Задачи по 2–5 минут с путями файлов, в docs/superpowers/plans/2026-08-12-massovyi-ban-tegov.md.
Твоя работа. Прогнать по чеклисту приёмки выше. Как выглядит настоящая правка на этом шаге:
Задача 3 не проверяема — не сказано, что делать с тегом, уже забаненным на этом сидже. Допиши ожидаемое поведение и тест на этот случай. Задачу 6 «привести форму в порядок» убери или разбей на конкретные пункты.
Правишь промптом в диалоге, не руками в файле — иначе исполнитель пойдёт по одной версии плана, а ты будешь держать в голове другую.
4 — Исполнение
Use superpowers:subagent-driven-development
Что происходит. По задаче за раз: свежий субагент получает бриф, пишет код через TDD, ревьюер читает дифф и выдаёт два вердикта. При отказе фиксы делает тот же исполнитель, а не новый.
Твоя работа. Не вмешиваться по мелочи — на то и цикл. Но следить за счётчиком кругов: если одна задача ушла на пятый круг, сработает ограничитель и решение вернётся тебе. Почти всегда это значит, что задача плохо поставлена в плане — возвращайся на шаг 3, а не чини руками.
5 — Ревью
Use superpowers:requesting-code-review
Что происходит. Дифф ветки целиком. На этой задаче тут всплывает типовое: логика «забанен на всех сиджах» продублирована в массовом импорте и в старом одиночном Add tag.
Твоя работа. Решить по каждому замечанию. На спорные — receiving-code-review. После фиксов прогнать верификацию заново.
6 — Закрытие
Use superpowers:finishing-a-development-branch
Что происходит. Мердж или PR, чистка worktree.
Твоя работа. Закоммитить спеку и план вместе с кодом. Дальше — карточка по обычному процессу, QA-чеклист проверки вёрстки если трогали интерфейс.
Шаги 1 и 3 — единственные, где работаешь ты. На шаге 4 ты в основном читаешь и апрувишь. Если чувствуешь, что на шаге 4 приходится много вмешиваться — значит, сэкономил на 1 и 3.
Источник: плагин
superpowers(маркетплейсclaude-plugins-official), версия 6.2.0 —SKILL.mdскиллов иRELEASE-NOTES.mdв~/.claude/plugins/cache/.