Этот документ — стартовая точка для тех, кто только начинает работать с Claude Code и AI-инструментами для разработки. Здесь собраны рекомендации и паттерны, которые в нашем опыте экономят время и улучшают результат. Это не догма — берите то, что подходит под ваши задачи, остальное игнорируйте.

Структура: от базы к продвинутым вещам. Можно читать по порядку, можно прыгать в нужный тир.

Tier 1 — Первый час. Минимум чтобы начать работать осмысленно.
Tier 2 — Первая неделя. Скиллы, команды, плагины, базовые рабочие паттерны.
Tier 3 — Продвинутый юзер. Саб-агенты, смоук-тесты, мобильность.
Tier 4 — Автоматизация. Хуки, cron, удалённая установка, тонкие настройки.

Tier 1 — Первый час

Минимальный набор чтобы начать работать с Claude Code осмысленно. Если у вас час до первой задачи — прочитайте только этот тир.

TL;DR

Ресёрч → собрать контекст (можно через саб-агентов, MCP, скиллы).
План → обсудить подход, зафиксировать шаги (Opus в Plan Mode). Большие задачи стоит сразу планировать под параллельных саб-агентов.
Реализация → Sonnet делает по плану, Opus подключается на сложных моментах. Независимые куски можно отдать параллельно саб-агентам — заметно быстрее.
Тесты → прогон после каждой значимой задачи, зелёные тесты = критерий «готово».
Ревью → сам себя ревьюит + кросс-модельное ревью на серьёзных изменениях.

Между задачами полезно вызывать /clear вместо /compact — на длинной дистанции это заметно влияет на качество ответов и стоимость токенов.

Основной flow

1. Ресёрч и обсуждение

Перед тем как писать код — даём модели вводные: что хотим сделать, зачем, какие ограничения. Просим собрать контекст по проекту и задаче.

Что помогает на этом шаге:

Саб-агенты — параллельный поиск по кодбазе.
MCP-серверы — например serena для семантической навигации по коду, context7 для актуальной документации библиотек.
Skills и Commands — готовые рецепты под типовые задачи (см. Tier 2).

Хорошее правило: чем точнее front-load контекста в первом промпте (намерение, ограничения, критерии готовности, пути файлов), тем меньше потом мусора в диалоге.

2. Составление плана

Команды:

/model opusplan — Opus в Plan Mode, Sonnet в имплементации (рекомендуемый дефолт).
Shift+Tab — переключение режимов, включая Plan Mode для текущего сообщения.
/advisor — назначить «советника» для текущей модели. Например, основная Sonnet, но при сомнениях он сам зовёт Opus.

Мультиагентное планирование. Если задача большая или состоит из независимых частей — стоит сразу заложить в план разбивку под параллельные саб-агенты. Главный агент держит общий план и контекст, саб-агенты параллельно ресёрчат/проектируют свои куски. Сильно ускоряет начальный этап на крупных фичах.

Когда план обычно не нужен: мелкие правки, ренеймы, добавить лог-строку, поправить регулярку. План тут чаще оверкилл.

Когда план обычно окупается: многофайловые рефакторы, новые фичи, архитектурные изменения, всё что трогает auth/payments/data. Решать вам — здравый смысл важнее правил.

3. Реализация

После апрува плана модель начинает выполнять шаги. Важные моменты:

Между шагами модель сообщает короткий статус.
Если что-то ломается — стоп, разбор, не продолжать «по плану» с поломанной базой.
Тесты — отдельной задачей либо параллельно с кодом, либо после. Чистый TDD (тест → код → рефактор) держится с трудом и часто не нужен — пишите тесты так, как принято в команде.

Мультиагентная имплементация. Если шаги плана независимы (разные модули, разные фичи, разные слои) — попросите Клода запустить саб-агентов параллельно. Текстом, обычным промптом: «раздели этот план на независимые куски и запусти параллельных саб-агентов на каждый». Дальше Клод сам подключает нужный инструмент — руками вызывать ничего не надо. Каждый саб-агент работает в изолированном контексте, главный собирает результат. Хороший выигрыш по времени на крупных задачах. Если установлен скилл superpowers:dispatching-parallel-agents — Клод подхватит его сам, либо позовите явно: /superpowers:dispatching-parallel-agents. Для физической изоляции работы — связка с worktrees (Tier 2).

4. Тесты

Просим модель запустить тесты после задачи. Зелёные = «готово». Красные = чиним до зелёного, не «завтра разберёмся».

Можно автоматизировать в CLAUDE.md на уровне проекта: «после любых изменений в src/ запусти npm test».

5. Ревью

Два уровня:

Самообзор — просим модель пройтись по своему диффу, поискать edge cases, проблемы безопасности, неудачные решения.
Кросс-модельное ревью — другая модель ловит другие блайнд-споты. Например, основной flow на Sonnet → финальный обзор на Opus (/model opus). Для критичного кода (auth, платежи, обработка данных) — стэкуйте оба ревью.

Стратегия моделей

Для планирования — Opus, для реализации — Sonnet. Opus умнее на абстракциях, но медленнее и дороже. Sonnet быстро и дёшево пилит механическую работу.

Шпаргалка:

Ситуация	Модель
Дефолт сессии	`/model opusplan` (Opus планирует, Sonnet делает)
Имплементация по плану	Sonnet
Сложный дебаг / архитектура	`/model opus`
Финальный обзор перед коммитом	`/model opus`, потом обратно

Effort levels:

xhigh — Opus 4.7 на сложных задачах (планирование, архитектура, дебаг гнилых багов).
high — стандартный режим, баланс качества и скорости.
medium — рутина, быстрые итерации, мелкие правки. Для большинства имплементационных задач хватает.
Просьба «отвечай прямо, не переусложняй» — когда модель уходит в overthinking на простой задаче.

