44 атомарных скиллов методологии — что каждый делает, как их установить, какие плагины Claude Code их дополняют.

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

  • Стек из трёх независимых компонентов: 44 скиллов UCP + плагин-оркестратор superpowers + MCP-сервер документации context7. Только 1 из 44 скиллов опционально использует двух последних — остальные работают без них
  • Каталог из 44 скиллов парами «спроектируй ↔ проверь» по 17 стайл гайдам: спецификация, REST API, DDD, jOOQ, PG (schema / migration / runtime), auth, validation, caching, kafka, observability, resilience, cqrs, hexagonal, distributed, тесты
  • Установка за 5 шагов: Claude Code → клон usecase-pattern-skills + install.sh → superpowers → context7 → Java LSP через MCP для семантического поиска
  • Раздел про subagent-примитивы и почему «multi-agent с ролями» не подходит для боевой команды

Если нужен практический гид «как применять с первого UseCase» — читайте Use Case Pattern: пошаговый гид по применению.

Что в стеке

Четыре независимых компонента, которые композируются:

КомпонентЧто этоЗачем нужен
usecase-pattern-skills44 скиллов Use Case Pattern по 17 стайл гайдамАтомарные операции: «спроектируй UseCase», «проверь Handler», «сгенерируй спеку из бизнес-брифа»
superpowersПлагин рабочего процессаОркестратор больших задач: брейншторм → план → исполни → проверь → закрой
context7MCP-сервер документацииАктуальные версии и API библиотек (Spring Boot, jOOQ и т.д.) — не протухают
mcp-language-server + jdtlsJava LSP через MCPСемантический поиск (find_references, definition, rename, diagnostics) вместо grep — точность IDE на больших Java-сервисах

Каждый по отдельности полезен. Вместе — конвейер «бизнес-описание → готовый сервис в проде» с одним рабочим процессом в Claude Code.

Важно: только один из 45 скиллов (ucp-spec-design) опционально использует superpowers и context7. Остальные 44 работают без них. То есть установка плагинов — улучшение, не предусловие.

Каталог скиллов

Скиллы организованы парами «спроектируй ↔ проверь» по жизненному циклу разработки.

Спецификация

ucp-spec-design — написать Use Case спеку из бизнес-описания. Сам определяет нужный уровень зрелости (1 — слоёная, 2 — UCP с опциональным CQRS, 3 — DDD + Hexagonal) и заполняет разделы с правильной глубиной. На выходе — docs/spec/: корневой файл контекста (<service>-spec.md, секции уровня контекста) + по файлу на домен-юнит в aggregates/. Домен без техники, карточки команд и запросов, ссылки между разделами через markdown-якоря, минимальный frontmatter с level.

ucp-spec-tier-0 — реверс-инжиниринг as-is спеки из кода существующего сервиса (без бизнес-брифа) — это Уровень 0. Парная операция к ucp-spec-design для brownfield-сценария. На входе — репо (Java-исходники, Liquibase/Flyway-миграции, application.yml, OpenAPI, интеграционные тесты), на выходе — та же раскладка docs/spec/ (корень + aggregates/) с frontmatter level: 0. Поля, для которых данных в репо нет (не объявлены агрегаты, нет ABAC-условий, нет SLA), заполняются литералом not-declared — это явный gap-сигнал, по которому downstream-скиллы выдают findings и который служит точкой отсчёта для миграции на Уровень 1/2/3.

Проектирование

ucp-api-design — REST API из раздела «Commands» в спеке. Производит OpenAPI YAML с paths, schemas, error responses (RFC 9457), сигнатуры Spring-контроллеров, список DTO.

ucp-ddd-tactical-design — агрегат + Value Objects + события + repository из раздела «Domain Model». Применяется на Уровне 3.

ucp-pattern-design — UseCase + Handler + контроллер + маппер. Самый часто используемый скилл для маленьких задач.

ucp-auth-design — Spring Security + OAuth2 Resource Server + JWT + ABAC-хелперы + audit-аспект. Полная конфигурация безопасности под методологию.

