Полная рабочая система Claude Code для новичка: 5 элементов первого запроса, plan mode, git как машина времени, CLAUDE.md-роутер, /compact, sub-agents и 7 скиллов по правилу «меньше = лучше».

Claude Code с нуля: рабочая система из 8 шагов и 7 скиллов

Claude Code запускается одной командой и сразу готов писать код. Но «готов писать код» и «работает на вас» - разные вещи. Без системы агент галлюцинирует, тратит токены на переделки, забывает договорённости через полчаса и выдаёт не то, что вы просили. С системой он становится сотрудником, которому можно делегировать многочасовую задачу и получить результат с первого-второго подхода.

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

Зачем вообще Claude Code

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

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

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

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

Шаг 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 - она сканирует проект и собирает шпаргалку с архитектурой и связями. Дальше файл дополняют по мере работы.

Ключевое правило, которое отличает рабочий CLAUDE.md от мусорного: это роутер, а не свалка. Держите его под 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-коммита и пятиэлементного запроса на ближайшей задаче, добавляйте остальное по мере того, как почувствуете, где упираетесь. Через несколько сессий вы перестанете печатать код руками и начнёте им управлять.