Claude Code для бизнеса: 8 шагов и 7 скиллов

Ваш разработчик (или вы сами) тратит часы на рутину: написать функцию, разобраться в чужом коде, починить баг. А можно делегировать это AI и получить результат за минуты. Но просто запустить Claude Code и сказать «сделай» - не работает. Без системы он галлюцинирует, переделывает по десять раз и забывает, о чём договаривались. С системой - это сотрудник, которому можно отдать задачу и получить готовый код с первого-второго подхода.

Эта статья - готовая система из 8 шагов и 7 скиллов. Собрана из практики разработчиков, которые проводят в Claude Code по несколько часов в день. В конце - чек-лист, по которому можно пройти с нуля.

Зачем это бизнесу

По данным Anthropic за март 2026, 49% профессий уже передают часть работы AI. Речь не о замене программистов - речь о том, чтобы рутину (написать функцию по описанию, разобраться в чужом коде, накатать тесты) делегировать агенту, а себе оставить решения и контроль.

Claude Code живёт в терминале, читает кодовую базу целиком, редактирует несколько файлов сразу, запускает команды и тесты, делает коммиты - и итерируется сам, пока задача не решена. Вы ставите цель, он планирует и исполняет.

Главный сдвиг: вы больше не печатаете код построчно. Вы ставите задачу и контролируете исполнение. Самый важный навык - не запуск агента, а умение вовремя его остановить. К кнопке Stop мы ещё вернёмся, она в этой системе центральная.

Выбор инструмента: Claude Code от Anthropic, Codex от OpenAI и другие близки по идее. Почти всё из этой статьи переносится между ними. Если только начинаете - выбирайте любой, не застревайте в сравнении. Освоенная система важнее марки агента.

Шаг 1. Идеальный первый запрос: 5 обязательных элементов

90% плохих результатов - плохие запросы. Агент не читает мысли. Хороший первый запрос содержит пять элементов. Прогоняйте каждую серьёзную задачу через этот чек-лист.

Цель. Что конкретно нужно получить. Не «улучши авторизацию», а «добавь вход через email и пароль с проверкой на сервере». Размытая цель = размытый результат.

Контекст. Где это находится и как устроено вокруг. Какой стек, какие файлы относятся к задаче, как называется нужный модуль. Чем точнее контекст, тем меньше агент тратит токенов на блуждание.

Ограничения. Чего делать нельзя. «Не трогай файл config.py», «не меняй публичный API», «используй только стандартную библиотеку». Ограничения экономят больше всего времени - отсекают целые ветки неправильных решений до того, как агент по ним пойдёт.

Формат вывода. В каком виде нужен результат. Один файл или несколько, с тестами или без, нужен ли комментарий. Если ждёте таблицу - попросите таблицу. Если markdown - скажите markdown.

Примеры. Один пример стоит абзаца объяснений. Покажите, как выглядит «правильно»: фрагмент кода в нужном стиле, образец вывода, ссылку на похожий участок проекта.

Собранный запрос выглядит так:

Цель: добавить эндпоинт POST /api/login, принимает email+password, возвращает JWT.
Контекст: FastAPI, роуты в src/api/routes/, модели в src/db/models.py, пользователь - таблица users.
Ограничения: не трогай существующие роуты, пароль сверяй через passlib, новых зависимостей не ставь.
Формат: один файл src/api/routes/auth.py + короткий комментарий о том, что изменилось.
Пример: стиль роутов смотри в src/api/routes/users.py.

Такой запрос агент исполняет почти без уточнений. Размытый «сделай логин» - десять итераций и не то.

Шаг 2. Режим плана (plan mode) и почему он экономит часы

Режим плана включается переключением (в Claude Code это Shift+Tab до появления plan mode). В этом режиме агент не трогает ни одного файла. Он сначала описывает, что собирается сделать: какие файлы создаст и изменит, в каком порядке, какие команды запустит. Вы читаете план и либо подтверждаете, либо правите.

Зачем это нужно: ошибку в плане вы видите за тридцать секунд чтения. Ту же ошибку в готовом коде - после того, как агент переписал пять файлов, и теперь надо всё откатывать и объяснять заново. Plan mode переносит проверку в начало, когда правка стоит одной фразы, а не полчаса разгребания.