ucp-bootstrap-design — Spring Boot bootstrap: 3 профиля (production / local / integration-test), Liquibase, jOOQ codegen, SecurityConfig per-profile, Kafka listener gating. Используется при старте нового сервиса или починке существующего.

ucp-test-design — интеграционные и unit-тесты по UC и BR из спеки. Использует BaseIntegrationTest с Testcontainers PostgreSQL + WireMock + in-memory event publisher.

Ревью

ucp-pattern-review — Java/Spring код против методологии UCP: UseCase — immutable record, Handler с @Transactional, контроллер ходит через UseCaseDispatcher, CQRS-маркеры на Уровне 2+, hexagonal-разделение на Уровне 3.

ucp-api-review — REST API контракт против style guide: формат URL (kebab-case), HTTP-методы и коды, именование полей в JSON (camelCase), формат ошибок RFC 9457, OpenAPI-метаданные.

ucp-ddd-tactical-review — доменный код против тактических паттернов DDD и корректное использование ddd-building-blocks: Entity, Value Object, Aggregate Root, Domain Event, Repository.

ucp-java-style-review — стиль Java-кода (то, что не ловит checkstyle): аббревиатуры, имена тестов, big lambdas, guard expressions, переносы строк.

ucp-auth-review — авторизация: JWT + RBAC + ABAC + S2S + audit + PII / секреты + идемпотентность. Каждое нарушение цитируется кодом правила (AUTH-9, AUTH-15 и т.д.).

Главная идея пар design ↔ review

Для каждого правила методологии есть:

  • design-скилл — создаёт код по правилу
  • review-скилл — проверяет существующий код на это правило

Это и есть превращение «PDF, который никто не читает» в исполняемый стандарт.

Установка

Шаг 0. Согласованные границы контекстов (для целого сервиса)

Для одной задачи (один UseCase) этот шаг можно пропустить. Для целого сервиса — пропустить нельзя. AI будет генерировать код в 5–10 раз быстрее, и если спека уже плохая — на проде это ускоряет движение в стену.

Что значит «согласованы»:

  • Границы контекстов (bounded contexts). С бизнесом и тимлидами проговорены границы сервиса: где заканчивается его зона ответственности, что синхронно, что асинхронно, чьи данные только читаем, а чьими владеем.
  • Владелец данных (data ownership). Каждая сущность имеет ровно одного владельца. Остальные читают через интеграционные паттерны, не лезут в чужую БД напрямую.
  • Зоны отказа (failure domains). Что с системой при отказе соседа: плавная деградация, очередь, запасной путь или отказ в обслуживании. Решение принимается до спеки, не после.

Без этого ucp-spec-design сгенерирует валидную спеку по формату, но она зафиксирует неверные границы — и сервис задрейфует к «общим таблицам», «двусторонней синхронизации», «нет владельца у сущности». Поправить через полгода — переписывание.

Инструмент — Event Storming в команде с бизнесом + DDD-спецификация. См. стратегические паттерны DDD. Эти артефакты — вход в Шаг 1, не его результат.

Если границы согласованы и записаны — переходим к установке.

Шаг 1. Claude Code

Если ещё нет — claude.com/code. Установите CLI и убедитесь, что в терминале работает:

claude --version

Дальше предполагаем, что Claude Code установлен.

Шаг 2. usecase-pattern-skills

Скиллы методологии живут в одном репо. Подключение — клон + install.sh.

git clone git@github.com:remodov/usecase-pattern-skills.git ~/projects/usecase-pattern-skills
cd ~/projects/usecase-pattern-skills

# подключить в конкретный Java-проект (рекомендуется):
./install.sh ~/my-java-project

# или глобально для всех проектов:
./install.sh ~/.claude

