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 имеют приоритет:

Расположение	Область видимости	Метка в `/help`
`.claude/skills/<name>/SKILL.md`	Только текущий проект	(project)
`~/.claude/skills/<name>/SKILL.md`	Все проекты пользователя	(user)
`.claude/commands/deploy.md`	Текущий проект (legacy)	(project)
`~/.claude/commands/`	Все проекты (legacy)	(user)

Директория .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-4-6, claude-opus-4-8, 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: автономные субагенты

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

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

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

Расположение	Область видимости
`.claude/agents/`	Только текущий проект, доступен всей команде через git
`~/.claude/agents/`	Все проекты пользователя

Формат файла

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

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

System prompt агента...

Frontmatter поля

name (обязательное) — уникальный идентификатор. Lowercase, цифры, дефисы.

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

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

model (опциональное, по умолчанию inherit):

inherit — модель текущей сессии (рекомендуется)
sonnet — баланс качества и скорости, резолвится в claude-sonnet-4-6
opus — сложный анализ, резолвится в claude-opus-4-8
haiku — быстрые задачи, резолвится в claude-haiku-4-5
Полный ID модели: claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5

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

tools (опциональное) — список доступных инструментов. Если не указано — агент наследует все инструменты сессии. Принцип наименьших привилегий: агент для анализа не должен иметь Write.

disallowedTools (опциональное) — инструменты, явно запрещённые агенту.

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

maxTurns (опциональное) — максимальное число ходов агента.

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

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

background (опциональное) — true запускает агента как фоновую задачу.

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

permissionMode (опциональное) — режим разрешений: default, acceptEdits, auto, dontAsk, bypassPermissions или plan.

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

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

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

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

Пример: 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).

Основные типы событий

По состоянию на середину 2026 года Claude Code поддерживает 27+ событий хуков. Вот полная актуальная таблица:

Событие	Когда срабатывает	Типичное применение
PreToolUse	Перед вызовом любого инструмента	Валидация, блокировка, модификация
PostToolUse	После завершения инструмента	Форматирование, логирование
PostToolUseFailure	Инструмент завершился с ошибкой	Обработка ошибок, retry-логика
PostToolBatch	После завершения группы параллельных инструментов	Агрегация результатов batch
UserPromptSubmit	Пользователь отправил сообщение	Добавление контекста, валидация
UserPromptExpansion	Промпт расширяется (через @ или !)	Модификация контекста до исполнения
Stop	Основной агент собирается остановиться	Проверка полноты выполнения
StopFailure	Агент остановился с ошибкой	Обработка аварийного останова
SubagentStop	Субагент собирается остановиться	Проверка качества результата
SubagentStart	Субагент запускается	Инициализация контекста агента
TeammateIdle	Участник команды (Agent Teams) завершил задачу	Координация в Agent Teams
TaskCreated	Создана задача в Dynamic Workflows	Отслеживание задач workflow
TaskCompleted	Задача в Dynamic Workflows завершена	Агрегация результатов workflow
SessionStart	Начало сессии Claude Code	Загрузка контекста, настройка окружения
Setup	После SessionStart, до первого сообщения	Инициализация инструментов и конфига
SessionEnd	Конец сессии	Очистка, логирование
InstructionsLoaded	CLAUDE.md файлы загружены	Аудит загруженных инструкций
ConfigChange	Изменение конфигурации в сессии	Реакция на смену настроек
CwdChanged	Рабочая директория изменена (`/cd`)	Перенастройка контекста проекта
PreCompact	Перед сжатием контекста	Сохранение критической информации
PostCompact	После сжатия контекста	Восстановление состояния
PermissionRequest	Claude запрашивает разрешение	Кастомная логика принятия решений
PermissionDenied	Разрешение отклонено	Логирование, альтернативные действия
Notification	Claude отправляет уведомление	Реакция на события
MessageDisplay	Вывод сообщения ассистента на экран	Редакция отображаемого текста (не влияет на транскрипт)
FileChanged	Изменение наблюдаемого файла	Автоперезагрузка конфигурации
WorktreeCreate	Создание git worktree	Настройка изолированного окружения
WorktreeRemove	Удаление git worktree	Очистка ресурсов
Elicitation	Claude запрашивает ввод у пользователя	Перехват и программная обработка запросов
ElicitationResult	Пользователь ответил на запрос	Пост-обработка ответа

Примечание: WorktreeCreate не поддерживает matcher и срабатывает на каждое событие. Любой ненулевой exit code прерывает создание worktree — это блокирующее событие.

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

Hooks конфигурируются в settings.json (user или project scope):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash /path/to/validate.sh",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

