Практический гид: что и в каком порядке делать, если хочется получить результат. Два сценария — маленькая задача (один UseCase за 3 минуты) и целый сервис от спеки до прода (день-два). Решение какой выбрать — в блоке ниже.

Перед началом убедитесь, что инструменты установлены: скиллы UCP — каталог и установка. Дальше — конкретные команды, чего ждать, как читать результат.

Что внутри (на 30 секунд):

  • Сценарий 1: один UseCase за 3 минуты — нужен только ucp-pattern-design. Работает на одну операцию в существующем сервисе
  • Сценарий 2: целый сервис за день-два — ucp-spec-design → план через superpowers:writing-plans → исполнение → 5 ревью-скиллов
  • Дерево «какой сценарий выбрать» — от одной операции до миграции с классической архитектуры на UCP
  • 5 хороших практик и 5 анти-паттернов

Сценарий 1: один UseCase за 3 минуты

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

Здесь нужен только usecase-pattern-skills. superpowers и context7 не нужны, избыточно.

Что делаете

Открываете Claude Code в проекте и вызываете один скилл:

/ucp-pattern-design Команда «отменить заказ» с проверкой статуса DRAFT|PAID и ABAC по customerId

Что получаете

Скилл за 30 секунд возвращает:

  • CancelOrderUseCase — record, реализующий UseCaseCommand<Void> или UseCaseCommand<Order>
  • CancelOrderHandler — @Component с @Transactional, бизнес-логика проверки статуса и ABAC внутри
  • Контроллер с @PreAuthorize("hasRole('customer')"), реализующий OpenAPI-генерируемый интерфейс
  • Юнит-тесты на основные сценарии (allowed transitions, ABAC denied, status mismatch)

Всё с правильными импортами, аннотациями, обработкой исключений по методологии.

Что делать дальше

  1. Прочитать ответ внимательно (не пропустить важные детали)
  2. Применить через Claude Code Edit-tools (или скопировать руками)
  3. Запустить /ucp-pattern-review на свежий diff — получить замечания если что-то не по правилам
  4. Запустить тесты локально, поправить если что-то падает
  5. PR

Реальное время от запроса до закоммиченного кода — 5–10 минут. Из них 3 на работу скилла, остальное на чтение и применение.

Все скиллы для маленьких задач

Под разные типы операций — разные ucp-*-design:

Что нужноКакой скилл
UseCase + Handler + контроллерucp-pattern-design
REST API контракт (OpenAPI)ucp-api-design
Доменный агрегат + события (Уровень 3)ucp-ddd-tactical-design
Spring Security + JWT + ABACucp-auth-design
Тесты на UseCase / business ruleucp-test-design

И симметричные *-review для проверки существующего кода.

Сценарий 2: целый сервис от спеки до прода

Здесь от вас бизнес-описание (даже на одну страницу), а на выходе — рабочий сервис. Нужны все три компонента стека: usecase-pattern-skills, superpowers, желательно context7.

Полный процесс за 4 шага.

Шаг 1. Спека из бизнес-описания

/ucp-spec-design Сервис каталога маркетплейса. Продавец публикует и скрывает товары, Order Service берёт цену по productId. Уровень 2

Скилл читает описание, определяет нужный уровень зрелости (1 — слоёный, 2 — Use Case Pattern ±CQRS, 3 — DDD + Hexagonal) и создаёт спеку в docs/spec/: корень контекста + по файлу на домен-юнит в aggregates/.

Brownfield-вход: если сервис уже существует, а бизнес-брифа нет — стартуйте не с ucp-spec-design, а с ucp-spec-tier-0. Он реверс-инжинирит as-is спеку из кода (Java-исходники, миграции, application.yml, OpenAPI) в том же формате — это Уровень 0 (level: 0). Отсутствующие данные помечаются литералом not-declared — точка отсчёта для миграции на нужный уровень через тот же ucp-spec-design уже с бизнес-вводом.

docs/spec/
  catalog-spec.md        — корень: Bounded Context, язык, роли, интеграции,
                           события-контракт, use cases, НФТ, техническая реализация
  aggregates/
    product.md           — домен-юнит: модель, жизненный цикл, доступ,
                           бизнес-правила, команды, запросы

На Уровне 2 §Доменные события и §Процессы помечаются «не применимо» (появляются на Уровне 3).

С context7 версии библиотек в спеке актуальные. С superpowers — внутреннее планирование, проще не пропустить раздел.

Шаг 2. План реализации

/superpowers:writing-plans

Читает спеку, производит план шагов:

1. scaffold gradle multi-module
2. Liquibase migration v-1.0/initial-schema.yaml
3. jOOQ codegen из applied-схемы
4. ProductRepository — jOOQ generated POJO + DSL
5. CreateProductUseCase + Handler + контроллер
6. PublishProductUseCase + Handler
7. HideProductUseCase + Handler
8. GET /products/{id} query
9. SecurityConfig (3 профиля: prod, local, integration-test)
10. Integration tests на каждый UC + AC из спеки
11. ArchUnit тесты на инварианты слоёв