Правило: любую задачу сложнее однострочной правки начинайте с plan mode. Прочитали план - увидели, что агент собрался лезть не в тот модуль или тянуть лишнюю зависимость - поправили одной репликой. Это снижает количество переделок в разы.

На что смотреть в плане: список файлов (если агент собрался трогать то, что просили не трогать), новые зависимости (агенты любят подтянуть библиотеку там, где хватило бы пары строк), порядок шагов (иногда агент планирует написать код раньше, чем разберётся в существующем). Поправить план - написать «не ставь библиотеку X, сделай вручную» или «сначала прочитай src/db/models.py, потом пиши». Тридцать секунд против получаса разгребания готового кода.

Шаг 3. Git как машина времени и кнопка Stop

Агент работает автономно, а значит может ошибиться масштабно. Две вещи делают это безопасным: git и Stop.

Git как машина времени

Перед тем как дать агенту серьёзную задачу, зафиксируйте текущее состояние:

git add -A && git commit -m "before agent task"

Теперь любой результат работы агента откатывается одной командой:

# отменить незакоммиченные правки во всех файлах
git checkout .

# вернуть всё к последнему коммиту
git reset --hard HEAD

Это и есть машина времени. Вам не нужно вручную помнить, что агент менял, и откатывать руками - git хранит все состояния. Не бойтесь давать агенту смелые задачи, если перед этим есть коммит: в худшем случае вы потеряете минуты, а не работу.

Полезная привычка - просить агента самого делать коммит после каждого логического шага. Тогда история чистая, и откатиться можно не на всё подряд, а на конкретную точку.

Кнопка Stop

Stop (в Claude Code это Esc) прерывает агента прямо на ходу. Видите, что он пошёл не туда - правит не тот файл, тянет лишнюю библиотеку, зациклился на одной ошибке - жмёте Stop, не дожидаясь, пока он закончит. Это не аварийная мера, это нормальный инструмент управления.

Распространённая ошибка новичка - запустить агента и уйти. Агент без присмотра может полчаса упорно решать задачу неправильным способом и сжечь на этом весь контекст. Смотрите, что он делает, и останавливайте при первом признаке, что он свернул не туда. Главный навык в работе с агентом - не запуск, а вовремя нажатый Stop.

Шаг 4. Режимы разрешений: начинайте с минимального

У Claude Code есть несколько уровней автономии. На минимальном уровне он спрашивает разрешение перед каждым действием - правкой файла, запуском команды. На максимальном (режим, который иногда называют «опасным») делает всё сам без спроса.

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

Шаг 5. CLAUDE.md как роутер

CLAUDE.md - это файл постоянной памяти проекта. Агент читает его при каждом запуске, и туда кладут то, что агент должен знать всегда: стек, архитектуру, команды запуска, договорённости по стилю. Это спасает от галлюцинаций - агент перестаёт выдумывать структуру проекта, потому что она у него перед глазами.

Сгенерировать первую версию можно командой /init - она сканирует проект и собирает шпаргалку с архитектурой и связями. Дальше файл дополняют по мере работы.

Ключевое правило: это роутер, а не свалка. Держите его под 200 строк. В сам файл - только самое важное и ссылки на детали. Детали выносите в отдельные файлы.

Плохо:

CLAUDE.md (800 строк: вся архитектура, все правила стиля,
история всех решений, описание каждого модуля...)

Хорошо:

# Проект X

Стек: FastAPI + Postgres + Next.js.
Запуск: docker compose up. Тесты: pytest.

## Детали
- Архитектура API: см. docs/api-architecture.md
- Правила стиля: см. docs/code-style.md
- Схема БД: см. db/schema.md

Почему так. Контекст конечен. Если CLAUDE.md занимает 800 строк, он съедает контекст на каждом запуске, даже когда детали не нужны. Роутер же грузит в голову агента короткую карту, а в подробный файл агент заглядывает только когда задача этого требует. Этот же принцип работает и для глобального CLAUDE.md, общего для всех проектов.

