Claude Code Skills и Agents: продвинутые техники

Claude Code из коробки закрывает 80% задач разработчика. Оставшиеся 20% - повторяющиеся workflows, специфичные для проекта проверки, стандарты команды и автоматизации, которые не реализуешь через обычные промпты. Skills, Agents, Hooks и Memory превращают Claude Code из универсального ассистента в инструмент, заточенный под конкретный проект и команду.

В этом гайде - полная система расширения Claude Code: от создания первой slash-команды до оркестрации сотен параллельных субагентов через Dynamic Workflows. Каждый раздел содержит готовые конфигурации для копирования.

Skills: slash-команды на стероидах

Skills (slash-команды) - markdown-файлы, которые Claude Code выполняет как инструкции. Пользователь вводит /review, и Claude получает детальный промпт с контекстом, ограничениями и форматом вывода.

Расположение и область видимости

Skills хранятся в нескольких местах. Новый формат - директория <skill-name>/SKILL.md; старый .claude/commands/<skill>.md продолжает работать, но skills имеют приоритет:

Директория .claude/skills/deploy/ с файлом SKILL.md внутри становится командой /deploy. Поддерживаются вложенные директории: apps/web/.claude/skills/deploy/SKILL.md становится /apps/web:deploy при конфликте имён.

Формат файла

Минимальный skill - обычный markdown без frontmatter:

Проверь текущий код на SQL-инъекции, XSS и проблемы с аутентификацией.
Укажи конкретные строки и уровень severity для каждой находки.

Сохрани как .claude/skills/security-scan/SKILL.md - и команда /security-scan готова.

YAML Frontmatter

Frontmatter добавляет контроль над поведением skill:

---
description: Ревью PR на качество кода
allowed-tools: Read, Grep, Bash(git:*)
model: sonnet
argument-hint: [pr-number]
---

Разберём каждое поле:

description - краткое описание, отображается в /help. Если не указан, используется первый абзац контента.

when_to_use - дополнительный контекст для автоматического срабатывания: триггерные фразы, примеры запросов. Добавляется к description в листинге.

allowed-tools - предоставляет разрешение на перечисленные инструменты без запроса. Bash(git:*) разрешает git-команды без подтверждения. Не ограничивает остальные инструменты - они доступны, но требуют approve.

disallowed-tools - полностью убирает инструменты из доступных, пока skill активна. Сбрасывается при следующем сообщении.

model - выбирает модель на время выполнения skill: haiku для быстрых задач, sonnet для стандартных, opus для сложного анализа. Можно указать полный ID модели (claude-sonnet-5, claude-opus-5, claude-haiku-4-5). По умолчанию наследуется от сессии.

argument-hint - подсказка по аргументам при автодополнении.

arguments - именованные позиционные аргументы для подстановки $name. Например: arguments: [issue, branch] делает доступными $issue и $branch.

disable-model-invocation - если true, Claude не вызовет skill автоматически; только пользователь вручную через /name.

user-invocable - если false, skill скрыта из меню /, но Claude может вызвать её сам. Полезно для фоновых инструкций.

context: fork - запускает skill в изолированном субагенте.

effort - уровень усилий: low, medium, high, xhigh, max. Переопределяет уровень сессии на время выполнения.

paths - glob-паттерны: skill автоматически активируется только при работе с файлами, соответствующими паттернам.

license - лицензия skill (название или ссылка). Используется при публичном распространении через плагины.

compatibility - требования к окружению (OS, версия Claude Code, план подписки).

metadata - дополнительные ключ-значения: owner, version, внутренние теги команды.

Динамические аргументы

Skills принимают аргументы через $ARGUMENTS (все аргументы строкой) или позиционно: $0, $1, $2 (0-based индексы).

---
description: Исправить issue по номеру
argument-hint: [issue-number]
---

Исправь issue #$ARGUMENTS по стандартам проекта.
Прочитай описание, найди релевантный код, предложи fix.

Использование: /fix-issue 123 - Claude получает промпт с подставленным номером.

Позиционные аргументы передают несколько параметров (0-based индексация):

---
description: Деплой приложения
argument-hint: [environment] [version]
---

Задеплой приложение в окружение $0 версии $1.
Проверь конфигурацию, запусти pre-deploy checks, выполни деплой.

Именованные аргументы - через поле arguments во frontmatter:

---
description: Деплой приложения
arguments: [environment, version]
argument-hint: [environment] [version]
---

Задеплой приложение в окружение $environment версии $version.

Динамический контекст: ! и @

Два механизма подтягивают контекст в runtime:

@path - включает содержимое файла в промпт:

Проверь @tsconfig.json и @package.json на согласованность.
Убедись, что версии TypeScript совпадают.

!command - выполняет bash-команду и включает вывод:

---
allowed-tools: Bash(git:*)
---

Файлы в текущем PR: !`git diff --name-only main...HEAD`

Проведи ревью каждого изменённого файла.
Проверь: качество кода, потенциальные баги, покрытие тестами.

Комбинация обоих механизмов даёт контекстно-зависимые skills:

---
description: Анализ последних изменений
allowed-tools: Read Bash(git:*)
---

Последний коммит: !`git log -1 --format="%H %s"`
Изменённые файлы: !`git diff --name-only HEAD~1`
Текущая ветка: !`git branch --show-current`

Проанализируй изменения в контексте проекта.
Проверь, не нарушают ли они существующую архитектуру.

Пример: полноценный /review skill

---
description: Комплексное ревью кода с чеклистом
allowed-tools: Read Grep Glob Bash(git:*)
model: sonnet
argument-hint: [file-or-directory]
---