Совет: держать Opus всю сессию по умолчанию обычно не окупается — Sonnet справляется с механической работой не хуже, при этом быстрее и дешевле. Опус подключайте точечно на сложных моментах.

Лимиты: 5-часовые окна и недельная квота

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

5-часовые сессионные окна

Окно стартует с первого запроса и длится ровно 5 часов.
В пределах окна тратится квота на сообщения/токены — расходуется по моделям (Opus тратит быстрее Sonnet).
Когда окно истекает — счётчик внутри него сбрасывается, начинается новое окно с следующего запроса.
Окна могут перекрываться: пока одно ещё активно, можно начать второе. Лимит считается по сумме активных окон.

Практически: интенсивная работа на Opus 4-5 часов подряд → внезапное упирание в потолок. На Sonnet окна расходуются заметно медленнее.

Недельная квота

Над сессионными окнами — общий недельный лимит.
Считается как rolling 7-дневное окно — расход «утекает» по мере того, как старые запросы выпадают за хвост в 7 дней.
Если упёрлись в недельный — никакая модель не работает, пока расход не «сольётся» по мере выпадания старых запросов.
Опус 4.7 расходует недельную квоту в разы быстрее Sonnet — это главный аргумент за /model opusplan вместо /model opus.

Как мониторить — статус-лайн под инпутом

Можно настроить статус-лайн под полем ввода — будет всегда показывать остаток лимитов, активную модель, контекст. Удобно для контроля без /cost каждый раз.

Базовая настройка:

/statusline — конфигурирует встроенный статус-лайн через интерактивный flow.
Кастомный — скрипт в settings.json под ключом statusLine. Получает на stdin JSON с состоянием сессии, выводит строку.

Что обычно показывают:

Остаток сессионного окна (% / время до сброса).
Остаток недельной квоты.
Активную модель и effort level.
Текущий контекст (сколько токенов в диалоге).
Текущий проект / директорию / git branch.

Пример скрипта ~/.claude/statusline.sh:

#!/bin/bash
read -r INPUT
MODEL=$(echo "$INPUT" | jq -r '.model.display_name')
DIR=$(echo "$INPUT" | jq -r '.workspace.current_dir | split("/") | last')
echo "[$MODEL] $DIR"

Прописать в ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

Для квот есть готовые скрипты в комьюнити (поищите claude-code statusline limits) — вытаскивают остаток из API/локального состояния.

Главное: иметь индикатор лимитов перед глазами полезно. Без него легко в середине дня обнаружить что недельная квота кончилась.

Контекст-гигиена

/clear между задачами, а не /compact. Самый недооценённый рычаг.
/compact — только если задача не закончена, но контекст забивается.
Ссылайтесь на файлы по пути (src/auth.ts), не вставляйте содержимое.
@file — только когда реально нужен полный файл со всей цепочкой CLAUDE.md.

Project `CLAUDE.md` — фундамент работы в проекте

Один из самых полезных файлов проекта для AI-flow. Без него модель пишет «в среднем по индустрии», а не как ваша команда. Если результаты модели сильно отличаются по стилю от существующего кода — обычно дело именно в отсутствии CLAUDE.md или его бедности.

Иерархия `CLAUDE.md`

Claude Code читает CLAUDE.md каскадом:

~/.claude/CLAUDE.md — глобальные правила (стратегия моделей, общий flow).
<project-root>/CLAUDE.md — правила проекта (стиль, команды, архитектура).
<subdir>/CLAUDE.md — локальные правила для подпроекта/модуля (если монорепо или фронт+бэк в одной репе).

Чем глубже — тем приоритетнее. Локальный CLAUDE.md подмодуля переопределяет проектный.

Что стоит сделать на старте проекта

Дать Клоду изучить проект. Команда /init делает первичный обзор и генерирует базовый CLAUDE.md. Удобно запускать при первом подключении к репозиторию.
Скормить стайлгайды. Если у команды есть документы про стиль кода, naming conventions, паттерны обработки ошибок, архитектурные принципы — можно попросить модель прочитать их и интегрировать в CLAUDE.md.
Показать примеры. Укажите 2-3 эталонных файла («так пишем сервисы», «так пишем тесты», «так оформляем компоненты»). Модель будет копировать стиль оттуда.
Зафиксировать манеру. Tabs vs spaces, кавычки, semicolons, naming (camelCase/snake_case), порядок импортов, длина строки, формат JSDoc/docstring — всё, что отличает код вашей команды от чужого.

Без этого модель угадывает, и угадывает чаще плохо, чем хорошо. Время на CLAUDE.md обычно окупается уже на первой неделе работы.

Что класть в `CLAUDE.md`

Стиль кода и линтер-правила (или ссылка на конфиг линтера и правило «следовать ему»).
Шаблон обработки ошибок (свои Error-классы? Result-тип? throw?).
Команды для тестов, билда, линта, запуска dev-сервера.
Архитектурные инварианты («сервисный слой не знает про HTTP», «доменные сущности без зависимостей от инфраструктуры»).
Особенности окружения (какие env-переменные нужны, где брать секреты).
Соглашения по коммитам и веткам.
Стек: версии Node/Python/etc, основные библиотеки, чем НЕ пользуемся.
Примеры файлов-эталонов с путями.

Что НЕ класть

Историю изменений (есть git).
Секреты, ключи, пароли.
Описания того, что и так очевидно из кода.
Ephemeral state (текущая задача, in-progress работа) — для этого есть TodoWrite.

Базовые CLI-фишки

Минимум что стоит знать про сам CLI с первого дня.

Сессии: `--resume`, `--continue`, `/rename`

Claude Code хранит историю сессий. Каждая сессия = отдельный диалог с контекстом.

claude --resume — открыть список прошлых сессий и продолжить любую. Удобно когда задача растянулась на несколько дней или понадобилось вернуться к старому диалогу.
claude --continue — сразу продолжить последнюю сессию без выбора.
/rename <имя> — переименовать текущую сессию. Удобно называть по коду задачи (PROJ-1234, auth-refactor, bug-login-redirect) — иначе список превращается в кашу из дефолтных названий и в нём тяжело ориентироваться.

