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/.