## Задача

Проведи ревью кода в $ARGUMENTS (или всех изменённых файлов, если аргумент не указан).

## Контекст

Изменения: !`git diff --cached --name-only 2>/dev/null || git diff --name-only HEAD~1`
Ветка: !`git branch --show-current`

## Чеклист

### Pass 1: Корректность
- Логические ошибки
- Необработанные edge cases
- Null/undefined handling

### Pass 2: Архитектура
- Соответствие существующим паттернам проекта
- Разделение ответственности
- Связность и сцепление модулей

### Pass 3: Безопасность
- Валидация входных данных
- SQL-инъекции, XSS
- Утечки секретов

### Pass 4: Производительность
- N+1 запросы
- Лишние ре-рендеры
- Неоптимальные алгоритмы

## Формат вывода

Для каждой находки укажи:
- Файл и строку
- Severity: critical / warning / suggestion
- Описание проблемы
- Предложенное исправление

Итого: общая оценка PR (approve / request changes) и основные рекомендации.

Agents: автономные субагенты

Нужен ли субагент для конкретной задачи, сколько стоит его запуск и когда он мешает, разобрано в отдельной статье о субагентах Claude Code. Здесь собраны формат файла, поля frontmatter и готовые примеры.

Agents (субагенты) - специализированные AI-помощники, которые выполняют сложные многошаговые задачи в изолированном контексте. В отличие от skills, agents:

• Работают в отдельном контексте - не засоряют основную сессию промежуточными результатами
• Запускаются параллельно
• Имеют собственные system prompts и ограничения по инструментам
• Возвращают только результат, не весь ход работы
• Могут работать в изолированном git worktree (isolation: worktree) - тогда агент получает чистую копию репозитория

Расположение

Формат файла

Agent - markdown-файл с обязательным frontmatter:

---
name: code-reviewer
description: Use this agent when...
model: inherit
color: blue
tools: ["Read", "Grep", "Glob"]
---

System prompt агента...

Frontmatter поля

name (обязательное) - уникальный идентификатор длиной до 256 символов, например code-reviewer. Не может содержать : (зарезервировано для plugin-агентов вида my-plugin:reviewer) и начинаться с -. Агента определяет это поле, а не имя файла.

description (обязательное) - самое важное поле. Определяет, когда Claude запустит агента. Рекомендуется включить:

1. Условия срабатывания: “Use this agent when…”
2. Блоки <example> с контекстом, запросом пользователя и реакцией ассистента
3. Блоки <commentary> с пояснением, почему агент подходит

model (опциональное) - алиас sonnet, opus, haiku или fable, полный ID модели (например, claude-opus-5-5) или inherit (модель основного разговора). Модель субагента выбирается по порядку:

1. Параметр model в конкретном вызове агента
2. Поле model во frontmatter
3. Переменная окружения CLAUDE_CODE_SUBAGENT_MODEL
4. Модель основного разговора

Без явных настроек субагент работает на модели основной сессии.

color (опциональное) - цвет в UI: red, blue, green, yellow, purple, orange, pink, cyan.

tools (опциональное) - доступные инструменты: строка через запятую (Read, Grep, Bash) или YAML-список. Если не указано, агент наследует все инструменты, доступные субагентам. Принцип наименьших привилегий: агент для анализа не должен иметь Write.

disallowedTools (опциональное) - инструменты, явно запрещённые агенту, в том же формате, что tools. Запись с уточнением вроде Bash(git push *) всё равно снимает инструмент целиком.

isolation (опциональное) - worktree запускает агента в изолированном git worktree. Worktree автоматически удаляется, если агент не внёс изменений.

maxTurns (опциональное) - максимальное число ходов агента. При достижении лимита результат возвращается с пометкой о том, что он частичный, и Claude может возобновить агента.

memory (опциональное) - персистентная память между сессиями: user, project или local.

effort (опциональное) - уровень усилий: low, medium, high, xhigh, max.

background (опциональное) - true оставляет агента в фоне, даже когда Claude собирается дождаться результата. Субагенты, запущенные из основного разговора, по умолчанию и так стартуют в фоне.

skills (опциональное) - список skills, которые инжектируются в контекст агента при запуске. Даёт агенту экспертизу без необходимости обнаруживать skills во время выполнения.

permissionMode (опциональное) - режим разрешений: default, acceptEdits, auto, dontAsk, bypassPermissions или plan; manual работает как синоним default.

mcpServers (опциональное) - список MCP-серверов для агента: строки с именами серверов или инлайн-объекты {name: config}.

hooks (опциональное) - хуки жизненного цикла, скоупленные к агенту. Поддерживаются все события, но чаще всего используются PreToolUse, PostToolUse и Stop.

initialPrompt (опциональное) - первый ход пользователя, который отправляется автоматически, когда агент запущен как главный агент сессии (--agent или настройка agent).

omitClaudeMd (опциональное) - true запускает агента без пользовательского, проектного и local CLAUDE.md; managed-политика всё равно загружается. Подходит агентам, которые получают всё нужное в задаче. Требует Claude Code v2.1.271+.

autoCompactWindow (опциональное) - уменьшенное окно авто-компакции для агента, от 100000 до 1000000 токенов. Требует v2.1.296+.

experimental.cacheTtl (опциональное) - время жизни prompt cache для запросов агента: 5m или 1h. Требует v2.1.248+.

Внимание: для plugin-субагентов поля hooks, mcpServers и permissionMode игнорируются из соображений безопасности; initialPrompt у них тоже не применяется.

Пример: Security Scanner Agent