Паттерн:

Создал ветку под задачу → сразу в Claude Code → /rename PROJ-1234.
Через день — claude --resume → находишь по коду задачи мгновенно.

Скриншоты в инпут

Картинки не нужно сохранять в файлы и указывать путь. Кидаешь напрямую:

Drag & drop — перетащить файл/скриншот мышкой в окно терминала.
Ctrl+V (или Cmd+V на Mac) — вставить скриншот из буфера.

Работает для UI-багов, мокапов дизайна, скриншотов ошибок, диаграмм. Модель видит изображение и комментирует напрямую.

Если Claude завис

Бывает: модель просто молчит, ничего не делает, не отвечает. Сетевая ошибка, баг рантайма, зависание стрима — причины разные.

Что делать:

Escape — прерывает текущий ответ.
Напиши «продолжай» / «continue» / «давай дальше».
Если снова завис — снова Escape, снова просьба продолжить.
Иногда нужно повторить 2-3 раза пока модель не поедет.

Если совсем намертво — /clear и пересобрать промпт заново. Контекст потеряется, но это редкий сценарий.

Tier 2 — Первая неделя

Скиллы, команды, плагины, MCP, полезные паттерны. Тут читатель из Tier 1 разворачивается в полноценного юзера.

Skills, Commands, MCP — три механизма расширения

Прежде чем переходить к плагинам, важно понять три способа как Claude Code расширяется.

Skills

Скиллы — переиспользуемые рецепты под конкретные задачи. По сути это инструкции для Клода, которые он подхватывает в нужный момент.

Как использовать (3 способа):

Слэш-командой — пишете в инпут /<имя-скилла>, например /dev:code-review. Прямой вызов конкретного скилла.
Обычным текстом — пишете «прогони code review этого диффа» / «сделай security-аудит» / «отрефакторь функцию X». Клод сам подбирает подходящий скилл из списка установленных и применяет его.
Автоматически — некоторые скиллы помечены как «использовать всегда когда» и Клод подключает их сам в нужном контексте, без явной просьбы.

Полезные категории:

dev:* — code-review, debug-error, refactor-code, explain-code.
test:* — write-tests, test-coverage, e2e-setup.
security:* — security-audit, dependency-audit.
docs:* — generate-api-documentation, create-architecture-documentation.
setup:* — setup-linting, setup-formatting, migrate-to-typescript.

Полный список установленных скиллов появляется в системных подсказках сессии. Если хочется конкретный — сначала проверьте что он в списке (имена не угадываются).

Commands

Кастомные слэш-команды живут в ~/.claude/commands/ (глобально) или .claude/commands/ (проектно). Это просто markdown-файлы с промптами под типовые задачи.

Примеры из коробки:

/init — инициализирует CLAUDE.md для проекта.
/review — ревью PR.
/security-review — security-проход по текущему диффу.

MCP Servers

MCP (Model Context Protocol) — стандарт подключения внешних инструментов к модели. Сервера дают доступ к данным и действиям за пределами кода.

Базовый набор:

serena — семантическая навигация по коду.
context7 — документация библиотек.
chrome-devtools / playwright — управление браузером для тестов и скрейпинга.

Управление:

/mcp — список подключённых серверов и их статус.
Конфиг — ~/.claude/mcp.json или .claude/mcp.json в проекте.

Полезные плагины

Эти инструменты построены поверх скиллов/команд/MCP, описанных выше.

Caveman

Сжимает вывод модели ~65% на механической прозе. Хорош для длинных имплементационных сессий.

Использовать: статус-апдейты при имплементации, коммит-сообщения (/caveman-commit), быстрые лукапы.
Не использовать: брейншторм, написание планов, ревью, дебаг — там нужна полнота, а не краткость.
Включение: /caveman. Уровни: lite, full, ultra.
Выключение: stop caveman или normal mode.

Plannotator

Интерактивный UI для аннотирования планов и ревью кода. Команды:

/plannotator-review — ревью текущих изменений или PR.
/plannotator-annotate — аннотация markdown-плана.

Superpowers

Набор скиллов для структурированного flow. Если хочется дисциплины в работе с моделью — стоит попробовать:

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

Serena

LSP-бэкап для семантической навигации по коду. Заявляется что на больших проектах может ощутимо экономить токены (до 70% по словам авторов) — реальный выигрыш зависит от проекта и стиля работы. Стоит протестировать на своём кейсе и сравнить.

Хорошо подходит для:

Найти функцию/класс → find_symbol (вместо чтения всего файла).
Найти где вызывается → find_referencing_symbols (вместо grep + чтение).
Редактирование конкретного метода → insert_after_symbol / replace_symbol_body.
Обзор незнакомой кодбазы → get_symbols_overview.

Не сильно полезен для: configs, markdown, YAML, JSON — там нет символов, обычные тулзы быстрее.

На новом проекте Serena умеет провести онбординг — это её собственная процедура: пройтись по кодбазе, построить семантический индекс символов и сложить заметки про архитектуру в .serena/memories/. Запускается просьбой текстом: «прогони Serena onboarding на этом проекте» (Клод сам зовёт mcp__serena__onboarding). Стоит токенов на старте, но дальше Serena работает заметно быстрее и точнее — окупается через пару сессий.

Context7

Документация библиотек/фреймворков/SDK прямо в контекст модели. Решает реальную проблему: данные обучения модели устаревают, а угаданный API ломает код.

Зачем нужен:

Структурированная выдача под конкретный вопрос — не нужно скармливать модели целые страницы доков.
Быстрее чем WebSearch + WebFetch + парсинг — один вызов вместо трёх.
Покрывает большинство популярных библиотек (React, Next.js, Prisma, Tailwind, Django и т.п.).
В 90% случаев возвращает корректный актуальный ответ.