install.sh создаёт симлинки на .claude/skills/* и docs/*.md. Симлинки означают, что обновления в репо автоматически прилетят в проект — не нужно re-копировать руками.

После установки в проекте появятся:

  • .claude/skills/ucp-*/ — 44 скиллов
  • docs/*.md — снапшоты style-guide-ов, которые скиллы читают как input

Проверка: откройте Claude Code в проекте, наберите /ucp- — должен появиться автокомплит со списком скиллов.

Шаг 3. superpowers (опционально)

Плагин из Claude Code marketplace. Точная команда установки зависит от версии Claude Code; начните с:

claude plugins install superpowers

Если команды нет — посмотрите claude help или docs Claude Code.

После установки в чате появятся скиллы:

  • superpowers:brainstorming — для размытых требований
  • superpowers:writing-plans — план реализации из спецификации
  • superpowers:executing-plans — пошаговое исполнение по плану
  • superpowers:test-driven-development — TDD-дисциплина
  • superpowers:verification-before-completion — проверка перед коммитом
  • superpowers:requesting-code-review — внешний разбор через subagent

И ряд других скиллов-оркестраторов.

Что даёт: оркестратор для больших задач. Без него ucp-*-скиллы — независимые операции, надо помнить порядок шагов руками. С ним — связной конвейер, в котором план держится между шагами.

Шаг 4. context7 (опционально)

context7 — это MCP-сервер (Model Context Protocol). Подключается через:

claude mcp add context7

Или вручную в ~/.claude/settings.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp-server"]
    }
  }
}

После Claude может вызывать mcp__context7__* инструменты — например, найти библиотеку по имени и подтянуть свежую документацию.

Что даёт: актуальные версии и API. Особенно полезно для скилла ucp-spec-design — он не напишет в спеке «Spring Boot 2.7» когда уже актуальная 3.4. Без context7 версии в спеке нужно проверять руками.

Шаг 5. Java LSP через MCP (рекомендуется для Java-сервисов)

Что: Claude по умолчанию работает с Java через Read/Grep — это точно для маленьких задач, но на больших сервисах теряет семантику. «Найди всех caller-ов Repository.save()» через grep даёт шум от Map.save, List.save, перегрузок. С LSP (find_references, definition, diagnostics, rename_symbol) — точность IDE.

Когда стоит: сервис от ~30 файлов / ~5 модулей. На маленьких — overhead настройки больше выигрыша.

Установка (~10 минут одноразово, macOS):

brew install jdtls go
go install github.com/isaacphi/mcp-language-server@latest

Подключить к Claude Code как user-scoped MCP-сервер с привязкой к одному workspace (jdtls = ~1-2GB RAM на сервер, на каждый workspace — отдельный):

claude mcp add --scope user java-lsp-<service> \
  $HOME/go/bin/mcp-language-server \
  -- -workspace /Users/<you>/IdeaProjects/<service> \
     -lsp /opt/homebrew/bin/jdtls

Замените <service> на slug сервиса (например bus-tickets). Имя java-lsp-<service> определяет имена tools — mcp__java-lsp-<service>__*.

Проверка:

claude mcp list

Должна быть строка java-lsp-<service>: ... ✓ Connected.

Важно про первый запуск: после claude mcp add нужно перезапустить Claude Code — MCP-серверы загружаются на старте сессии. Первый вызов LSP-tool в новой сессии займёт 1-3 минуты — jdtls в фоне импортирует gradle/maven-проект, скачивает зависимости в ~/.cache/jdtls/, строит индекс. Дальше — мгновенно.

Удалить: claude mcp remove java-lsp-<service>.

Несколько workspace-ов: добавляйте отдельный сервер на каждый репо (java-lsp-bus-tickets, java-lsp-catalog и т.д.). Каждый ест 1-2GB RAM — не стоит подключать все 10 проектов сразу, только активные.

Linux/WSL: вместо brew install jdtls — скачать релиз с github.com/eclipse-jdtls/eclipse.jdt.ls/releases и распаковать. Дальше — то же самое.

Шаг 6. Проверка установки

Откройте Claude Code в вашем проекте, проверьте каждый компонент.

Скиллы UCP:

/ucp-pattern-review

Должен показаться скилл с описанием. Если нет — проверьте ls .claude/skills/, должны быть симлинки на 12 директорий.

Superpowers (если установили):

/superpowers:writing-plans

Должен показаться скилл с описанием.

Context7 (если установили):

mcp__plugin_context7_context7__resolve-library-id

Должен быть доступен как tool. Можно проверить простой запрос — найти библиотеку Spring Boot.

Java LSP (если установили):

mcp__java-lsp-<service>__find_references

Должен быть доступен как tool. Проверить — попросить Claude найти всех caller-ов конкретного метода в установленном workspace и сравнить с grep. LSP должен дать меньше шума и точнее.

claude mcp list снаружи Claude Code тоже валидно — для проверки ✓ Connected без запуска сессии.

Если что-то не работает — см. раздел «Если что-то не работает» ниже.

Скиллы vs «команда агентов с ролями»

Часто спрашивают: «а почему не сделать команду агентов с ролями — Java-разработчик, тестировщик, ревьюер — которые переговариваются автономно? AutoGen, Crew AI же это и предлагают».

Это другой подход к AI, не лучше и не хуже — но для боевой команды на UCP он плохо подходит:

  • Размывается единообразие стиля. У каждой роли немного свой стиль. На большой кодовой базе через год получится 20 разных интерпретаций «правильного UCP» — ровно та проблема, против которой методология и существует.
  • Журнал аудита рвётся. Кто принял решение по архитектуре — «разработчик»-агент, «архитектор»-агент или их диалог? Для команд из регулируемых отраслей (банки, госкомпании) это серьёзный блокер.
  • Стоимость в подписках растёт. Цикл из 10 вызовов агентов на задачу — реальные деньги в месячном счёте. На индивидуальной разработке терпимо, на команде из 20+ инженеров с десятками задач в день — нет.
  • Контроль уходит из цикла. Человек смотрит на итог, не на процесс. Это допустимо для эксперимента, не допустимо для боевого кода.

Где multi-agent силён: соло-разработка, прототипы, креативные задачи, где разнообразие полезно (несколько вариантов решения), исследование большого объёма задачи.

В нашем стеке примитивы multi-agent тоже есть — но не как «команда персон», а как специализированные субагенты для конкретных задач:

  • superpowers:code-reviewer — субагент-ревьюер с другой ментальной моделью, чем у автора кода
  • superpowers:dispatching-parallel-agents — параллельный запуск независимых задач (один-ко-многим, не диалог)
  • superpowers:subagent-driven-development — оркестратор с субагент-исполнителями для параллельных шагов плана

Идея: субагент под конкретную задачу — да, «команда персон» с автономным диалогом — нет. Меньше шума, больше контроля, дешевле в эксплуатации.

Если что-то не работает

Скиллы /ucp-* не видны в Claude Code:

ls -la .claude/skills/

Должны быть 12 симлинков на директории в ~/projects/usecase-pattern-skills/.claude/skills/. Если нет — повторите install.sh.

Superpowers не установлен:

claude plugins list

Если в списке нет superpowers — переустановите. Точная команда установки зависит от версии Claude Code, начните с claude help plugins.

Context7 MCP не отвечает:

claude mcp list

Если статус down или error — проверьте, что npx доступен в PATH и что есть интернет (npx скачивает пакет при первом запуске). Возможно, нужны права на запись в ~/.npm/.

Скилл ucp-spec-design ругается на отсутствие зависимости:

ucp-spec-design — единственный скилл, опционально использующий superpowers и context7. Если их нет, скилл работает, но:

  • без superpowers — нет TodoWrite-планирования внутри
  • без context7 — версии библиотек могут протухнуть, проверяйте руками

Это плавная деградация, не блокер.

Все остальные скиллы (ucp-*-review, ucp-*-design кроме spec) работают без внешних плагинов вообще, только на стандартных Claude Code tools. Если они «не работают» — проблема не в зависимостях, а в установке самих скиллов.

Что дальше

  • Применять методологию — как именно? Use Case Pattern: пошаговый гид по применению — два сценария от 3 минут до 2 дней.
  • Зачем всё это нужно: «AI пишет код. Зачем тогда методология?» и «Как ревьюить код, который написал AI».
  • Внедрение в команде — на странице услуг описан формат: 2–6 месяцев, методология + AI-скиллы + поддержка автора.