---
name: security-scanner
description: |
  Use this agent for security review of code changes.
  Triggers on auth, payments, API endpoints, user data handling.

  <example>
  Context: User modified authentication flow
  user: "Review the auth changes I just made"
  assistant: "I'll use the security-scanner agent to check for vulnerabilities"
  <commentary>Auth changes require specialized security review</commentary>
  </example>

  <example>
  Context: New API endpoint added
  user: "Check if this endpoint is secure"
  assistant: "I'll use the security-scanner agent to verify input validation and authorization"
  <commentary>New endpoints need OWASP Top 10 verification</commentary>
  </example>
model: sonnet
color: red
tools: ["Read", "Grep", "Glob", "Bash"]
---

You are a security engineer with an attacker's mindset.
Focus on real-world exploitable vulnerabilities, not theoretical concerns.

## Review Process

1. **Identify attack surface**: endpoints, inputs, auth flows, data access
2. **Check OWASP Top 10**: injection, broken auth, XSS, IDOR, misconfigurations
3. **Verify authorization**: every endpoint checks permissions before data access
4. **Review input validation**: all user inputs validated and sanitized
5. **Check secrets**: no hardcoded API keys, tokens, passwords

## Output Format

For each vulnerability:
- **Location**: file:line
- **Severity**: Critical / High / Medium / Low
- **Category**: OWASP category
- **Description**: what's wrong
- **Exploit scenario**: how an attacker would use this
- **Fix**: specific code change

Summary: total vulnerabilities by severity, overall risk assessment.

Пример: Test Writer Agent

---
name: test-writer
description: |
  Use this agent to generate comprehensive tests for code.
  Triggers on: "write tests", "add tests", "test coverage", new features without tests.

  <example>
  Context: User implemented a new utility function
  user: "Write tests for the parseConfig module"
  assistant: "I'll use the test-writer agent to generate comprehensive tests"
  <commentary>New code without tests needs systematic test generation</commentary>
  </example>

  <example>
  Context: User asks about test coverage
  user: "This module has no tests, fix it"
  assistant: "I'll use the test-writer agent to analyze the module and create tests"
  <commentary>Missing tests require understanding module contracts</commentary>
  </example>
model: inherit
color: green
tools: ["Read", "Write", "Grep", "Glob", "Bash"]
---

You are a testing specialist. Write tests that verify behavior, not implementation.

## Process

1. Read the source code and understand its public API
2. Identify test categories: happy path, edge cases, error handling, integration
3. Check existing test patterns in the project (framework, style, conventions)
4. Generate tests following project conventions
5. Run tests to verify they pass

## Test Design Principles

- **One assertion per test** where practical
- **Descriptive test names**: "should return empty array when input is null"
- **AAA pattern**: Arrange, Act, Assert
- **No implementation coupling**: test behavior through public API
- **Cover edge cases**: null, undefined, empty, boundary values, concurrent access
- **Mock only external dependencies**: database, network, file system

## Output

- Test file(s) following project naming convention
- Summary of coverage: what's tested, what's intentionally skipped and why

Пример: Code Reviewer Agent

---
name: code-reviewer
description: |
  Use this agent for detailed code review with actionable feedback.
  Triggers on: "review this", "check my code", PR review requests.

  <example>
  Context: User completed a feature implementation
  user: "Review the changes in src/api/"
  assistant: "I'll use the code-reviewer agent for a detailed multi-pass review"
  <commentary>Feature review needs systematic multi-pass analysis</commentary>
  </example>
model: sonnet
color: cyan
tools: ["Read", "Grep", "Glob"]
---

You are a senior engineer conducting code review.
Prioritize: Correctness > Security > Performance > Maintainability.

## Multi-Pass Review

### Pass 1: Correctness (mandatory)
- Logic errors, off-by-one, null handling
- All code paths handled
- Error propagation correct

### Pass 2: Architecture
- Fits existing project patterns
- Single responsibility maintained
- No unnecessary coupling

### Pass 3: Performance
- No N+1 queries
- Efficient algorithms for data size
- No memory leaks or unnecessary allocations

### Pass 4: Maintainability
- Code is self-documenting
- No magic numbers or strings
- Tests present and meaningful

## Output Format

**Verdict**: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION

For each finding:
- 📍 Location: `file:line`
- 🔴/🟡/🟢 Severity
- Description and suggested fix

**Summary**: key strengths and areas for improvement.

Изоляция и контекст

Агенты работают в изолированном контексте:

• Основной агент не видит промежуточные шаги субагента - только финальный результат
• Субагент не имеет доступа к истории основного чата
• Несколько субагентов могут работать параллельно без конфликтов

Практическая ценность - в управлении контекстом: субагент читает десятки файлов и возвращает только резюме на 20 строк, основная сессия остаётся чистой.

Автоматический и явный вызов

Claude Code определяет, когда запустить агента, по description. Чем точнее примеры в <example> блоках, тем точнее срабатывание.

Явный вызов: “Use the security-scanner agent to check this file” - Claude найдёт агента по имени.

Hooks: событийная автоматизация

Hooks - обработчики, которые Claude Code запускает автоматически в заданных точках цикла: до и после вызова инструмента, при отправке промпта, на старте и остановке сессии, перед компакцией. Handler может быть bash-командой (command), HTTP-эндпоинтом (http), MCP-инструментом (mcp_tool), LLM-промптом (prompt) или субагентом (agent, помечен как experimental). В отличие от инструкции в CLAUDE.md, хук выполняется каждый раз и не зависит от решения модели.

Основные события