matcher — какие инструменты перехватывать:

"Write" — точное совпадение
"Read|Write|Edit" — несколько инструментов
"*" — все инструменты
"mcp__.*" — все MCP tools (regex)

type — тип handler’а: "command" (bash), "http" (HTTP POST, доступен с февраля 2026), "mcp_tool" (MCP-инструмент), "prompt" (LLM-оценка однократным промптом), "agent" (субагент с доступом к инструментам для сложной верификации).

timeout — лимит выполнения в секундах. По умолчанию: 60.

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

0 — успех; stdout парсится как JSON output (поля systemMessage, decision, hookSpecificOutput и др.). Для большинства событий stdout пишется в debug-лог; Claude видит его только в UserPromptSubmit, UserPromptExpansion, SessionStart.
2 — блокирующая ошибка: stdout игнорируется, stderr передаётся Claude как сообщение об ошибке. Блокирует действие в PreToolUse, UserPromptSubmit, PermissionRequest, Stop, SubagentStop, PreCompact, TaskCreated, TaskCompleted и др. Для WorktreeCreate любой ненулевой код прерывает создание worktree.
Любой другой код (1, 3 и т. д.) — не блокирующая ошибка; уведомление <hook name> hook error с первой строкой stderr, выполнение продолжается.

Hook Input

Все hooks получают JSON через stdin с общими полями:

{
  "session_id": "abc123",
  "cwd": "/project/path",
  "hook_event_name": "PreToolUse",
  "tool_name": "Write",
  "tool_input": { "file_path": "/path/to/file" }
}

Событие-специфичные поля: tool_name и tool_input для PreToolUse/PostToolUse, user_prompt для UserPromptSubmit, reason для Stop/SubagentStop.

Переменные окружения

В command hooks доступны:

$CLAUDE_PROJECT_DIR — корень проекта
$CLAUDE_ENV_FILE — (только SessionStart) файл для персистентных env-переменных
$CLAUDE_EFFORT — текущий уровень усилий: low, medium, high, xhigh, max

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

Хук запрещает Claude модифицировать определённые файлы:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/protect-files.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Скрипт protect-files.sh:

#!/bin/bash
set -euo pipefail

input=$(cat)
file_path=$(echo "$input" | jq -r '.tool_input.file_path')

# Защищённые паттерны
PROTECTED=(
  ".env"
  ".env.local"
  "credentials"
  "secrets"
  "*.key"
  "*.pem"
)

for pattern in "${PROTECTED[@]}"; do
  if [[ "$file_path" == *"$pattern"* ]]; then
    echo "{\"decision\": \"deny\", \"reason\": \"Protected file: $file_path\"}" >&2
    exit 2
  fi
done

# Запрет path traversal
if [[ "$file_path" == *".."* ]]; then
  echo "{\"decision\": \"deny\", \"reason\": \"Path traversal detected\"}" >&2
  exit 2
fi

exit 0

Пример 2: Auto-format после записи

Автоматическое форматирование файла после каждой записи:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/auto-format.sh",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

Скрипт auto-format.sh:

#!/bin/bash
set -euo pipefail

input=$(cat)
file_path=$(echo "$input" | jq -r '.tool_input.file_path')

# Определяем формат по расширению
case "$file_path" in
  *.ts|*.tsx|*.js|*.jsx)
    npx prettier --write "$file_path" 2>/dev/null
    ;;
  *.py)
    ruff format "$file_path" 2>/dev/null
    ;;
  *.rs)
    rustfmt "$file_path" 2>/dev/null
    ;;
  *.go)
    gofmt -w "$file_path" 2>/dev/null
    ;;
esac

exit 0

Пример 3: Загрузка контекста при старте сессии

SessionStart хук загружает проектный контекст и устанавливает переменные окружения:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/load-context.sh",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

Скрипт load-context.sh:

#!/bin/bash
set -euo pipefail

# Определяем тип проекта
if [ -f "package.json" ]; then
  echo "export PROJECT_TYPE=nodejs" >> "$CLAUDE_ENV_FILE"
elif [ -f "pubspec.yaml" ]; then
  echo "export PROJECT_TYPE=flutter" >> "$CLAUDE_ENV_FILE"
elif [ -f "pyproject.toml" ]; then
  echo "export PROJECT_TYPE=python" >> "$CLAUDE_ENV_FILE"
elif [ -f "Cargo.toml" ]; then
  echo "export PROJECT_TYPE=rust" >> "$CLAUDE_ENV_FILE"
fi