Шаг 6. Управление контекстом: /compact на 60%

У агента ограниченное контекстное окно - объём текста, который он держит в голове одновременно. По мере работы оно заполняется: ваши запросы, прочитанные файлы, вывод команд. Когда окно переполняется, начинается главная беда длинных сессий - агент забывает, о чём договаривались в начале.

Проверить заполнение можно командой /context - она показывает, сколько токенов израсходовано.

Не дожидайтесь, пока окно забьётся под завязку. Примерно на 60% заполнения делайте /compact. Команда сжимает историю диалога: убирает промежуточные шаги и оставляет суть. Но просто /compact рискует выкинуть важное, поэтому указывайте явно, что сохранить:

/compact сохрани архитектуру API и схему БД, которые мы обсудили

Тогда после сжатия агент помнит ключевые договорённости, а не общую кашу. Привычка «дошёл до ~60% - сделал /compact с явным указанием» - одна из самых полезных в длинных сессиях.

Шаг 7. Sub-agents для параллельной работы

Когда задача большая и распадается на независимые части, не гоните всё через одну сессию. Используйте sub-agents. Главная сессия выступает оркестратором: она раздаёт подзадачи, а каждый sub-agent работает в своём отдельном контекстном окне параллельно.

Зачем это нужно: контекст не засоряется (пока один sub-agent копается в деталях рефакторинга одного модуля, главная сессия не забивает свою память этими деталями) и скорость (независимые куски делаются одновременно).

Типичный сценарий - большой рефакторинг или фича, которая трогает несколько изолированных частей. Главная сессия разбивает её: один агент переписывает слой данных, другой - API, третий пишет тесты. Каждый со своим чистым контекстом.

Sub-agents хороши и для исследования. Например, «найди по всей кодовой базе, где используется устаревшая функция X, и составь список» - это можно отдать sub-agent, чтобы он перерыл проект, а главная сессия получила готовый список, не забив свой контекст десятками прочитанных файлов. Поиск, инвентаризация, сбор фактов - всё это удобно выносить наружу.

Не злоупотребляйте. Sub-agents оправданы, когда части реально независимы. Если они постоянно зависят друг от друга, накладные расходы на координацию съедают выигрыш - проще делать в одной сессии.

Шаг 8. Скиллы и правило «меньше = лучше»

Скилл - это переиспользуемая инструкция, упакованный процесс. Один раз описали, как делать определённую задачу, и дальше вызываете скилл вместо того, чтобы каждый раз объяснять заново. Скиллы вызываются по имени или slash-командой.

Агент не загружает все скиллы целиком. Он видит только название и описание каждого. Полную инструкцию он подгружает только в момент, когда задача совпала с описанием скилла. Подгрузка по требованию, а не при каждом запросе.

Из этого следует контринтуитивный вывод: меньше скиллов работает лучше, чем больше. Когда у вас 40-50 скиллов, агент путается. Это как меню из 500 блюд - выбрать невозможно. Семь чётких скиллов, где каждый делает одну задачу, бьют пятьдесят похожих.

Рабочий набор из 7 скиллов

Вот проверенная стартовая система. Не ставьте больше, пока не поймёте, зачем вам каждый дополнительный.

Прожарка идеи (Grilli). Задаёт 40-50 вопросов до написания первой строки кода. Превращает сырую идею в чёткий бриф. Спасает от ситуации «начал делать, на середине понял, что делал не то».
Планирование (Superpowers). Строит план реализации из брифа. Логичная пара к прожарке: сначала вытащили правильную идею, потом разложили на шаги.
Создание скиллов (Skill Creator). Удачный процесс упаковываете в новый скилл, чтобы не повторять его вручную. После каждого проекта: что хорошо сработало - в скилл.
Ресёрч (Last N Days). Собирает свежий контент по теме из Reddit, Twitter, YouTube, HackerNews, GitHub, Perplexity. Полезно, когда нужно быстро понять текущее состояние какой-то технологии или тренда.
Handoff. Сохраняет контекст между сессиями (разберём отдельно ниже - это важно).
Playwright. Тестирование браузером: открыть страницу, кликнуть кнопки, заполнить формы, сделать скриншоты, написать тесты. Обязателен для любого живого продукта с пользователями и деньгами.
База знаний (Obsidian). Структурирует материалы в wiki-формат со ссылками. Накопленное переиспользуется в следующих проектах - агент сам предлагает сослаться на прошлый материал.