Когда не хватает:

Свежий релиз/беты — индекс может отставать.
Узкая нишевая либа — может не быть в индексе.
Вопрос про конкретный edge case или баг — лучше идти в issues GitHub.
Расхождение между мажорными версиями — уточняйте версию в запросе.

Практика:

Дефолт — Context7 для всех вопросов про библиотеки. Дёшево, быстро, обычно верно.
Сомнения — попросите модель сверить с первоисточником через WebFetch (оф. сайт, GitHub, changelog).
Критичный код — не доверяйте слепо ни одному источнику, проверяйте на минимальном примере.

Итого: Context7 = удобный быстрый слой. WebSearch/WebFetch = резервный слой когда Context7 не справляется или нужна сверка.

`/add-dir` — несколько папок в одной сессии

По умолчанию Claude Code видит только директорию из которой запущен. Если нужно работать с несколькими (фронт + бэк, либа + потребитель, монорепо без общего корня) — добавляешь их через /add-dir:

/add-dir ../backend
/add-dir ../shared-lib

Можно также передать при старте: claude --add-dir ../backend ../shared-lib.

Удобный паттерн — workspace-папка с несколькими репо:

~/projects/myapp/
├── frontend/        ← репо 1
├── backend/         ← репо 2
├── shared-lib/      ← репо 3
└── infra/           ← репо 4

Запускаешь claude из ~/projects/myapp/ (или из любого подпроекта + /add-dir остальных). Клод видит все репо одновременно — не надо переключать сессии или пересобирать контекст когда задача трогает фронт и бэк сразу.

Полезные сценарии:

Фича где нужно поправить API в бэке + дёрнуть его из фронта — одна сессия видит обе стороны.
Сквозной рефакторинг типа в shared-либе с обновлением всех потребителей.
E2E-тесты которые требуют контекста и UI, и сервера.

Аудиты кодбазы — рекомендуемое первое упражнение

Хороший способ вкатиться в Claude Code на реальном проекте — прогнать аудит существующего кода. Низкий риск, высокая польза, сразу видны конкретные находки. Если только начинаете — попробуйте с этого.

Что искать через аудит:

Security — SQL-инъекции, XSS, CSRF, утечки секретов, небезопасное использование eval, отсутствие валидации на входах. Скиллы: security:security-audit, security:dependency-audit, security-review.
Dead code — функции/классы/файлы без вызовов, неиспользуемые импорты, закомментированный код. Скилл: dev:remove-dead-code.
Архитектурные нарушения — слой A знает про слой B хотя не должен, циркулярные зависимости, размытые границы модулей. Скиллы: team:architecture-review, rust:audit-clean-arch (для Rust), rust:audit-layer-boundaries.
Технический долг — TODO/FIXME без owner, антипаттерны, дублирование, magic numbers, длинные функции, низкая когезия. Скилл: dev:code-review.
Тесты — что не покрыто, флейки, моки которых не должно быть, отсутствие edge case проверок. Скилл: test:test-coverage.
Производительность — N+1 запросы, отсутствие индексов, синхронные операции в hot path, ненужные ре-рендеры. Скилл: performance:performance-audit.
Зависимости — устаревшие пакеты, известные CVE, дублирующиеся либы, ненужные транзитивы. Скилл: security:dependency-audit.
Документация — расхождение README с реальностью, отсутствие onboarding, мёртвые ссылки.

Практика для новичков. Возьмите проект (свой или рабочий) и прогоните 1-2 аудита. Например:

claude → «Сделай security-аудит этого проекта. Найди реальные проблемы, не теоретические. Приоритизируй по серьёзности.»
Получите список находок → разберите каждую: реальная или ложное срабатывание?
Поправьте 1-2 настоящих → откройте PR.

За пару часов получите понимание инструмента + улучшение проекта. Хороший паттерн знакомства с Claude Code на боевом материале.

Полезные команды и скиллы:

/security-review — security-проход по текущему диффу.
/review — общее ревью PR.
dev:code-review — комплексное ревью качества.
dev:directory-deep-dive — глубокий разбор директории.
team:architecture-review — архитектурное ревью.

⚠️ Аудиты дают список гипотез, не диагнозов. Каждую находку проверяйте руками перед фиксом. Особенно security — false positives там обычное дело.

Worktrees — параллельные ветки без конфликтов

Git worktree = несколько рабочих копий одного репозитория, каждая на своей ветке. Идеально для параллельной работы Claude Code над несколькими задачами без переключения веток в основной копии.

Зачем

Запустить две Claude-сессии параллельно над разными фичами.
Не сбивать состояние IDE, dev-сервера, кеша билда при переключении задач.
Изолировать рискованные эксперименты от основной копии.

Где размещать

Рекомендация: worktrees лучше держать сиблинг-директориями рядом с основной копией. Если вложить worktree внутрь репозитория — обычно ломаются IDE-вотчеры, рекурсивные тулзы и билд-контексты. Поэтому проще класть рядом.

~/projects/foo/
├── bar.dev/                    ← основная копия, ветка main
└── bar.dev-worktrees/
    ├── feat-x/                 ← worktree, ветка feat/x
    ├── PROJ-1234/              ← worktree, ветка PROJ-1234
    └── hotfix-login/           ← worktree, ветка hotfix/login

Паттерн пути: <repo>-worktrees/<branch> (слэши в имени ветки заменить на дефисы).

Команды

git worktree add ../bar.dev-worktrees/feat-x feat/x       # создать
git worktree list                                          # список всех worktrees
git worktree remove ../bar.dev-worktrees/feat-x            # удалить (после merge)

Flow с Claude Code