# Проверяем наличие незакоммиченных изменений
DIRTY=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')
if [ "$DIRTY" -gt 0 ]; then
  echo "export GIT_DIRTY=true" >> "$CLAUDE_ENV_FILE"
  echo "export GIT_DIRTY_COUNT=$DIRTY" >> "$CLAUDE_ENV_FILE"
fi

# Текущая ветка
BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "export GIT_BRANCH=$BRANCH" >> "$CLAUDE_ENV_FILE"

Пример 4: Проверка полноты выполнения (Stop hook)

Хук, который проверяет, выполнил ли Claude задачу полностью:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/check-completion.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# check-completion.sh
input=$(cat)
# Проверяем, запущены ли тесты, собран ли проект
# При необходимости возвращаем ненулевой код
exit 0

Параллельное выполнение

Все matching hooks для одного события выполняются параллельно:

Hooks не видят результаты друг друга
Порядок выполнения не детерминирован
Каждый hook должен быть независимым

Перезагрузка hooks

Hooks загружаются при старте сессии. Изменения в settings.json требуют перезапуска Claude Code. Для проверки загруженных hooks используй команду /hooks.

Примечание: файлы skills (SKILL.md) подхватываются без перезапуска — Claude Code отслеживает директории в реальном времени.

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

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

Типы memory

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

Файл	Расположение	Область
`CLAUDE.md`	Корень проекта	Проектные инструкции, доступны команде
`.claude/CLAUDE.md`	Внутри .claude	Альтернативное расположение
`CLAUDE.local.md`	Корень проекта	Персональные, gitignored
`~/.claude/CLAUDE.md`	Домашняя директория	Глобальные персональные

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 работает автоматически, но процессом можно управлять явно:

Коррекция — исправь Claude: “Нет, используй pnpm, не npm”. Он сохранит это в feedback и применит в следующей сессии.
Явное сохранение — “Запомни: в этом проекте все API-ответы оборачиваются в { data, error, meta }”. Claude создаст memory-файл.
Проверка — открой ~/.claude/projects/*/memory/MEMORY.md, удали устаревшие записи.
Миграция — если правило глобальное, перенеси его в ~/.claude/CLAUDE.md.

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

CLAUDE.md — основной механизм инструктирования Claude Code. Файл загружается при старте сессии и определяет поведение Claude в проекте.

Иерархия приоритетов

CLAUDE.md файлы существуют на четырёх уровнях (от высшего приоритета к низшему):

Уровень	Расположение	Кто использует
Managed policy	macOS: `/Library/Application Support/ClaudeCode/CLAUDE.md` Linux: `/etc/claude-code/CLAUDE.md`	IT/DevOps организации. Невозможно переопределить.
Project	`./CLAUDE.md` или `./.claude/CLAUDE.md`	Команда через git
User	`~/.claude/CLAUDE.md`	Персональные настройки для всех проектов
Local	`./CLAUDE.local.md`	Персональные для конкретного проекта, gitignored

Важная деталь: файлы конкатенируются, не переопределяют друг друга. При конфликте инструкций Claude ориентируется на более специфичный контекст.

.claude/rules/ с glob-паттернами

Директория .claude/rules/ хранит правила, которые применяются к конкретным файлам:

.claude/rules/
├── api-endpoints.md     # Правила для API файлов
├── database.md          # Правила для миграций и схем
└── tests.md             # Правила для тестов

Правила без paths frontmatter загружаются при старте. Правила с paths загружаются только когда Claude работает с соответствующими файлами:

---
paths:
  - "src/api/**/*.ts"
---

# API Development Rules

- All API endpoints must include input validation
- Use the standard error response format

Импорт через @path

CLAUDE.md поддерживает импорт других файлов:

@shared-rules.md
@RTK.md

Claude загружает содержимое указанных файлов и включает в инструкции. Удобно разбивать правила по темам и переиспользовать конфигурации между проектами.

Best practices для CLAUDE.md

Структура проектного CLAUDE.md:

# Project Name

## Overview
Краткое описание проекта: стек, архитектура, ключевые зависимости.

## Commands
Основные команды для разработки, тестирования, деплоя.

## Architecture
Ключевые архитектурные решения, которые Claude должен учитывать.

## Conventions
Стиль кода, именование, паттерны, анти-паттерны.

## Known Issues
Текущие ограничения, workarounds, tech debt.

Принципы:

Конкретность — “Используй pnpm, не npm” вместо “Используй правильный пакетный менеджер”.
Приоритизация — Помечай критичные правила: (CRITICAL).
Актуальность — Удаляй устаревшие инструкции. Лучше 20 актуальных правил, чем 100 неактуальных.
Контекст — Объясняй причину: “Используй edge functions вместо API routes, потому что проект на Cloudflare Pages” — Claude лучше понимает ограничения.
Примеры — Показывай правильный формат через примеры кода, не абстрактные описания.

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