Событий больше 30, и список растёт почти с каждым релизом, поэтому полный перечень лучше смотреть в Hooks reference. Для большинства задач хватает десятка:

Конфигурация

Hooks задаются в settings.json (user, project или local scope), в плагинах и во frontmatter skill или субагента. Структура трёхуровневая: событие, группа с matcher, список обработчиков.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-files.sh",
            "timeout": 5,
            "onFailure": "block"
          }
        ]
      }
    ]
  }
}

matcher на tool-событиях фильтрует по имени инструмента: "Write|Edit" - точный список, "*" или пустое значение - все, строка с другими символами ("mcp__.*") читается как regex. timeout задаётся в секундах, по умолчанию 600 для command, http и mcp_tool, поэтому на частых событиях его лучше указывать явно. onFailure: "block" нужен защитным хукам: без него таймаут или падение хука вызов не блокирует. Все подходящие обработчики события выполняются параллельно.

Выходные коды

• 0 - успех. Stdout разбирается как JSON-ответ; plain-текст попадает в контекст Claude только на UserPromptSubmit, UserPromptExpansion, SessionStart и PostModelSwitch, на остальных событиях уходит в debug-лог.
• 2 - блокировка на событиях, которые её поддерживают (PreToolUse, UserPromptSubmit, Stop и др.). Причина пишется в stderr обычным текстом, и Claude её видит. JSON, выведенный в stderr, решением не считается.
• Любой другой код, включая 1, - некритичная ошибка: Claude Code покажет hook error, и действие выполнится. Защитный хук с exit 1 ничего не блокирует.

Пример: защита критичных файлов

Скрипт protect-files.sh для конфигурации выше запрещает правку секретов, .git/ и lock-файла:

#!/bin/bash
P=$(jq -r '.tool_input.file_path // empty')
[ -z "$P" ] && exit 0
case "$P" in
  *.env|*/.env.*|*/.git/*|*/package-lock.json|*.pem|*.key)
    echo "Заблокировано: $P в списке защищённых путей" >&2
    exit 2 ;;
esac
exit 0

Хук видит только Edit и Write: команду echo X > .env через Bash он не перехватит, для неё нужен deny-rule в permissions.

Правки хуков в файлах настроек обычно подхватываются без перезапуска: Claude Code следит за этими файлами. Если изменение не появилось, помогает перезапуск сессии. Загруженные хуки показывает команда /hooks.

Подробнее: exit codes по каждому событию, JSON-решения, рецепты защиты для Bash, Stop-gate с проверкой stop_hook_active, форматирование после правки, уведомления, отладка и безопасность самих хуков разобраны в статье Claude Code hooks: рецепты, exit codes и безопасность.

Memory: персистентность между сессиями

Memory - механизм сохранения знаний между сессиями. Claude запоминает решения, паттерны и контекст проекта, и не переспрашивает одно и то же.

Типы memory

CLAUDE.md файлы - инструкции, которые Claude загружает при старте:

Auto-memory - Claude автоматически сохраняет feedback и решения.

Расположение: ~/.claude/projects/<project>/memory/ (путь формируется из git-репозитория проекта)

Когда Claude получает коррекцию от пользователя, он сохраняет её в memory-файлы. Файл MEMORY.md служит индексом. При старте сессии загружаются первые 200 строк или первые 25KB этого файла.

Структура MEMORY.md

# Memory Index

- [feedback_article_tone.md](feedback_article_tone.md) — Тон статей: профессиональный, технический
- [feedback_publish_date.md](feedback_publish_date.md) — Дата публикации = день реальной публикации
- [reference_telegram_channel.md](reference_telegram_channel.md) — Telegram-канал: @futcraft
- [project_reddit_strategy.md](project_reddit_strategy.md) — Reddit Growth Strategy: 6-месячный roadmap

Типы memory-файлов

Имена файлов следуют конвенции по типу:

feedback_ - коррекции от пользователя. “Не добавляй эмодзи в коммиты”, “Используй vitest, не jest”. Самый частый тип.

reference_ - справочная информация. ID каналов, URL API, ключевые конфиги. То, что Claude не найдёт в коде.

project_ - проектные решения. Архитектурные выборы, стратегии, roadmaps. Контекст, который Claude учитывает при работе.

user_ - персональные предпочтения. Стиль кода, предпочитаемые инструменты, форматы вывода.

Практика: эффективная работа с memory

Memory работает автоматически, но процессом можно управлять явно:

1. Коррекция - исправь Claude: “Нет, используй pnpm, не npm”. Он сохранит это в feedback и применит в следующей сессии.

2. Явное сохранение - “Запомни: в этом проекте все API-ответы оборачиваются в { data, error, meta }”. Claude создаст memory-файл.

