Настройка Claude Code под Use Case Pattern: плагины и скиллы пошагово

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

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

Стек из трёх независимых компонентов: 12 скиллов UCP + плагин-оркестратор superpowers + MCP-сервер документации context7. Только 1 из 12 скиллов опционально использует двух последних — остальные работают без них

Каталог 12 скиллов парами «спроектируй ↔ проверь»: спецификация, проектирование (api / ddd / pattern / auth / bootstrap / test), ревью (pattern / api / ddd / java-style / auth)

Установка за 5 шагов: Claude Code → клон usecase-pattern-skills + install.sh → superpowers → context7 → Obsidian для просмотра спеки графом

Раздел про subagent-примитивы и почему «multi-agent с ролями» не подходит для боевой команды

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

Что в стеке

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

Компонент	Что это	Зачем нужен
usecase-pattern-skills	12 скиллов Use Case Pattern	Атомарные операции: «спроектируй UseCase», «проверь Handler», «сгенерируй спеку из бизнес-брифа»
superpowers	Плагин рабочего процесса	Оркестратор больших задач: брейншторм → план → исполни → проверь → закрой
context7	MCP-сервер документации	Актуальные версии и API библиотек (Spring Boot, jOOQ и т.д.) — не протухают

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

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

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

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

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

ucp-spec-design — написать Use Case спеку из бизнес-описания. Сам определяет нужный Tier (A — классическая, B — UCP с CQRS, C — DDD/Hexagonal) и заполняет 16 разделов с правильной глубиной. На выходе — папка docs/spec/: каждая секция в подпапке, каталоги (errors, commands, events, aggregates, integrations) — per-item карточки (одна ошибка = один файл, одна команда = один файл) с типизированным frontmatter, ссылки между секциями через wikilinks. Папку можно открыть в Obsidian — увидеть Graph View связей между сущностями. Подробнее — Шаг 5 ниже.

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

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». Применяется на Tier C.

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-разделение на Уровне 4.

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-*/ — 12 скиллов
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. Obsidian (опционально, для просмотра спеки графом)

ucp-spec-design создаёт docs/spec/ как Obsidian-совместимый vault — каждая секция в папке, frontmatter с типизированными полями, ссылки через wikilinks. Если поставите Obsidian, эту папку можно открыть как vault и увидеть граф связей между командами, событиями и ошибками.

brew install --cask obsidian   # macOS
# или скачать: https://obsidian.md/download

При первом запуске ucp-spec-design кладёт в docs/spec/.obsidian/ минимальный бутстрап — только встроенные настройки Obsidian, без community-плагинов:

types.json — schema всех frontmatter-полей (severity, retryable, criticality, payload, и т.д.) → Properties-панель сразу с правильными виджетами вместо «всё текст».
core-plugins.json → включены Properties / Graph / Backlinks / Tag pane / Outline.
graph.json → цветовые группы Graph View по типам узлов через нативный обсидиановский ["type":"error"]-синтаксис: errors красные, commands зелёные, events фиолетовые, integrations оранжевые.

Использование:

После генерации спеки откройте docs/spec/ в Obsidian: «File → Open folder as vault».
Если Obsidian спросит про trust — согласитесь, иначе настройки .obsidian/ не активируются.
Graph View сразу покажет связи: команда → события, которые публикует → потребители; команда → ошибки, которые поднимает; агрегат → его события.
Properties-панель справа автоматически распознаёт типы полей карточек.

Что даёт:

Визуальная карта связей. На большом сервисе пары команда↔событие↔потребитель руками не отследишь, на графе — видно с одного взгляда.
Editing через Properties. Поменять status: deprecated или criticality: experimental — клик в правой панели, не правка YAML.
Backlinks. Открываете команду — видите все ошибки и события, которые на неё ссылаются.

Community-плагины не ставим по умолчанию. Раньше пробовали поставлять Dataview прямо в бутстрапе — отказались: пинит версию, раздувает репо, вшитый бинарник вызывал больше проблем, чем решал. Хотите Dataview-таблицы в landing-файлах для запросов вида «все retryable 5xx ошибки» — установите плагин руками через Obsidian → Settings → Community plugins → Browse → Dataview. Базовая спека читается и без него.

Без Obsidian: spec остаётся обычным markdown — читается в любом редакторе, frontmatter виден как текст. Это нормально, но теряется граф и удобный editing полей.

Шаг 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.

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

Скиллы 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-скиллы + поддержка автора.