Настоящая сила — в комбинации всех компонентов. 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. Приоритетные задачи на сегодня

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:

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

Ваша основная сессия остаётся отзывчивой: 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 до последних версий" \
  --max-turns 30 \
  --model claude-opus-4-8 \
  --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

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

1. Commit Message Validator (PreToolUse)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/validate-commit.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# validate-commit.sh
set -euo pipefail

input=$(cat)
command=$(echo "$input" | jq -r '.tool_input.command // empty')

# Проверяем только git commit
if [[ "$command" != *"git commit"* ]]; then
  exit 0
fi

# Проверяем наличие Conventional Commits
if echo "$command" | grep -q 'git commit.*-m'; then
  msg=$(echo "$command" | sed 's/.*-m ["\x27]//' | sed 's/["\x27].*//')

  # Conventional Commits pattern
  if ! echo "$msg" | grep -qE '^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?: .+'; then
    echo '{"systemMessage": "Commit message does not follow Conventional Commits format. Use: type(scope): description. Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert."}' >&2
    exit 2
  fi
fi

exit 0

2. Sensitive Data Guard (PreToolUse)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/sensitive-data-guard.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# sensitive-data-guard.sh
set -euo pipefail

input=$(cat)
file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty')
content=$(echo "$input" | jq -r '.tool_input.content // .tool_input.new_string // empty')

# Проверяем путь
BLOCKED_PATHS=(".env" ".env.local" ".env.production" "credentials" "secrets" ".key" ".pem" ".p12")
for pattern in "${BLOCKED_PATHS[@]}"; do
  if [[ "$file_path" == *"$pattern"* ]]; then
    echo "{\"hookSpecificOutput\": {\"permissionDecision\": \"deny\"}, \"systemMessage\": \"Blocked: writing to sensitive file $file_path\"}" >&2
    exit 2
  fi
done

# Проверяем контент на наличие секретов
if [ -n "$content" ]; then
  # AWS keys
  if echo "$content" | grep -qE 'AKIA[0-9A-Z]{16}'; then
    echo "{\"hookSpecificOutput\": {\"permissionDecision\": \"deny\"}, \"systemMessage\": \"Blocked: content contains AWS access key\"}" >&2
    exit 2
  fi

  # Private keys
  if echo "$content" | grep -qE 'BEGIN (RSA |EC |DSA )?PRIVATE KEY'; then
    echo "{\"hookSpecificOutput\": {\"permissionDecision\": \"deny\"}, \"systemMessage\": \"Blocked: content contains private key\"}" >&2
    exit 2
  fi

  # Generic API key patterns
  if echo "$content" | grep -qE '(api[_-]?key|api[_-]?secret|access[_-]?token)\s*[:=]\s*["\x27][a-zA-Z0-9]{20,}'; then
    echo "{\"systemMessage\": \"Warning: content may contain hardcoded API key. Consider using environment variables.\"}"
  fi
fi

exit 0

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

Рекомендуемая структура .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
    └── validate-commit.sh

Итого

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

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

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

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

Формат файла

YAML Frontmatter

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

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

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

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

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

Формат файла

Frontmatter поля

Пример: Security Scanner Agent

Пример: Test Writer Agent

Пример: Code Reviewer Agent

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

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

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

Основные типы событий

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

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

Hook Input

Переменные окружения

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

Пример 2: Auto-format после записи

Пример 3: Загрузка контекста при старте сессии

Пример 4: Проверка полноты выполнения (Stop hook)

Параллельное выполнение

Перезагрузка hooks

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

Типы memory

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

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

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

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

Иерархия приоритетов

.claude/rules/ с glob-паттернами

Импорт через @path

Best practices для CLAUDE.md

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

Skill вызывает Agent

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

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

Реальные workflow

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

Workflow 2: Automated PR Review

Workflow 3: Release Management

Workflow 4: Debugging Methodology

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

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

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

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

Доступность

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

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

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

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

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

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

1. /adr — Architecture Decision Record

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

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

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

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

2. Dependency Auditor

3. Performance Profiler

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

1. Commit Message Validator (PreToolUse)

2. Sensitive Data Guard (PreToolUse)

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

Итого

Как написать свой MCP сервер на Python: пошаговый туториал

MCP серверы: что это, зачем нужны и как подключить

Vibe Coding: гайд для инженеров и команд

AI Security Audit Checklist: 15 уязвимостей, которые Claude нашел в production-коде