Главное: руками команды вбивать не обязательно. Просто скажите Клоду в текущей сессии: «создай worktree для ветки PROJ-1234 рядом с проектом» — он сам выполнит git worktree add по правильному пути (сиблинг, не вложенный). После merge — «удали worktree для PROJ-1234».

Если хочется руками:

git worktree add ../<repo>-worktrees/<branch> <branch> → создаёшь worktree.
cd ../<repo>-worktrees/<branch> → переходишь в неё.
claude → стартуешь сессию.
/rename <код-задачи> → именуешь сессию.
После merge → git worktree remove ../<repo>-worktrees/<branch> → чистишь.

Если установлен скилл superpowers:using-git-worktrees — Клод подхватит его при просьбе про worktrees, либо позовите явно: /superpowers:using-git-worktrees.

Когда worktrees не нужны

Один человек, одна задача за раз — оверкилл, обычная ветка достаточна.
Мелкие правки в той же области кода — переключение ветки быстрее.

Tier 3 — Продвинутый юзер

Параллелизация, end-to-end тестирование руками Клода, доки в репо, мобильная работа.

Sub-agents

Саб-агенты дают параллельность и защищают основной контекст от мусора.

Как запустить. Прямой команды для саб-агентов нет — пишете обычным текстом: «запусти параллельно двух Explore-агентов на поиск X и Y», «отдай ресёрч документации саб-агенту», «делегируй имплементацию модуля A саб-агенту, пока ты делаешь модуль B». Дальше Клод сам подключает нужный механизм с нужным типом агента и промптом — со стороны юзера это выглядит как простая просьба.

Когда использовать:

Параллельный поиск/ресёрч по нескольким направлениям.
Длинные задачи с большим выводом, который не нужно тащить в основной контекст.
Независимая ветка работы пока вы делаете что-то ещё.

Доступные типы:

Explore — быстрый readonly-поиск по коду.
general-purpose — открытые вопросы и многошаговые задачи.
Plan — построение архитектурных планов.
claude-code-guide — вопросы про сам Claude Code и Anthropic SDK.

Что дать Клоду чтобы делегирование вышло хорошим:

Промпт саб-агенту собирает сам Клод — юзер с агентом напрямую не общается. Но саб-агент не видит вашу историю диалога, поэтому Клоду нужно вложить туда контекст. Чем точнее ваша исходная просьба — тем лучше промпт он соберёт. Полезно явно указать:

Цель и зачем — агент должен понимать ради чего он копает.
Что уже выяснено — чтобы не делал работу дважды.
Тип задачи — «только ресёрч» или «код тоже писать».
Формат отчёта — например «короткий отчёт, не более 200 слов» (иначе саб-агент может выдать стену текста, которая забьёт ваш контекст).

Можно прямо так и сказать: «делегируй саб-агенту: цель X, уже знаем Y, нужен только ресёрч, отчёт до 200 слов».

Фоновые процессы — dev-серверы, билды, watch-режим

Клод умеет запускать команды в фоне и параллельно продолжать работу. Полезно когда нужно держать процесс живым — dev-сервер, watch-билд, docker-compose, тесты в watch-режиме.

Зачем:

Запустить npm run dev → Клод вернёт управление сразу, не ждёт пока Ctrl+C. Аппка крутится — можно идти тыкать руками в браузере.
Параллельно: пока вы кликаете UI, Клод дальше пишет код по плану. Дев-сервер сам перезагружается на изменения.
Запустить долгий билд/тест → Клод не блокируется, делает другое в это время → проверяет результат когда команда закончит.

Как использовать:

Просто текстом: «запусти npm run dev в фоне», «подними docker-compose в фоне и продолжи задачу».
Клод дальше может читать stdout/stderr запущенного процесса в любой момент — увидит ошибки, прогресс, логи.
Остановить: «убей фоновый процесс с dev-сервером» или Клод сам остановит когда задача закончится.

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

Ручной смоук-тест. Клод поднимает бэк + фронт в фоне → вы в браузере тыкаете новую фичу → Клод параллельно мониторит логи и чинит баги по ходу.
TDD-цикл. npm test --watch в фоне → Клод правит код → тесты сами перезапускаются → Клод читает результат.
Длинный билд/деплой. Запустил → ушёл писать другое → вернулся к результату когда готово.

Подводные камни:

Фоновые процессы привязаны к сессии Клода — закроется CLI, упадут процессы. Для долгоживущих сервисов лучше tmux / systemd.
Если процесс пишет много логов — Клод тратит токены на их чтение. Для шумных процессов имеет смысл редиректить вывод в файл (>> dev.log) и читать выборочно.

Смоук-тестирование через Клода

После имплементации полезно дать Клоду самому проверить что всё работает end-to-end, а не только что юнит-тесты зелёные. Особенно для фич где есть UI + бэк.

Базовый паттерн:

Подключить репо через /add-dir (или работать в workspace-папке с фронтом и бэком).
Поднять стек: попросить Клода запустить docker-compose up, npm run dev, миграции и т.п.
Дать задание: «открой UI, прокликай новую фичу, проверь что флоу X работает, посмотри логи бэка на ошибки».
Клод через chrome-devtools / playwright MCP открывает браузер, кликает, читает консоль и сетевые запросы, смотрит логи сервера.
Если находит баг — чинит, перезапускает, проверяет снова.

Что Клод реально может:

Кликать кнопки, заполнять формы, ходить по страницам.
Делать скриншоты на каждом шаге → видишь что именно увидела модель.
Читать console.error, network errors, stack traces.
Параллельно мониторить логи бэка на ошибки/медленные запросы.
Воспроизводить баг по шагам и сразу его чинить.

Когда особенно полезно:

Новая фича на стыке фронт+бэк — юнит-тестов мало, нужно увидеть в работе.
Регрессия после рефакторинга — пройти основные пользовательские сценарии.
Баг которого не воспроизводит автоматический тест — Клод тыкает и ищет.

Подводные камни:

