agents

KO | EN

gitlite — search

#markdown #chatbot #devops #awesome-list #electron #swift #kotlin #reactjs #tailwindcss #linux

(★ 9)

Universal Claude Code subagents: plan architect/reviewer, backend, frontend, designer, QA, DevOps — stack-agnostic, work in any project

File Explorer

ZIP Download

- python-async-specialist.md
- python-data-analyst.md
- python-performance-optimizer.md
- python-pytest-specialist.md
- python-type-checker.md
- README.md
- components-library-rule.md
- README.md
- registries.json
- shadcn-component-researcher.md
- shadcn-implementation-builder.md
- shadcn-quick-helper.md
- shadcn-requirements-analyzer.md
.gitignore
accessibility-expert.md
ai-engineer.md
api-specialist.md
backend-developer.md
code-reviewer.md
conversion-analyst.md
database-engineer.md
designer.md
devops.md
error-detective.md
feature-documentation-writer.md
frontend-developer.md
implementation-plan-architect.md
implementation-plan-reviewer.md
landing-ab-tester.md
landing-optimizer.md
marketing-analyst.md
marketing-specialist.md
mobile-developer.md
mobile-growth.md
monitoring-engineer.md
performance-engineer.md
product-analyst.md
qa-engineer.md
README.md
researcher.md
security-auditor.md
security-reviewer.md

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

