Superpowers может провести пользователя Claude Code через существенное изменение в управляемом им Git-репозитории: согласовать проектирование, утвердить план задач, реализовать с тестами, проверить каждую задачу и готовую ветку. Это руководство следует официальным материалам Superpowers 7.0.0, проверенным 20 октября 2026 года. BIG CHANGE изучила документацию; мы не устанавливали плагин и не проводили проект через этот процесс.

Главное изменение

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

Перед началом

Выберите одно разрешённое многошаговое изменение кода в собственном или доступном для редактирования репозитории. Оно должно делиться на проверяемые задачи и иметь тестируемое поведение. Запишите требуемое поведение, затрагиваемую область, исключения, исходную команду приёмки и начальный commit. До работы запустите эту команду и соответствующие существующие проверки. Если исходное состояние уже не проходит, установите причину сейчас: последующим красным и зелёным результатам нужна известная точка отсчёта.

Нужны Git, аутентифицированная установка Claude Code, разрешение устанавливать плагины и создавать ветку или worktree, а также достаточная ёмкость тарифа или API для Claude Code и субагентов. Проверьте правила организации по доступу к исходному коду и плагинам. Перед включением изучите содержимое плагина, действующие разрешения, условия поставщика по данным и контроль расходов. Anthropic предупреждает, что plugin hooks и серверные процессы могут выполняться с правами пользователя вне изоляции вызовов инструментов; обычные запросы разрешений инструментов покрывают не весь такой код. Ограничьте секреты, зависимости, внешние записи, push и выпуски своими реальными полномочиями. Документация безопасности плагинов Claude Code объясняет эту границу.

Далее используется навык Superpowers subagent-driven-development для изменения с несколькими задачами. Руководства также описывают прямой путь executing-plans и допускают упрощённое согласование проектирования для небольших работ. Выберите путь с ответственным до реализации, а не считайте полную последовательность обязательной для каждого проекта.

1. Установите плагин и проверьте активную версию

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

Text
/plugin install superpowers@claude-plugins-official

Claude Code открывает панель подробностей плагина перед установкой. Изучите содержимое и выберите разрешённую область действия. Локальная область включает его для вас в этом репозитории; проектная влияет на настройки репозитория участников. Прочитайте сводку установки и вкладку Errors. Выполните указания сессии по активации или перезапустите её, затем проверьте Installed и в shell запустите claude plugin list. Запишите отображаемые Version, Scope и Status и подтвердите доступность навыков Superpowers в активной сессии. Команда каталога не фиксирует исследовательский commit этого руководства. Если установленная версия или текст навыка отличается от 7.0.0, сначала согласуйте процедуру с установленной версией. Неудачная или отключённая установка требует остановки, а не доказывает загрузку процесса. Руководство по установке Claude Code описывает эти проверки.

2. Утвердите проектирование, затем план

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

Затем попросите процесс writing-plans преобразовать проект в задачи. Проверьте границы файлов, интерфейсы, общие ограничения, тестовые команды и Review Focus плана. Каждая задача должна быть достаточно небольшой для проверки, а тест — измерять согласованное поведение. Утвердите план и способ работы субагентов до изменений кода. Руководство по планированию определяет передачу. Правдоподобный план не разрешает добавлять зависимости или менять посторонние файлы.

При выполнении using-git-worktrees проверяет подходящее существующее рабочее пространство или готовит изолированное с необходимым согласием. Запишите фактическую ветку, базовый commit и чистое исходное состояние. Используйте встроенную поддержку worktree в Claude Code, когда она доступна. При наличии посторонних правок сначала выясните ответственность за них. Руководство по worktree описывает проверки и создание.

3. Наблюдайте каждый тест и проверку задачи

С утверждённым планом используйте subagent-driven-development для независимо проверяемых задач. Текущее руководство назначает задаче исполнителя, затем передаёт реализацию и diff одному проверяющему задачи. Он выдаёт два заключения: соответствует ли задача спецификации и приемлемо ли качество реализации. Это два вывода одной проверки, а не два последовательных агента-проверяющих. Маленькие однотипные задачи можно объединять по правилам руководства. Процесс задач и промпт проверяющего устанавливают эту последовательность.

Для каждого поведения, подходящего к тестированию прежде реализации, требуйте наблюдаемый красно-зелёный цикл: добавьте тест поведения, запустите и увидьте ожидаемое падение; выполните минимальную реализацию, повторите и увидьте прохождение; затем рефакторите при зелёных проверках. Ошибка импорта или сломанная тестовая инфраструктура — не ожидаемый красный результат. Храните команду, вывод и соответствующий commit или diff каждой задачи. Руководство по разработке через тестирование описывает исключения, требующие согласия человека; здесь предполагается задача для обычного пути с тестом вначале.

Прочитайте оба заключения и настоящий diff. Перед принятием задачи решите каждый пункт «нельзя проверить по diff» по плану и репозиторию. Изучите исправления и их ограниченную повторную проверку; новое заявление об успехе не является свежим результатом теста. Процесс 7.0.0 ограничивает цикл исправлений и может откладывать замечания с письменными решениями. Сохраните их для дальнейшей проверки. Отметка о завершении задачи не обязательно означает проверку без замечаний.

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

4. Проверьте ветку и решите, что с ней делать

Ещё раз запустите исходную команду приёмки на конечном коде вместе со всей тестовой системой проекта. Изучите свежие выводы, полный diff ветки и все оставшиеся замечания. Руководство Superpowers по проверке требует доказательств текущего состояния до заявления о завершении. При падении тестов установите точную ошибку и исправьте её либо оставьте ветку на проверку; документированное меню завершения недоступно при падающей тестовой системе.

В именованной ветке finishing-a-development-branch предлагает локальное слияние, push с созданием pull request или сохранение ветки как есть. При отсоединённом HEAD доступны pull request и сохранение. Отбрасывание выполняется лишь после явного запроса ответственного и набранного подтверждения; это не обычный четвёртый вариант. Руководство по завершению ветки перечисляет эти варианты. До решения покажите ответственному проверки, diff и остаточные замечания. Слияние, push, удаление или выпуск требуют соответствующих полномочий.

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

Источники и дополнительное чтение

Для узкого исправления одной приёмочной проверки см. руководство BIG CHANGE по проверке одного падающего контроля репозитория. Здесь процесс начинается раньше, с проектирования и плана многозадачного изменения.