Долго (минуты на сценарий) и токеноёмко.
Не заменяет нормальные E2E-тесты — это ad-hoc проверка.
Иногда модель видит «нормальный» UI там где для человека баг очевиден. Скриншоты помогают перепроверить.

Доки и саммари сессий в репо

Claude Code хорошо генерирует, но плохо помнит между сессиями (контекст начинается с нуля при /clear или новом запуске). Решение — оставлять следы прямо в репозитории.

Что стоит коммитить:

Архитектурные решения (ADR) — docs/adr/0001-why-postgres.md. Почему выбрали то-то, что рассматривали, что отвергли.
Саммари больших задач — после крупной фичи попросить Клода написать docs/decisions/2026-05-feature-x.md: что сделано, что осталось, почему так. Затем закоммитить.
Гайды по проекту — docs/onboarding.md, docs/runbook.md, docs/troubleshooting.md. Можно сгенерить через Клода, потом руками отредактировать.
Логи дебага гнилых багов — что пробовали, что не сработало, что в итоге помогло.
API-описания через docs:doc-api, диаграммы архитектуры через docs:create-architecture-documentation.

Зачем:

Будущая Claude-сессия читает эти доки и понимает проект быстрее → меньше токенов на ресёрч, лучше решения.
Новый человек в команде — то же самое.
Через полгода сами не помните почему сделали именно так — открыли ADR, поняли.

Паттерн «закрытие задачи»:

Имплементация готова, тесты зелёные.
«Клод, напиши краткое саммари того что мы сделали в этой сессии: проблема, решение, ключевые решения, что осталось». В docs/sessions/<task-code>.md.
Закоммитить вместе с фичей. Можно автоматизировать через хук Stop или git pre-commit.

Опасность: если генерить такие доки на каждое мелкое изменение — docs/ превращается в свалку. Стоит писать саммари только для содержательных задач, остальное — в commit messages и PR descriptions.

Бонус-паттерн: Клод как секретарь. Хороший приём — складывать продумывание задач в docs/tasks/<task-code>.md ещё до начала имплементации. Например:

Прилетела задача — садишься с Клодом и брейнштормишь: что делать, какие подходы, риски, открытые вопросы. Ответы складываются в docs/tasks/PROJ-1234.md.
Через день/неделю возвращаешься — открываешь файл, продолжаешь с того же места. Контекст сессии потерян, но мысли на месте.
Можно переосмыслить, дописать, поменять подход. Файл живёт пока задача актуальна.
После имплементации — либо удаляешь, либо превращаешь в ADR/саммари.

Эффект: Клод работает как секретарь — оформляет ваши размышления в структурированный документ, который потом удобно читать. Особенно полезно когда задач много и нужно держать в голове несколько одновременно.

`/remote-control` — вайбкодинг на ходу

Дистанционное управление локальной Claude Code сессией с телефона/планшета/любого браузера. Сессия крутится на рабочей машине (со всеми файлами проекта, git, MCP, инструментами), а ты пишешь промпты с телефона.

Зачем:

Утро в кофейне → запустил длинную задачу с телефона → пришёл домой, всё уже сделано.
В метро вспомнил баг → открыл сессию → попросил Клода починить → к моменту прихода на работу PR готов.
Лежишь на диване — фичу хочется, к компу подходить лень. Это и есть вайбкодинг на ходу.
Длинный билд/тест на удалённой машине → запустил команду → ушёл → проверил с телефона как закончилось.

Как включить:

В сессии Claude Code → /remote-control → следуйте инструкциям (генерится ссылка/код для парного устройства).
Открой ссылку с телефона → сессия доступна через браузер.
Пиши промпты — выполняются на твоей машине в реальном проекте.

Подводные камни:

Машина должна быть включена и онлайн.
Если включён --dangerously-skip-permissions — управляешь полным доступом к машине с телефона. Подумай дважды.
Сетевые лаги бывают. Не для real-time дебага.
Конфиг и токены парных устройств хранятся в ~/.claude/ — точное имя файла зависит от версии CLI, лучше править через сам /remote-control, а не руками.

Tier 4 — Автоматизация и тонкие настройки

Headless-режим, хуки, уведомления, channels, удалённая установка, permissions. Эта часть про то, как встроить Claude Code в свою инфру и сделать рутину автоматической.

Headless / inline режим — cron, CI, скрипты

Claude можно запускать одним промптом без интерактивной сессии. Удобно для автоматизации.

Базовый формат:

claude -p "промпт текстом"

Запустит модель, выполнит промпт, выведет результат, завершится.

Полезные опции:

-p / --print — non-interactive режим, вывод в stdout.
--output-format json — структурированный вывод для скриптов.
--dangerously-skip-permissions — без интерактива промпты не сработают, нужен этот флаг или пред-настроенный allow-list.

Сценарии автоматизации:

Cron-задачи на машине: ежедневный аудит безопасности, проверка устаревших зависимостей, генерация changelog.

0 9 * * 1 cd ~/projects/foo && claude -p "Прогони /security-review на изменениях за неделю и создай отчёт в audit.md" --dangerously-skip-permissions

CI/CD: автогенерация PR-описаний, авто-ревью диффа, создание тестов под новый код.
Watch-режим: реагировать на изменения файлов через fswatch / entr + claude -p.
Pre-commit / pre-push хуки: прогон ревью или генерация коммит-сообщения автоматически.

Встроенный планировщик:

/schedule — создание/управление cron-задачами Claude Code через интерактивный flow (либо просто попросите Клода: «настрой cron на еженедельный security-review»).
/loop — повторять промпт с интервалом, например /loop 5m /security-review.

Осторожно:

Headless с --dangerously-skip-permissions = полный доступ к машине без надзора. deny-правила в settings.json обязательны (см. ниже про permissions).
Логируй вывод (>> claude.log) — иначе непонятно что происходит.
Не клади промпты с секретами в shell-историю/cron-конфиг.