Универсальные субагенты для [Claude Code](https://claude.com/claude-code) — работают в любом проекте независимо от стека. Каждый агент при запуске сам определяет контекст проекта (CLAUDE.md, файлы зависимостей, конвенции) и адаптируется под него.

Агенты и манифесты объединены в один файл на агента (frontmatter + инструкции), формат — стандартный для `.claude/agents/`.

## Агенты

| Agent | Model | MCP (опционально) | Роль |
|-------|-------|-------------------|------|
| `implementation-plan-architect` | opus | — | Создание детальных планов реализации: декомпозиция на задачи 1–4 часа, acceptance criteria, зависимости и параллельность, ADR-мышление, API-контракты |
| `implementation-plan-reviewer` | opus | — | Review планов: полнота, гранулярность, техническая корректность + security review плана (threat modeling lite) и architecture review. Итерирует с архитектором до approval |
| `code-reviewer` | sonnet | — | Review кода после разработчика: SOLID/DRY/KISS, соответствие плану, error handling. Итерирует с разработчиком, код не правит |
| `security-reviewer` | opus | — | Security-аудит кода после code review: OWASP Top 10, auth/authz, скан зависимостей и секретов. Работает точечно (фича) и аудитом всего репо |
| `security-auditor` | opus | — | Комплексный security-аудит существующего проекта: код (OWASP), зависимости и секреты (включая историю git), инфраструктура (контейнеры, IaC, CI/CD, cloud), compliance, remediation-roadmap. По вызову |
| `backend-developer` | sonnet | postgres, context7 | Backend-задачи: API, модели данных, миграции, бизнес-логика |
| `database-engineer` | sonnet | postgres, context7 | Схемы БД, индексы, оптимизация запросов, безопасные миграции с rollback, data integrity |
| `ai-engineer` | sonnet | context7 | AI/ML-задачи: LLM-фичи (промпты, RAG, structured outputs, fine-tuning), classical ML, evals, сервинг и мониторинг моделей |
| `frontend-developer` | sonnet | context7, playwright | Frontend-задачи: UI-фичи, компоненты, маршруты, интеграция с API + весь визуальный слой (токены → layout → компоненты → анимации) по дизайн-системе |
| `mobile-developer` | sonnet | context7 | Мобильные приложения (native iOS/Android, React Native, Flutter, KMP): платформенный UI, offline-first и sync, интеграция push и deep links, релизные сборки |
| `designer` | opus | playwright | Проектирование интерфейсов ДО кода: брейншторм экранов, user flows, ASCII-вайрфреймы, все состояния, UX-план и хендофф. Интерактивная роль (диалог), код не пишет |
| `qa-engineer` | sonnet | playwright, postgres | Тестирование в двух режимах — ручное или автотесты (режим задаётся в постановке): тест-планы, bug reports, quality gate sign-off |
| `devops` | sonnet | — | Git-операции, CI/CD, деплой, инфраструктура, мониторинг |
| `researcher` | sonnet | context7 | Технические исследования: сравнение технологий, best practices, валидация гипотез. Research report с comparison-матрицей и рекомендацией |
| `accessibility-expert` | sonnet | playwright | WCAG-аудит (axe-core, Lighthouse, Pa11y), ревью дизайна на a11y, самостоятельный фикс a11y-проблем в коде. По вызову |
| `performance-engineer` | sonnet | playwright, postgres | Оптимизация производительности web, backend и mobile: baseline-замеры, поиск bottleneck-ов (N+1, bundle size, cold start / fps / память / батарея), оптимизация, валидация против baseline. По вызову |
| `error-detective` | sonnet | — | Расследование инцидентов: анализ логов, корреляция ошибок, root cause. Использует скилл systematic-debugging, если доступен. По вызову |
| `mobile-growth` | sonnet | — | ASO (ключевые слова, листинг, отзывы, локализация) и push/engagement-стратегия (сегментация, тайминг, opt-in). Стратегия и материалы, код не пишет. По вызову |
| `landing-optimizer` | sonnet | playwright | Конверсионные лендинги: структура под одну цель, копирайт (AIDA/PAS, CTA, формы), social proof, гипотезы для A/B. Blueprint и тексты, реализует @frontend-developer. Landing-проекты |
| `landing-ab-tester` | sonnet | — | A/B-эксперименты: приоритизация гипотез (ICE/PIE), sample size, статистическая значимость без подглядывания, анализ по сегментам, лог тестов. Landing-проекты |
| `conversion-analyst` | sonnet | playwright | CRO-диагностика: карта воронки и drop-off, анализ поведения (heatmaps, recordings, form analytics), фрикшены, CRO-аудит с бэклогом гипотез (ICE). Landing-проекты |
| `api-specialist` | sonnet | context7 | Публичные/партнёрские API: контракт-first и OpenAPI-документация, GraphQL (DataLoader, complexity limits), rate limiting, webhooks (HMAC, retries), версионирование. API-проекты |
| `marketing-specialist` | sonnet | — | GTM-кампании (цели, каналы, тайминг, бюджет), маркетинговый контент, оптимизация каналов привлечения, анализ воронки и ROI (CAC/LTV). Запуск и бюджет — за пользователем. По вызову |
| `feature-documentation-writer` | sonnet | playwright | Документация фич после имплементации: user guides, API-доки, tutorials, how-to, release notes. Каждый шаг тестируется, примеры запускаются. По вызову |
| `monitoring-engineer` | sonnet | context7 | Observability: метрики (RED/USE), структурные логи с correlation ID, трейсы (OpenTelemetry), дашборды, алерты с runbooks, SLO/SLI. Деплой стека — через @devops. По вызову |
| `product-analyst` | sonnet | postgres, playwright | Продуктовая аналитика: North Star и metrics framework (decision-first), tracking plan / event schema, когорты и retention, дизайн экспериментов, аудит инструментации. По вызову |
| `marketing-analyst` | sonnet | playwright | Аналитика привлечения: UTM-таксономия и реестр, кросс-доменный трекинг, атрибуция, unit economics каналов (CAC/LTV:CAC/ROAS), отчётность с бюджетными рекомендациями. По вызову |

MCP-серверы опциональны: агент использует их, если они подключены в проекте (`.mcp.json`) или глобально; их отсутствие не ломает агента. Колонка MCP — рекомендации, не требования: при интеграции просканируй реально доступные MCP пользователя и раздай агентам из того, что есть (см. «Интеграция в проект» ниже).

### Python-агенты (папка `python/`)

Для проектов, где Python — ядро (AI-кор бэкенд, data-пайплайны, чистый Python-сервис), есть отдельный набор language-специфичных агентов: `python-async-specialist`, `python-type-checker`, `python-pytest-specialist`, `python-performance-optimizer`, `python-data-analyst`. Ставятся отдельными агентами ИЛИ их практики вливаются в существующих (backend-developer, ai-engineer, qa-engineer, performance-engineer и др.) — оба режима с таблицей маппинга описаны в [`python/README.md`](python/README.md).

### shadcn-агенты (папка `shadcn/`)

Для проектов, где UI собирается из готовых компонентов registry-библиотек (shadcn/ui и совместимые реестры — @magicui, @originui, @aceternity и др.): `shadcn-requirements-analyzer`, `shadcn-component-researcher`, `shadcn-implementation-builder`, `shadcn-quick-helper`. Плюс два файла-ресурса в проект — `components-library-rule.md` (какая библиотека приоритетна) и `registries.json` (справочник реестров).

**Ставятся только по явному запросу пользователя** — при интеграции сначала задаётся вопрос, работает ли проект с такими библиотеками (шаг 2 ниже). Ответ «нет» → папка не трогается вовсе. Оба режима подключения, граница с `frontend-developer` и таблица маппинга — в [`shadcn/README.md`](shadcn/README.md).

## Workflow

```
Брейншторм (режим РОЛИ, интерактивно с пользователем):
  User + @designer (для UI-фич: проектирование экранов, флоу, вайрфреймы — до планирования)
  → @implementation-plan-architect (+ @researcher по нужде)
  → спека → план → @implementation-plan-reviewer (полнота + архитектура + security плана) до ✅ APPROVED

Имплементация (сабагенты, автоматически):
  @backend-developer / @frontend-developer / @mobile-developer / @database-engineer / @ai-engineer (по плану, параллельно)
  → @code-reviewer (качество) ⇄ разработчик (до ✅)
  → @security-reviewer (безопасность) ⇄ разработчик (до ✅)
  → @qa-engineer (ручное или автотесты — режим задаётся в постановке)
  → @devops (commit / push / deploy / monitoring)

По вызову (не в обязательном пайплайне):
  @accessibility-expert · @performance-engineer · @error-detective · @researcher · @mobile-growth · @marketing-specialist · @feature-documentation-writer · @monitoring-engineer · @security-auditor · @product-analyst · @marketing-analyst
  Landing-проекты: @landing-optimizer · @landing-ab-tester · @conversion-analyst
  API-проекты: @api-specialist
  shadcn-проекты (папка shadcn/, ставятся по запросу):
    @designer → @shadcn-requirements-analyzer → @shadcn-component-researcher → @shadcn-implementation-builder → общий цикл ревью
    @shadcn-quick-helper — точечно, вне пайплайна
```

`@designer` — интерактивная роль: входить в диалог, не запускать fire-and-forget (вся ценность в вопросах, вариантах и гейтах). Механику брейншторма даёт скилл проекта (superpowers:brainstorming, grilling или другой) — в промпт агента она не зашита. Результат — UX-план, вайрфреймы и дизайн-спеки; реализует их @frontend-developer, которому передан и весь визуальный слой (токены, стили, анимации).

`@database-engineer` подключается точечно: схема/миграция для фичи (до или параллельно с @backend-developer), медленные запросы, data-level дебаг. Production-миграции применяет @devops по его rollback-плану.

`@ai-engineer` подключается при AI/ML-задачах в плане: LLM-фичи, RAG, модели, evals. Его код проходит тот же цикл ревью (code-reviewer → security-reviewer → qa). Vector store проектирует вместе с @database-engineer, деплой моделей — через @devops.

`@mobile-developer` подключается в мобильных проектах: платформенный UI, offline-first/sync, интеграция push. Его код проходит тот же цикл ревью; релизные сборки и публикация в сторы — через @devops. `@mobile-growth` — по вызову: ASO и push-кампании; выдаёт стратегию и материалы, механику реализует @mobile-developer.

Для landing-проектов — тройка `@landing-optimizer` + `@landing-ab-tester` + `@conversion-analyst`: optimizer проектирует структуру и копирайт, conversion-analyst диагностирует воронку (drop-off, поведение, фрикшены) и выдаёт приоритизированный бэклог гипотез, ab-tester превращает гипотезы в статистически корректные эксперименты. Все трое — стратегия и анализ; вариации, трекинг и внедрение победителя реализует @frontend-developer.

`@api-specialist` — для проектов, где API это продукт с внешними потребителями: публичный контракт, developer-документация, GraphQL, rate limiting, webhooks. Внутренние API приложения остаются за @backend-developer; auth-модель и webhook-безопасность идут на аудит @security-reviewer (у него для этого API-секция).

Четвёрка из `shadcn/` подключается только в проектах на registry-библиотеках готовых компонентов: `@designer` проектирует экраны как обычно, `@shadcn-requirements-analyzer` маппит их на компоненты библиотеки и строит иерархию, `@shadcn-component-researcher` достаёт из реестров реальные API, примеры и команды установки, `@shadcn-implementation-builder` собирает код. Дальше — общий цикл ревью без исключений. Граница с `@frontend-developer`: builder владеет композицией из компонентов библиотеки, формами и доступностью собранного; роутинг, стейт, интеграция с API, дизайн-токены и всё кастомное вне библиотеки остаются за frontend-developer, и спорный случай решается в его пользу.

`@marketing-specialist` — по вызову: GTM-стратегия, контент, каналы, воронка и ROI. Дирижирует ростовыми агентами: лендинг кампании — @landing-optimizer, эксперименты — @landing-ab-tester, стор/push в mobile — @mobile-growth, креативы — @designer. Запуск кампаний и бюджет всегда подтверждает пользователь.

`@feature-documentation-writer` — по вызову после имплементации (в идеале — после @qa-engineer): user guides, API-доки, tutorials, release notes в структуре доков проекта. Правило агента: ни один шаг не публикуется непроверенным, ни один пример — незапущенным. Публичный API-reference остаётся за @api-specialist.

`@monitoring-engineer` — по вызову: проектирование observability и инструментация кода (метрики, логи, трейсы), дашборды, алерты, SLO. Разделение с @devops: он деплоит стек мониторинга и владеет uptime/инфраструктурными алертами; @error-detective расследует инциденты инструментами, которые построил monitoring-engineer.

`@security-auditor` — по вызову: комплексный аудит существующего (brownfield) проекта — код, зависимости, секреты (включая историю git), инфраструктура (контейнеры, IaC, CI/CD, cloud IAM), data protection и заявленная регуляторика — с поэтапным remediation-планом и re-audit'ом после фиксов. Граница с @security-reviewer: тот — гейт пайплайна по фичам, аудитор — проект целиком, включая слои вне кода.

Пара аналитиков `@product-analyst` + `@marketing-analyst` — обязательная связка на сквозной воронке (handoff — signup): единый tracking plan в `docs/analytics/`, identity contract (UTM первого/последнего касания в профиль пользователя), ежемесячный feedback loop — product-analyst отдаёт когортное качество каналов (activation/retention/LTV), marketing-analyst перераспределяет бюджет по LTV:CAC, а не по CPL. Оба проектируют измерение; события в коде реализуют разработчики по их спецификациям.

Ключевое правило: **git-операции централизованы в @devops** — разработчики и QA не коммитят сами, а передают готовую работу DevOps-агенту.

## Установка (быстрая, руками)

```bash
# В конкретный проект
cp *.md /path/to/project/.claude/agents/

# Глобально для всех проектов
cp *.md ~/.claude/agents/
```

`README.md` и `docs/` копировать не нужно.

## Интеграция в проект — инструкция для кодингового агента

**Если ты — кодинговый агент, которому дали этот репозиторий с задачей «интегрируй агентов»,** работай по пайплайну ниже. Каждый пункт с пометкой «спроси» — реальный вопрос пользователю, не решай за него.

### 1. Куда ставим
Спроси: глобально (`~/.claude/agents/` — на все проекты) или в конкретный проект (`.claude/agents/`).

### 2. Кого ставим
1. Просканируй проект: `CLAUDE.md`, файлы зависимостей, быстрый grep по структуре — есть ли фронтенд, БД, API, тесты
2. Проверь уже установленных агентов (`~/.claude/agents/` и `.claude/agents/` проекта) — отметь пересечения по ролям, не дублируй
3. Предложи список под стек: нет БД → `database-engineer` не нужен; нет UI → `designer` / `frontend-developer` / `accessibility-expert` не нужны; и т.д.
   - **Python-проект (AI-кор, data, Python-сервис)?** Предложи также Python-агентов из `python/` — отдельными агентами или вливанием практик в существующих; оба режима и маппинг — в `python/README.md`. В AI-кор проекте без классического веб-бэкенда основной разработчик — `ai-engineer`, `backend-developer` может быть не нужен
4. **Спроси про shadcn — прямым вопросом да/нет:** «Работаете (или планируете работать) с shadcn/ui или другой registry-библиотекой готовых компонентов — @magicui, @originui, @aceternity и т.п.?»
   - **Нет** → папку `shadcn/` не трогаем вообще: агенты не ставятся, `docs/shadcn/` не создаётся, дальше про них не упоминаем
   - **Да** → добавь четвёрку из `shadcn/` в список кандидатов и подключай по `shadcn/README.md`: скопируй агентов, создай `docs/shadcn/` с `components-library-rule.md` и `registries.json`, **заполни правило вместе с пользователем** (какая библиотека основная — иначе агенты будут переспрашивать каждый запуск), проверь наличие shadcn MCP и `components.json` в корне проекта, проговори и зафиксируй в `CLAUDE.md` границу `shadcn-implementation-builder` ↔ `frontend-developer`
   - Не уверен по автодетекту — всё равно спрашивай: наличие `components.json` в корне это подсказка, а не ответ за пользователя
5. Режим выбора — спроси, как удобнее: поставить всех / выборочно списком / итеративно по одному (с объяснением роли каждого)
6. Финальный список законфирмь с пользователем ДО копирования

### 3. Структура docs
Агенты ссылаются на `docs/` (`ADR/`, `conventions/`, `backlog/`, `roadmap.md`, `research/`, `agent-learnings/`, а при подключённых shadcn-агентах — `shadcn/`) — всё опционально, отсутствие ничего не ломает. Но:
1. Проверь, что из этого есть в проекте
2. Если структуры нет — спроси: создать минимальную (`docs/backlog/`, `docs/ADR/`) / пользователь укажет свои существующие папки / оставить как есть
3. Если пользователь называет свои пути — поправь пути в УСТАНОВЛЕННЫХ копиях агентов (исходный репозиторий не трогай)

### 4. Режим брейншторма и логика работы с агентами
Роль-агенты (`implementation-plan-architect`, `designer`) рассчитаны на интерактивный брейншторм, механику которого даёт скилл пользователя.
1. Спроси, что использует: `superpowers:brainstorming` / `grilling` (GrillMe) / другой скилл / никакой
2. Выбранный режим пропиши в промпты роль-агентов — назови пользователю, чьи именно промпты правишь, и получи согласие
3. Логику работы с агентами (workflow, роли, гейты) закладывай ВСЕГДА: если она не расписана в `CLAUDE.md` / `AGENTS.md` проекта — предложи записать. Дефолт — записываем; пропускай только при явном отказе пользователя
4. Если скилла нет — замени обязательный вызов скилла на «выясни требования диалогом до планирования»

### 5. MCP
1. Просканируй доступные MCP: `.mcp.json` проекта + глобальные (`claude mcp list`)
2. Предложи раздачу по агентам из реально доступного (таблица выше — рекомендации)
3. `researcher` — ОБЯЗАТЕЛЬНО найди и выдай ему инструмент поиска/ресерча из того, что реально есть у пользователя: поисковый MCP (context7 / Exa / Brave Search / аналог), поисковый скилл или тула — и адаптируй его промпт под найденное. Если ничего нет — он работает на встроенных WebSearch/WebFetch
4. `mcpServers` в frontmatter установленных копий приведи к реальности проекта (отсутствующие MCP агент игнорирует, но чистый список честнее)

### 6. Agent Learnings
У всех агентов есть механизм learnings: столкнувшись с ошибкой или ограничением, агент пишет запись в `docs/agent-learnings/<агент>/`, а перед каждой работой ЧИТАЕТ свои накопленные записи и учитывает их. Оба поведения активны ТОЛЬКО если директория существует в проекте.
1. Спроси пользователя, хочет ли он это (одной строкой: «агенты будут накапливать знания об ошибках и ограничениях проекта, чтобы не повторять их»)
2. Да → сразу создай `docs/agent-learnings/` с коротким `README.md` (формат записи: дата, агент, что случилось, как обходить) — все агенты начнут писать автоматически
3. Нет → не создавай директорию; агенты молча пропустят (условие «если директория есть» уже зашито в их промптах)

Не оставляй это молчаливым: пользователь должен знать о механизме и явно выбрать.

### 7. Не Claude Code?
Если пользователь работает в другом кодинговом агенте (Codex, Gemini CLI, …) — предложи адаптацию: frontmatter-формат специфичен для `.claude/agents/`; для других инструментов перенеси содержимое промптов в их формат (AGENTS.md, GEMINI.md, их системы кастомных агентов).

### 8. Финал
1. Скопируй согласованных агентов, покажи итоговый список
2. Проверь установленные копии: пути `docs/` соответствуют проекту, `mcpServers` — реальности
3. Покажи пользователю workflow (схема выше) и напомни правило: git-операции — только через `@devops`

## Принципы

- **Универсальность** — никакого хардкода стека: агент определяет технологии по `CLAUDE.md` и файлам зависимостей
- **Adapt to Existing** — новый код пишется в стиле существующего кода проекта
- **Опциональные конвенции** — ссылки на `docs/conventions/`, `docs/ADR/`, дизайн-систему (`DESIGN.md` в корне или `docs/design-system.md`) работают, если эти файлы есть; их отсутствие не ломает агента
- **Дизайн-система first** — designer и frontend-developer читают `DESIGN.md` перед любой UI-работой; конфликт кода и дизайн-системы решается в пользу дизайн-системы. Приоритет визуальных решений: слова пользователя → дизайн-система → скилл `artifact-design` → вкус агента
- **Agent Learnings** — агенты фиксируют ошибки и ограничения в `docs/agent-learnings/` и ЧИТАЮТ свои накопленные learnings перед каждой работой (если директория есть в проекте; нет — молча пропускают)

## Credits

Роли и workflow-манифесты основаны на [X0-Framework](https://github.com/Serg1kk/X0-Framework) — meta-framework для Documentation-Driven Development с мультиагентной архитектурой.

agents

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

Download README