Скиллы бывают глобальные (нужны во всех проектах) и локальные (только в конкретном). Прожарку и планирование держат глобально, а узкоспециальный скилл под один проект кладут в его папку.

Handoff-файл против протухания контекста

Даже с /compact у длинной сессии есть предел. Через 30-40 минут плотной работы контекст «протухает»: агент начинает забывать договорённости, которые казались очевидными в начале. Закрыли терминал, вернулись завтра - и новая сессия вообще ничего не помнит.

Решение без тяжёлой инфраструктуры - Handoff-файл. Это markdown-файл в корне проекта, куда агент перед концом сессии (или вы по команде) записывает:

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

В начале новой сессии агент читает Handoff и мгновенно входит в контекст - без пересказа всей истории заново. Это дешевле любой базы данных и работает сразу.

Один нюанс: добавьте Handoff-файл в .gitignore. Это служебная заметка для агента, в истории проекта ей не место.

Практический чек-лист для новичка

Пройдите по нему на первой же реальной задаче.

Перед стартом задачи

Сделал git-коммит текущего состояния (точка отката готова).
Проверил, есть ли в проекте CLAUDE.md. Нет - сделал /init.
CLAUDE.md держу под 200 строк, детали вынес в отдельные файлы.

Формулирую запрос

Указал цель (конкретно, не размыто).
Дал контекст (стек, нужные файлы).
Прописал ограничения (чего нельзя трогать).
Задал формат вывода.
Привёл пример или ссылку на образец.

Во время работы

Сложную задачу начал с plan mode (Shift+Tab), прочитал план до запуска.
Разрешения на минимуме, смотрю что агент делает.
Свернул не туда - нажал Stop (Esc), не жду до конца.
Контекст дошёл до ~60% (/context) - сделал /compact с явным «сохрани X».
Большая задача из независимых частей - раздал sub-agents.

Длинные сессии и скиллы

Перед концом сессии записал Handoff-файл (цель, прогресс, решения, следующие шаги).
Handoff в .gitignore.
Скиллов мало и каждый про одно. Не разрастаюсь до 40-50.

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

Частые вопросы

С чего начать, если никогда не работал с Claude Code?

Сначала сделать git-коммит как точку отката, затем запустить /init чтобы создать CLAUDE.md с описанием проекта, потом сформулировать первый запрос по пяти элементам - цель, контекст, ограничения, формат, пример. Сложную задачу открывать через plan mode (Shift+Tab), чтобы сначала увидеть план, не дожидаясь готового кода.

Зачем нажимать Stop, если агент работает?

Это не аварийная кнопка, а основной инструмент управления. Если агент пошёл не туда - правит не тот файл или тянет лишнюю библиотеку - лучше остановить сразу (Esc), чем ждать пока он переделает пять файлов. Без присмотра агент может полчаса решать задачу неправильным способом и сжечь весь контекст сессии.

Сколько скиллов нужно настроить для нормальной работы?

Семь скиллов - рабочий набор. Больше не лучше: при 40-50 скиллах агент путается в выборе. Минимальный стартовый набор - прожарка идеи, планирование, создание скиллов, ресёрч, handoff, Playwright для тестирования браузером и база знаний.

Что делать, если агент начинает забывать договорённости из начала разговора?

Два инструмента: команда /compact примерно на 60% заполнения контекста - она сжимает историю, но важно явно указать что сохранить. И Handoff-файл в корне проекта: перед концом сессии агент записывает туда цель, прогресс и следующие шаги, а в новой сессии читает его и сразу входит в контекст.

AI Компас (t.me/kosmoslab_ai) - канал для предпринимателей в РФ и СНГ, которые применяют AI в своём бизнесе без программиста. Разбираем инструменты и схемы - без курсов и теории.