Хуки и уведомления

Хуки = шелл-команды, которые Claude Code запускает в ответ на события. Настраиваются в ~/.claude/settings.json (глобально) или <project>/.claude/settings.json (проектно). Это основа автоматизации поверх Claude Code.

Доступные события

SessionStart — старт сессии (можно подгрузить контекст, env-переменные).
UserPromptSubmit — после отправки промпта пользователем (можно дописать дополнительный контекст).
PreToolUse / PostToolUse — перед/после вызова инструмента (валидация, логирование, авто-форматирование после Edit).
Stop — модель закончила ответ (уведомления, звук).
Notification — модель просит пермишен или ввод.

Зачем используют

Автоматический prettier / eslint --fix после каждого Edit/Write.
Логирование команд в файл для аудита.
Запрет на запуск опасных команд через PreToolUse.
Уведомления когда модель закончила длинную задачу.
Подгрузка проектного контекста на старт сессии.

Если не хочется руками править JSON — попросите Клода настроить хук текстом («настрой Stop-хук чтобы играл звук Glass.aiff»). Можно явно позвать /update-config, если скилл установлен — он проводит через интерактивную настройку settings.json.

Звуковые и системные уведомления

Длинная задача → ушёл за кофе → как узнать что Клод закончил? Через хук Stop + системное уведомление или звук.

macOS — звук:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "afplay /System/Library/Sounds/Glass.aiff" }
        ]
      }
    ]
  }
}

macOS — системное уведомление:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "osascript -e 'display notification \"Готово\" with title \"Claude Code\" sound name \"Glass\"'" }
        ]
      }
    ]
  }
}

Linux — notify-send:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "notify-send 'Claude Code' 'Задача завершена' && paplay /usr/share/sounds/freedesktop/stereo/complete.oga" }
        ]
      }
    ]
  }
}

Полезные паттерны:

Разные звуки на разные события: Stop = успех, Notification = «нужен ввод».
На событие Notification (модель ждёт пермишен) — звук погромче, чтобы не пропустить.
Сетевая нотификация через webhook (Telegram, Slack, Discord) — пишешь промпт с телефона через /remote-control, получаешь пинг в мессенджер когда готово.

Channels — внешние каналы связи с Клодом

Официальная фича Claude Code (research preview с v2.1.80+). Подключает внешние мессенджеры/каналы прямо к сессии — внешние события и промпты летят в Клод, ответы возвращаются туда же.

Официально поддерживаемые каналы:

Telegram — через бот.
Discord — через бот.
iMessage — на macOS, нативная интеграция.
Fakechat — локальный демо-канал для разработки своих.
Custom — собирается через MCP.

Базовая установка (точный синтаксис команд может меняться, фича в research preview):

Установить плагин канала из официального реестра (telegram / discord / imessage).
Настроить токены/allowlist.
Запустить Claude Code с подключённым каналом.

Актуальные команды и флаги — в доках ниже, синтаксис стоит брать оттуда, а не из памяти.

Доки:

Ограничения:

Research preview — API ещё может меняться.
Требует Bun.
Не работает на Bedrock / Vertex AI / Foundry.
В Team/Enterprise — админ должен включить.

Хороший вариант если нужен мост в мессенджер — не надо городить самописный бот, всё уже есть из коробки.

Claude Code где угодно — VPS, сервера, удалённые машины

Claude Code = обычная CLI на Node.js. Ставится на любой Linux/macOS/Windows где есть node. Не привязан к локальной машине.

Куда можно поставить:

VPS / dev-сервер компании — вайбкодишь прямо там, ничего не качаешь локально.
Удалённая машина с GPU для ML — Claude Code там же где данные и модели.
Raspberry Pi / домашний сервер — для скриптов автоматизации, скрейпинга, бэкапов.
Контейнер / dev-container / Codespaces — изолированная песочница на проект.
Боевой сервер (осторожно, только для аудита/чтения, не для записи) — диагностика прод-проблем без копирования данных к себе.

Как:

SSH на машину.
Установить Node + Claude Code (npm install -g @anthropic-ai/claude-code или официальная инструкция).
Залогиниться: claude → пройти авторизацию.
Работать как обычно. Через tmux / screen сессия переживает разрыв SSH.

Зачем это нужно:

Большой репозиторий который качать локально неудобно — оставил на сервере, подключился, поработал.
Команда работает в одинаковом окружении (dev-сервер) — нет проблем «у меня работает».
Тяжёлые операции (билды, тесты, миграции) не грузят локальную машину.
Связка с /remote-control — Claude крутится на сервере, ты пишешь промпты с телефона. Полная мобильность.

Подводные камни:

Авторизация привязана к аккаунту — каждая машина = отдельный логин.
Лимиты считаются по аккаунту, не по машине.
~/.claude/ на каждой машине свой — настройки, скиллы, MCP не синхронизируются автоматически. Можно держать в dotfiles-репо и симлинкать.

Permissions и `--dangerously-skip-permissions`

Флаг отключает все промпты на разрешение запуска инструментов. Запускается так:

claude --dangerously-skip-permissions

⚠️ Что делает. Модель выполняет любые bash-команды, пишет в любые файлы, дёргает любые MCP без подтверждения. Защита снимается полностью.

✅ Хорошо подходит:

Изолированные окружения (Docker-контейнер, devcontainer, VM, sandbox) — даже если что-то сломается, потерять нечего.
Длинные автономные прогоны где постоянные промпты убивают flow.
CI/скрипты где интерактив невозможен.

⚠️ Не рекомендуется (но решать вам):

На рабочей машине с доступом к продовым ключам, секретам, репозиториям — модель может случайно выполнить деструктивную команду или утечь секрет в лог.
На системе с данными которые нельзя восстановить.
«Просто потому что задолбали промпты» — лучше настроить allow-list через /permissions, эффект тот же без потери защиты на действительно опасных операциях.