3. Проверка - открой ~/.claude/projects/*/memory/MEMORY.md, удали устаревшие записи.

4. Миграция - если правило глобальное, перенеси его в ~/.claude/CLAUDE.md.

CLAUDE.md: продвинутая конфигурация

CLAUDE.md - markdown-файл с постоянными инструкциями, который Claude Code загружает в контекст в начале каждой сессии: команды сборки и тестов, соглашения команды, неочевидные ограничения проекта. Это контекст для модели, а не принудительная настройка. Если действие нужно запретить без исключений, его переносят в hook.

Ключевые факты:

• Четыре уровня. В порядке загрузки, от широкого к узкому: managed policy организации, пользовательский ~/.claude/CLAUDE.md, проектный ./CLAUDE.md или ./.claude/CLAUDE.md и личный ./CLAUDE.local.md (добавить в .gitignore).
• Файлы склеиваются, а не переопределяют друг друга. Порядок идёт от корня файловой системы к рабочей директории, поэтому инструкции ближе к месту запуска модель читает последними. Если два файла противоречат друг другу, Claude может выбрать любой вариант: противоречия убирают из самих файлов.
• Правила для части кода кладут в .claude/rules/ с полем paths во frontmatter: такие правила грузятся, когда Claude работает с подходящими файлами. Импорт @path/to/file подключает другой файл, но контекст не экономит: импортированный файл грузится вместе с родительским.
• Коротко и конкретно. Документация рекомендует держать каждый CLAUDE.md короче 200 строк и писать проверяемые формулировки: «Используй pnpm, не npm» вместо «используй правильный пакетный менеджер». Пометки CRITICAL и капслок не нужны: современные модели следуют обычной формулировке, а от эмфазы могут применять правило шире нужного.

Подробнее о загрузке вложенных CLAUDE.md, импортах, .claude/rules/, шаблон файла и чек-лист аудита - в гайде по CLAUDE.md.

Комбинации: оркестрация компонентов

Настоящая сила - в комбинации всех компонентов. Skills запускают агентов, hooks передают контекст через env, memory накапливает правила между сессиями, а Dynamic Workflows масштабирует это на сотни параллельных задач.

Skill вызывает Agent

Skill может включать инструкцию запустить конкретного агента:

---
description: Полный цикл ревью PR
argument-hint: [pr-number]
allowed-tools: Bash(gh:*), Read
---

PR #$ARGUMENTS:
Информация: !`gh pr view $ARGUMENTS --json title,body,files`

Phase 1: Запусти code-reviewer агента для анализа изменений.
Phase 2: Запусти security-scanner агента для проверки безопасности.
Phase 3: На основе результатов обоих агентов сформируй итоговый вердикт.

Claude запускает оба агента (потенциально параллельно), собирает их результаты и формирует общее заключение.

Hook информирует Claude через контекст

SessionStart hook загружает информацию, которую skill или agent используют:

# load-context.sh
#!/bin/bash

# Проверяем, есть ли открытые PR
OPEN_PRS=$(gh pr list --json number,title --limit 5 2>/dev/null || echo "[]")
echo "export OPEN_PRS='$OPEN_PRS'" >> "$CLAUDE_ENV_FILE"

# Последний неудачный CI run
FAILED_RUN=$(gh run list --status failure --limit 1 --json databaseId,name 2>/dev/null || echo "[]")
echo "export FAILED_CI='$FAILED_RUN'" >> "$CLAUDE_ENV_FILE"

Теперь skill использует этот контекст:

---
description: Утренний статус проекта
---

Покажи утренний статус:
1. Текущая ветка и незакоммиченные изменения
2. Открытые PR (из env OPEN_PRS)
3. Последний упавший CI (из env FAILED_CI)
4. Приоритетные задачи на сегодня

Короткий контекст можно отдать и без переменных: plain-текст, который SessionStart-хук печатает в stdout, попадает прямо в контекст Claude. Этот вариант и повторная инъекция контекста после компакции разобраны в статье о хуках Claude Code.

Memory информирует Agent

Когда Claude получает коррекцию (“В этом проекте не используй Lodash, всё есть в стандартной библиотеке”), это сохраняется в memory. В следующей сессии code-reviewer агент учитывает это правило без напоминаний - CLAUDE.md и memory загружаются при старте.

Цепочка: пользователь исправляет Claude → memory сохраняет feedback → CLAUDE.md загружает при старте → agent учитывает при анализе.

Реальные workflow

Workflow 1: Onboarding нового разработчика

Новый разработчик клонирует проект. CLAUDE.md описывает архитектуру, conventions и команды. Skills берут на себя рутину:

• /setup - устанавливает зависимости, настраивает окружение, проверяет prerequisites
• /architecture - объясняет структуру проекта, ключевые модули, потоки данных
• /find-examples - находит примеры использования паттерна в кодовой базе

Agents помогают разбираться:

• code-reviewer агент ревьюит первые PR
• test-writer агент генерирует тесты по конвенциям проекта

Hooks обеспечивают качество:

• PreToolUse hook проверяет, что новый код не нарушает конвенции
• Stop hook проверяет, что тесты написаны и проходят

Workflow 2: Automated PR Review

---
description: Автоматический ревью PR
argument-hint: [pr-number]
allowed-tools: Bash(gh:*), Read, Grep, Glob
model: sonnet
---

## PR Review Pipeline

PR: !`gh pr view $ARGUMENTS --json title,body,additions,deletions,changedFiles`
Файлы: !`gh pr diff $ARGUMENTS --name-only`

### Step 1: Scope Assessment
Оцени масштаб изменений. Если > 500 строк, предупреди о рисках большого PR.

### Step 2: Code Review
Запусти code-reviewer агента на изменённых файлах.

### Step 3: Security Check
Если изменения затрагивают auth, API endpoints или обработку данных —
запусти security-scanner агента.

### Step 4: Test Coverage
Проверь наличие тестов для новых функций.
Если тестов нет — запусти test-writer агента.

### Step 5: Final Verdict
Объедини результаты всех проверок.
Формат: APPROVE / REQUEST CHANGES с конкретными action items.

Workflow 3: Release Management

---
description: Подготовка релиза
argument-hint: [version]
allowed-tools: Bash(git:*, npm:*, gh:*), Read, Write, Edit
---

## Release Checklist для версии $ARGUMENTS

### Pre-release
1. Проверить: !`git status --porcelain`
2. Текущая ветка: !`git branch --show-current`
3. Все тесты проходят: !`npm test 2>&1 | tail -5`

### Changelog
4. Собери коммиты с последнего релиза: !`git log $(git describe --tags --abbrev=0)..HEAD --oneline`
5. Сгенерируй changelog в формате Keep a Changelog

### Version Bump
6. Обнови version в package.json до $ARGUMENTS
7. Обнови CHANGELOG.md

### Release
8. Создай коммит: "chore: release v$ARGUMENTS"
9. Создай тег: v$ARGUMENTS
10. Покажи команды для push (но не выполняй без подтверждения)

Workflow 4: Debugging Methodology

---
description: Системная отладка проблемы
argument-hint: [description]
allowed-tools: Read, Grep, Glob, Bash(*)
model: opus
---

## Systematic Debugging: $ARGUMENTS

### Phase 1: Reproduce
Определи точные шаги воспроизведения проблемы.
Найди минимальный test case.

### Phase 2: Isolate
Используй binary search по коммитам если проблема регрессионная.
Определи: какой модуль, функция, строка вызывает проблему.

### Phase 3: Hypothesize
Сформулируй 3 гипотезы о причине.
Для каждой гипотезы опиши: как проверить, что искать.

### Phase 4: Verify
Проверь каждую гипотезу начиная с наиболее вероятной.
Покажи доказательства (логи, значения, stack traces).

### Phase 5: Fix
Предложи минимальное исправление.
Объясни, почему оно решает root cause, а не симптом.
Предложи тест, который предотвратит регрессию.

Dynamic Workflows: оркестрация сотен субагентов

Dynamic Workflows - ключевое обновление 2026 года. Это JavaScript-скрипты, которые Claude пишет сам и запускает в фоне, координируя десятки и сотни параллельных субагентов в рамках одной сессии.

Как это работает

Вы описываете задачу: «Сделай аудит безопасности всей кодовой базы» или «Проведи миграцию с REST на GraphQL». Claude:

1. Составляет план - декомпозирует работу на параллельные подзадачи
2. Генерирует JavaScript-скрипт оркестрации
3. Запускает субагентов - до 16 параллельно, не более 1 000 суммарно за один run
4. Валидирует результаты перед финальным ответом

Ваша основная сессия остаётся отзывчивой: workflow выполняется в фоне, прогресс виден в UI.

Типичные сценарии

• Аудит кодовой базы (безопасность, качество, документация)
• Крупные миграции (версия фреймворка, смена API)
• Кросс-проектные исследования с несколькими источниками

Сохранение и переиспользование

Скрипты сохраняются через меню workflow (клавиша s). Два пути хранения:

• ~/.claude/workflows/ - персональные
• В папке skill с указанием в SKILL.md - для дистрибуции через плагины

---
description: Security audit workflow
---

Запусти dynamic workflow из @security-audit.js для аудита всей кодовой базы.
Используй скрипт как шаблон и адаптируй под текущий стек.

Доступность

Dynamic Workflows включены по умолчанию для планов Max, Team, Enterprise и при работе через API. Пользователи плана Pro могут включить в /config. Активировать через /workflows или через настройку ultracode.

Agent Teams: параллельная работа команды агентов

Agent Teams - экспериментальная функция, отключённая по умолчанию. Включается через переменную CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS в settings.json. Имеет известные ограничения по возобновлению сессий и управлению задачами.

Agent Teams - развитие модели субагентов: несколько экземпляров Claude работают параллельно над разными подзадачами, координируясь через общий список задач.

В отличие от ручного запуска нескольких сессий, Agent Teams обеспечивает встроенную координацию:

• Агенты захватывают задачи без конфликтов - через file locking при клейме задач
• Участники общаются напрямую через mailbox, а также через ведущего агента
• Ведущий агент (lead) координирует список задач и синтезирует результаты

Событие TeammateIdle в хуках позволяет реагировать, когда участник команды завершает задачу - например, запустить следующую стадию обработки.

Плагины: дистрибуция skills и агентов

С ростом экосистемы Claude Code в 2026 году оформилось различие между skills и плагинами:

• Skill - один файл SKILL.md с инструкциями
• Плагин - комплект: несколько skills + MCP-серверы + агенты + конфиги, упакованные как одна устанавливаемая единица

Плагины устанавливаются через команду /plugin внутри Claude Code:

/plugin marketplace add <user-or-org/repo-name>

Централизованного официального маркетплейса нет - экосистема децентрализована. Плагины публикуются в git-репозиториях; маркетплейс подключается через URL или GitHub-репо с файлом .claude-plugin/marketplace.json. Официальный каталог Anthropic доступен через /plugin marketplace add anthropics/claude-code.

Для публикации собственного плагина в SKILL.md используются поля license, compatibility и metadata.

Headless режим и автоматизация

Claude Code поддерживает неинтерактивный запуск через флаг -p:

# Базовый headless-запуск
claude -p "Проведи аудит безопасности src/" --output-format json

# С конкретной моделью
claude -p "Обнови dependencies до последних версий" \
  --model claude-opus-5 \
  --allowedTools "Read,Write,Bash"

# Продолжение предыдущей сессии
claude --continue -p "Теперь напиши тесты для исправленного кода"

# Структурированный вывод
claude -p "Проанализируй API и верни JSON-отчёт" \
  --output-format json \
  --json-schema report-schema.json

С февраля 2026 года доступен Remote Control режим: запустите его через /remote-control - Claude покажет QR-код для подключения с телефона через приложение Claude. Это даёт полный контроль сессии, включая управление файлами и мониторинг прогресса.

Обновлённое десктопное приложение

В апреле 2026 года Anthropic выпустила кардинальный редизайн Claude Code Desktop:

Мультисессионность - сайдбар управляет всеми активными и недавними сессиями. Запускайте работу в нескольких репозиториях одновременно и переключайтесь по мере получения результатов.

Интегрированные инструменты - встроенный терминал, редактор файлов, ускоренный diff-viewer для больших changeset’ов, превью HTML/PDF и запуск локальных серверов.

Кастомный layout - каждая панель (терминал, превью, diff, чат) перетаскивается, сетка настраивается под рабочий стиль.

Паритет с CLI - поддержка плагинов и SSH для удалённых машин (macOS и Linux).

Приложение доступно для всех планов: Pro, Max, Team, Enterprise и через API.

Готовые шаблоны

5 Skills для копирования

1. /adr - Architecture Decision Record

---
description: Создать Architecture Decision Record
argument-hint: [title]
allowed-tools: Read, Write, Glob
---

Создай ADR (Architecture Decision Record) по теме: $ARGUMENTS

Найди существующие ADR: !`ls docs/decisions/ 2>/dev/null || echo "Нет ADR"`

Формат ADR:

# ADR-[NEXT_NUMBER]: $ARGUMENTS

## Status
Proposed

## Context
[Какая проблема решается]

## Decision
[Что решили]

## Consequences
### Positive
- [Плюсы]

### Negative
- [Минусы]

### Neutral
- [Нейтральные последствия]

## Alternatives Considered
[Какие альтернативы рассматривались и почему отклонены]

Сохрани в docs/decisions/adr-[NUMBER]-[slug].md

2. /test - Запуск и анализ тестов

---
description: Запусти тесты и проанализируй результат
argument-hint: [test-path]
allowed-tools: Bash(npm:*, npx:*, pnpm:*), Read
model: sonnet
---

Запусти тесты: !`npm test -- $ARGUMENTS 2>&1 | tail -50`

Если тесты прошли: краткий отчёт, покрытие.
Если тесты упали:
1. Определи root cause каждого failure
2. Предложи конкретный fix
3. Укажи, регрессия это или новый баг

3. /deploy - Pre-deploy проверки

---
description: Pre-deploy проверки и деплой
argument-hint: [environment]
allowed-tools: Bash(*), Read
---

## Pre-Deploy Checklist для $ARGUMENTS

1. Git status: !`git status --porcelain`
2. Текущая ветка: !`git branch --show-current`
3. Непушнутые коммиты: !`git log @{u}..HEAD --oneline 2>/dev/null || echo "No upstream"`
4. Тесты: !`npm test 2>&1 | tail -10`
5. Build: !`npm run build 2>&1 | tail -10`

Если все проверки пройдены, покажи команду деплоя для $ARGUMENTS.
Если нет — покажи что исправить.

4. /refactor - Безопасный рефакторинг

---
description: Рефакторинг с сохранением поведения
argument-hint: [file-or-module]
allowed-tools: Read, Write, Edit, Grep, Glob, Bash(npm:*)
model: opus
---

## Рефакторинг: $ARGUMENTS

### Phase 1: Understand
Прочитай код. Определи: что делает, как используется, какие тесты покрывают.

### Phase 2: Identify
Найди code smells:
- Дублирование
- Слишком длинные функции (> 50 строк)
- Глубокая вложенность (> 3 уровня)
- Нарушение Single Responsibility

### Phase 3: Plan
Предложи план рефакторинга. Каждый шаг должен:
- Сохранять поведение (тесты продолжают проходить)
- Быть атомарным (один коммит)

### Phase 4: Execute
Выполни рефакторинг пошагово.
После каждого шага: запусти тесты.

5. /api-docs - Генерация документации API

---
description: Генерация документации для API endpoint
argument-hint: [file-path]
allowed-tools: Read, Grep, Glob
---

Прочитай @$1 и сгенерируй документацию API.

Формат для каждого endpoint:

### [METHOD] /path

**Description:** Краткое описание

**Authentication:** Required/Optional

**Request:**
- Headers: ...
- Body: schema с типами

**Response:**
- 200: Success schema
- 400: Validation error
- 401: Unauthorized
- 500: Server error

**Example:**
```bash
curl -X POST /api/endpoint \
  -H "Authorization: Bearer token" \
  -d '{"key": "value"}'

Используй типы из кода, не придумывай.

### 3 Agents для копирования

#### 1. Database Migration Reviewer

```markdown
---
name: migration-reviewer
description: |
  Use this agent to review database migrations for safety and correctness.
  Triggers on: migration files, schema changes, SQL modifications.

  <example>
  Context: User created a new migration
  user: "Review this migration before I apply it"
  assistant: "I'll use the migration-reviewer agent to check for data safety issues"
  <commentary>Migrations need careful review for data loss, locking, and rollback</commentary>
  </example>
model: sonnet
color: yellow
tools: ["Read", "Grep", "Glob"]
---

You are a database migration specialist. Review migrations for safety, correctness, and performance.

## Checklist

1. **Data Safety**
   - Can this migration cause data loss?
   - Is there a rollback path?
   - Are default values set for new NOT NULL columns?

2. **Locking**
   - Will this lock tables for a long time?
   - Use CONCURRENTLY for indexes on large tables?
   - Avoid ALTER TABLE on hot tables during peak hours

3. **Performance**
   - Will this migration be fast enough for production data volume?
   - Are new indexes necessary and efficient?
   - No missing indexes for new foreign keys

4. **Compatibility**
   - Is this backward-compatible with current application code?
   - Can old and new code run simultaneously during deploy?

## Output
- SAFE / NEEDS ATTENTION / DANGEROUS
- Specific issues with fixes
- Estimated execution time for production data

2. Dependency Auditor

---
name: dependency-auditor
description: |
  Use this agent to audit project dependencies for security and health.
  Triggers on: "audit dependencies", "check packages", dependency updates.

  <example>
  Context: User wants to check dependency health
  user: "Audit our dependencies"
  assistant: "I'll use the dependency-auditor agent to check for vulnerabilities and outdated packages"
  <commentary>Regular dependency audits catch vulnerabilities early</commentary>
  </example>
model: sonnet
color: yellow
tools: ["Read", "Bash", "Grep"]
---

You are a dependency security specialist. Audit project dependencies comprehensively.

## Process

1. Run security audit: `npm audit` / `pip audit` / `cargo audit`
2. Check for outdated packages with major version gaps
3. Identify packages with known CVEs
4. Check license compatibility
5. Identify abandoned packages (no updates > 2 years)

## Output

### Critical (act now)
- Packages with known exploited vulnerabilities

### High (act this sprint)
- Packages with high-severity CVEs
- Packages 2+ major versions behind

### Medium (plan for)
- Outdated packages with breaking changes ahead
- Packages approaching end-of-life

### Info
- License summary
- Dependency tree depth
- Total package count

3. Performance Profiler

---
name: performance-profiler
description: |
  Use this agent to analyze code for performance issues.
  Triggers on: "performance", "slow", "optimize", "profiling".

  <example>
  Context: User reports slow API endpoint
  user: "This endpoint takes 3 seconds, find out why"
  assistant: "I'll use the performance-profiler agent to analyze bottlenecks"
  <commentary>Performance issues need systematic profiling, not guessing</commentary>
  </example>
model: opus
color: purple
tools: ["Read", "Grep", "Glob", "Bash"]
---

You are a performance engineer. Find and fix bottlenecks systematically.

## Analysis Process

1. **Identify hot path**: trace the execution path of the slow operation
2. **Database queries**: find N+1, missing indexes, full table scans
3. **Algorithm complexity**: check for O(n^2) or worse in loops
4. **I/O operations**: unnecessary disk reads, synchronous network calls
5. **Memory**: large allocations, data structure inefficiency
6. **Caching**: missed caching opportunities, cache invalidation issues

## Report Format

### Bottleneck #N
- **Location**: file:line
- **Impact**: estimated time/memory cost
- **Root cause**: why it's slow
- **Fix**: specific code change
- **Expected improvement**: quantified estimate

### Summary
- Top 3 bottlenecks ranked by impact
- Quick wins vs. architectural changes
- Recommended order of fixes

Hooks для копирования

Готовые рецепты хуков с корректными exit codes (защита файлов, guard для Bash, форматирование после правки, Stop-gate, журнал активности, уведомления) собраны в статье Claude Code hooks: рецепты, exit codes и безопасность.

Организация файлов

Рекомендуемая структура .claude/ для проекта средней сложности:

.claude/
├── settings.json           # Permissions, hooks, env
├── settings.local.json     # Персональные переопределения (gitignored)
├── CLAUDE.md               # Или CLAUDE.md в корне проекта
├── skills/                 # Project skills (новый формат)
│   ├── review/
│   │   └── SKILL.md
│   ├── test/
│   │   └── SKILL.md
│   └── deploy/
│       └── SKILL.md
├── commands/               # Legacy skills (продолжают работать)
│   └── ...
├── agents/                 # Project agents
│   ├── code-reviewer.md
│   ├── test-writer.md
│   └── security-scanner.md
└── rules/                  # File-scoped rules
    ├── api.md
    ├── database.md
    └── tests.md

Для персональных (user-scope) - аналогичная структура в ~/.claude/:

~/.claude/
├── settings.json
├── CLAUDE.md
├── skills/                 # Global skills
│   ├── debug/
│   │   └── SKILL.md
│   ├── git-workflow/
│   │   └── SKILL.md
│   └── morning-standup/
│       └── SKILL.md
├── agents/                 # Global agents
│   ├── senior-reviewer.md
│   └── performance-profiler.md
└── hooks/                  # Hook scripts
    ├── protect-files.sh
    └── auto-format.sh

Итого

Skills, Agents, Hooks, Memory и Dynamic Workflows - пять основных механизмов расширения Claude Code, каждый на своём уровне:

• Skills - slash-команды для повторяющихся задач с предсказуемым форматом. Вызываются вручную или автоматически. Хранятся в .claude/skills/<name>/SKILL.md.
• Agents - изолированные субпроцессы для сложных многошаговых задач. Возвращают только результат. Поддерживают skills, permissionMode, mcpServers, hooks и initialPrompt.
• Hooks - автоматические реакции на события (30+ событий). Для enforcement правил и интеграции с внешними инструментами. Handlers: command, http, mcp_tool, prompt, agent.
• Memory - персистентность между сессиями. Claude учится на коррекциях и не повторяет ошибки.
• CLAUDE.md - декларативные инструкции, задающие поведение Claude в проекте.
• Dynamic Workflows - JavaScript-оркестрация сотен параллельных субагентов для масштабных задач. Пишется Claude, выполняется в фоне. Доступно на всех платных планах (на Pro включается в /config).
• Agent Teams - несколько экземпляров Claude в параллельной работе с координацией через общий список задач. Экспериментальная функция, требует включения через CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS.
• Плагины - комплексные пакеты (skills + MCP + агенты), распространяемые через маркетплейс.