Каждый шаг с критериями приёмки. План остаётся в контексте сессии — executing-plans будет идти по нему.

Шаг 3. Исполнение

/superpowers:executing-plans

Идёт по плану шаг за шагом. На каждом вызывает соответствующий ucp-*-design:

ШагСкилл
Bootstrap (gradle, профили, Liquibase, jOOQ)ucp-bootstrap-design
Доменные классы (Уровень 3)ucp-ddd-tactical-design
UseCase + Handler + контроллерucp-pattern-design
Spring Securityucp-auth-design
API + ProblemDetailsucp-api-design
Тестыucp-test-design

После каждого шага — superpowers:verification-before-completion: gradle compileJava, gradle test. Не зелёное — не двигаемся дальше.

Шаг 4. Финальный разбор

/ucp-pattern-review
/ucp-api-review
/ucp-ddd-tactical-review
/ucp-java-style-review
/ucp-auth-review

Каждый скилл методологии прогоняется по diff. Замечания цитируют код правила (R-7, JS-2.5, BR-C5).

И финальный внешний взгляд:

/superpowers:requesting-code-review

Subagent-ревьюер читает PR с позиции «не знаком с кодом, но знаком с UCP» и оставляет комментарии о неочевидных моментах, что разработчик упустил из-за привычности.

Реальное время

От бизнес-описания до работающего сервиса — день-два, если стек установлен. Без AI и методологии — 1–2 недели на ту же постановку.

Когда какой сценарий выбирать

Сколько у вас задача?
│
├─ Одна операция в существующем сервисе
│  → Сценарий 1 (один UseCase, 3 минуты)
│  → ucp-pattern-design / ucp-api-design напрямую
│
├─ Новый модуль (3-5 операций)
│  → Сценарий 1 повторяется N раз
│  → По одному UseCase за итерацию
│  → Не нужен superpowers, ритм быстрый
│
├─ Новый сервис с нуля
│  → Сценарий 2 целиком
│  → Все три компонента стека
│
├─ Переписывание существующего сервиса с классической слоёной на UCP
│  → Сначала аудит (ucp-pattern-review на текущий код)
│  → Потом план миграции через superpowers:writing-plans
│  → Дальше Сценарий 2 по модулям
│
└─ Сложный архитектурный выбор (saga vs 2PC, ивенты ли вообще)
   → superpowers:brainstorming
   → дальше Сценарий 2 с уже определённым подходом

Хорошие практики

Стартовать с уровня ниже, чем кажется нужным. Если сомневаетесь, 2 или 3 — берите 2. Уровень повышается легко, понижается тяжело. Не стройте DDD + Hexagonal где хватит Use Case Pattern.

Пропускать verification-before-completion нельзя. Соблазн «потом проверим» большой, особенно когда AI сделал что-то выглядящее правильным. Не зелёный билд после шага = плохой шаг, возвращайтесь.

Один UC = один PR. Не сваливать 5 UseCase-ов в один коммит, даже если AI пишет быстро. Размер PR определяет качество ревью.

Спека и код должны совпадать. Изменили UseCase в коде — обновите раздел 7 спеки в том же PR. Расхождение = баг, не «доработаем потом». На этом ломаются 80% методологий.

AI-скиллы для ревью идут перед человеком, не вместо. /ucp-*-review ловит банальные нарушения правил, человек смотрит на архитектуру и компромиссы. Если человек ушёл из цикла полностью — это уже multi-agent (см. ниже про антипаттерны).

Антипаттерны

«Создадим только спеку, код потом» — спека без кода устаревает за 2 недели. Делайте параллельно или удаляйте спеку.

«AI заодно отрефакторил три соседних модуля» — узкие промпты дают узкий diff. «Заодно» = разраставшийся PR, который никто не успевает проверить.

«У нас Уровень 3 везде потому что DDD» — Уровень 3 дороже и сложнее в поддержке. Применяйте только там, где есть инварианты в домене (Order, Payment, Reservation). Справочники и админки — Уровень 1 или 2.

«AI написал тесты, я не читал» — тесты-«обёртки» (assertNotNull, verify(any())) пропускают баги. Прочитайте 5 тестов, поймёте качество остальных.

«Скиллы + команда агентов с ролями = ещё круче» — нет. Подробно «Скиллы vs команда агентов с ролями» в статье про установку. Multi-agent с автономным диалогом ломает согласованность стиля и журнал аудита.

Что дальше

  • Скиллы UCP — каталог и установка — если ещё не настроили инструменты
  • Use Case спецификация: универсальный шаблон — корень контекста + домен-юниты, уровень во frontmatter
  • Уровни зрелости: 1 — Слоёный → 2 — Use Case Pattern → 3 — DDD + Hexagonal
  • Кейс: Order Service (Уровень 3) — полный пример сервиса с применением UCP
  • Внедрение в команде — на странице услуг описан формат: 2–6 месяцев, методология + AI-скиллы + поддержка автора