Альтернатива — allow-list. Запустить /permissions (интерактивная настройка) или попросить Клода: «добавь в allow-list npm test, git status, ls». Если установлен скилл fewer-permission-prompts — позовите /fewer-permission-prompts, он сам проанализирует историю и предложит что добавить. Промптов меньше, защита от опасного остаётся.

Важно про deny в settings.json. Правила в секции deny действуют даже с флагом --dangerously-skip-permissions. Скип отключает интерактивные промпты, но не обходит явные запреты в конфиге. Хороший паттерн:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(*--no-verify*)",
      "Write(.env*)"
    ]
  }
}

Так можно запускать --dangerously-skip-permissions для удобства, но критичные операции остаются заблокированными. Это разумный компромисс для рабочей машины: меньше промптов на рутине, твёрдая защита от деструктива.

Team-mates

Возможность подключить других AI-агентов как «сокомандников» через TeamCreate. Используется для специализированных ролей (ревьюер, тестировщик, архитектор) которые сохраняют свой контекст между обращениями.

Стартовать рекомендуется со стандартного flow без team-mates — добавлять только когда есть чёткая повторяющаяся роль.

Хвост

Чеклист (необязательный)

Полезные пункты для самопроверки перед/во время задачи. Можно следовать целиком, можно выборочно — на ваше усмотрение:

В проекте есть актуальный CLAUDE.md (стиль, команды, архитектура).
Контекст загружен (project CLAUDE.md прочитан, релевантные файлы упомянуты).
Решено: нужен план или нет.
Если план — Plan Mode + Opus.
После плана — сразу выполнение, не зацикливаться на обсуждениях.
После имплементации — тесты.
После тестов — самообзор / кросс-ревью при необходимости.
Перед следующей задачей — /clear.

На что обратить внимание

Типичные грабли по которым новички часто ходят. Не правила — просто наблюдения:

Сразу писать код без контекста — модель угадывает, результат обычно слабый.
Один длинный диалог на десять задач — контекст забивается, качество падает. Помогает /clear между задачами.
Opus на всё подряд — медленно и дорого, при этом Sonnet справляется с механикой не хуже.
Игнор тестов — «потом проверю» = «никогда не проверю».
Принимать первый ответ как финальный — особенно на сложных задачах. Стоит просить альтернативы, edge cases, что может пойти не так.
Не использовать Serena/Context7 — на больших проектах это заметная переплата токенами и работа по устаревшей доке.
Работать без project CLAUDE.md — модель пишет «среднее по индустрии», а не как ваша команда. Стиль, naming, паттерны не совпадают с кодбазой.
Вкладывать worktrees внутрь репо — обычно ломает IDE и тулзы, проще держать рядом.

Способы работы с Claude — не только CLI

CLI — основная среда, но есть и другие. Кратко что существует:

IDE-расширения (VS Code, JetBrains, Cursor) — Claude Code прямо в IDE. Под капотом тот же CLI.
Claude Code Web (claude.ai/code) — веб-интерфейс, подключается к локальной сессии или запускает облачные песочницы.
Claude for Chrome — браузерное расширение с доступом к вкладке (UI-тесты, парсинг, веб-консоли).
Mobile App (iOS / Android) — лайтовая работа на ходу, в связке с /remote-control или Channels отдаёт промпты в живую сессию.

Аккаунт один, лимиты общие. Подробности и установка — в официальных доках.

Что читать дальше

Документация Claude Code: https://docs.claude.com/claude-code
Список своих скиллов: проверяйте системные подсказки в начале сессии.
Конфиг: ~/.claude/CLAUDE.md (глобальный) и <project>/CLAUDE.md (проектный).

Tier 1 — Первый час

TL;DR

Основной flow

1. Ресёрч и обсуждение

2. Составление плана

3. Реализация

4. Тесты

5. Ревью

Стратегия моделей

Лимиты: 5-часовые окна и недельная квота

5-часовые сессионные окна

Недельная квота

Как мониторить — статус-лайн под инпутом

Контекст-гигиена

Project CLAUDE.md — фундамент работы в проекте

Иерархия CLAUDE.md

Что стоит сделать на старте проекта

Что класть в CLAUDE.md

Что НЕ класть

Базовые CLI-фишки

Сессии: --resume, --continue, /rename

Скриншоты в инпут

Если Claude завис

Tier 2 — Первая неделя

Skills, Commands, MCP — три механизма расширения

Skills

Commands

MCP Servers

Полезные плагины

Caveman

Plannotator

Superpowers

Serena

Context7

/add-dir — несколько папок в одной сессии

Аудиты кодбазы — рекомендуемое первое упражнение

Worktrees — параллельные ветки без конфликтов

Зачем

Где размещать

Команды

Flow с Claude Code

Когда worktrees не нужны

Tier 3 — Продвинутый юзер

Sub-agents

Фоновые процессы — dev-серверы, билды, watch-режим

Смоук-тестирование через Клода

Доки и саммари сессий в репо

/remote-control — вайбкодинг на ходу

Tier 4 — Автоматизация и тонкие настройки

Headless / inline режим — cron, CI, скрипты

Хуки и уведомления

Доступные события

Зачем используют

Звуковые и системные уведомления

Channels — внешние каналы связи с Клодом

Claude Code где угодно — VPS, сервера, удалённые машины

Permissions и --dangerously-skip-permissions

Team-mates

Хвост

Чеклист (необязательный)

На что обратить внимание

Способы работы с Claude — не только CLI

Что читать дальше

Project `CLAUDE.md` — фундамент работы в проекте

Иерархия `CLAUDE.md`

Что класть в `CLAUDE.md`

Сессии: `--resume`, `--continue`, `/rename`

`/add-dir` — несколько папок в одной сессии

`/remote-control` — вайбкодинг на ходу

Permissions и `--dangerously-skip-permissions`