Лучшие практики Claude Code: практический чек-лист

Лучшие практики Claude Code для реальных проектов: короткий CLAUDE.md, сначала план, проверка для запуска, небольшие задачи, /clear, разрешения, хуки и worktree.

Solviera Teknoloji 11 мин чтения

Самые важные лучшие практики Claude Code просты: держите CLAUDE.md коротким, планируйте перед крупными изменениями, давайте Claude проверку, которую он может запустить, работайте небольшими задачами, очищайте контекст между ними, закрепляйте жёсткие правила конфигурацией, а не текстом, и запускайте параллельную работу в отдельных git worktree. А затем читайте diff и коммитьте почаще.

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

Чек-лист одним взглядом

#ПрактикаКоротко
1Короткий CLAUDE.mdТолько команды, подводные камни и решения
2Конкретные промптыСимптом, место, как доказать, что исправлено
3Сначала планРежим планирования или письменная спецификация для всего многошагового
4Проверка для запускаТесты, проверка типов, линтер; просите доказательства
5Небольшие задачиОдна цель на сессию, /clear между задачами
6Жёсткие правила в конфигурацииЗапреты, хуки, песочница
7Направляйте сразуEsc, /rewind и /clear после двух неудачных поправок
8Субагенты осознанноПараллельная работа и свежий взгляд на ревью, а не по привычке
9Worktree для параллельной работыОдна рабочая копия на сессию
10Ревью и коммитыЧитайте diff, коммитьте маленькими шагами, пушьте сами

1. Держите CLAUDE.md коротким и фактическим

Claude Code загружает CLAUDE.md в каждую сессию, поэтому каждая строка в нём забирает немного внимания в каждой задаче, к делу она относится или нет. Файл работает лучше всего, когда в нём только то, до чего Claude не может додуматься по коду:

  • Как подтвердить работу в этом репозитории: точные команды тестов, проверки типов и линтера и как запустить один тестовый файл.
  • Места, где код вводит в заблуждение: старый паттерн, который новый код не должен копировать, папка, которая выглядит мёртвой, но таковой не является.
  • Решения, которых нет в репозитории: какой помощник для ошибок выбрала команда, как устроен деплой.
  • Всё, что вам пришлось поправлять дважды.

Файл, прошедший такой отбор, остаётся небольшим:

# Commands
- Install: pnpm install
- Run one test file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit

# Conventions
- Use the error helpers in src/lib/errors.ts, never throw raw strings
- src/legacy/ is still live but don't copy its patterns into new code

# Gotchas
- Integration tests need DATABASE_URL set, see .env.example

Описывать архитектуру или структуру папок не нужно: Claude читает репозиторий. /init пишет первый черновик, а дальше работа в основном состоит в удалении. Официальное руководство по памяти советует укладываться в 200 строк. /context подтверждает, что файл загружен, а /doctor подсказывает, что сократить. Личные предпочтения храните в CLAUDE.local.md и добавьте его в .gitignore.

Два связанных инструмента помогают держать основной файл компактным. Правила, важные только для одной части проекта, кладите в .claude/rules/*.md с фильтром paths:, и они загружаются только тогда, когда Claude работает там. Командные процедуры, например чек-лист релиза, оформляйте как skill в .claude/skills/<name>/SKILL.md: Claude видит только его имя и описание, пока ему не понадобится полный текст. Полный разбор — в статье Как писать CLAUDE.md и AGENTS.md.

Если Claude упорно игнорирует какую-то строку, слово IMPORTANT заглавными буквами помогает редко. Либо файл слишком длинный, либо эта строка — правило без исключений, и ей место в хуке (см. пункт 6).

2. Пишите промпты, в которых сказано где, что и как проверить

Расплывчатый промпт заставляет Claude угадывать. Конкретный называет симптом, место, где искать, и способ доказать исправление:

Пользователи жалуются, что после истечения сессии вход не работает. Посмотри обновление токена в src/auth/, напиши падающий тест, который это воспроизводит, а затем исправь.

Указывайте файлы через @, вставляйте скриншоты и передавайте логи через пайп, а не пересказывайте их. Если вы ещё не знаете, чего хотите, пусть Claude сначала проведёт с вами интервью:

Я хочу добавить ограничение частоты запросов в публичный API, но ещё не продумал детали. Задавай мне вопросы, пока не сможешь написать спецификацию, а затем запиши её в SPEC.md.

Затем начните новую сессию, которая строит по SPEC.md. Работа начинается с чистого контекста и письменного определения готовности, а спецификация потом служит эталоном для ревьюера. Больше шаблонов промптов — в статье Как писать промпты для ИИ-агентов программирования.

От двух привычек можно отказаться: фразы вроде «think hard» не повышают уровень рассуждений (используйте /effort high или напишите ultrathink в отдельном промпте), а выделение ЗАГЛАВНЫМИ в основном приводит к тому, что Claude применяет правило слишком усердно.

3. Планируйте перед многошаговыми изменениями

Для всего, что затрагивает несколько файлов, отделяйте обдумывание от правок. Режим планирования позволяет Claude прочитать код и предложить план, ничего не меняя. В него можно перейти через Shift+Tab или сразу начать в нём сессию:

claude --permission-mode plan

Прочитайте план, поправьте его и только потом дайте Claude строить. Неверное допущение, пойманное в плане, стоит одного сообщения; пойманное в diff — переписывания. Мелким очевидным исправлениям план не нужен. Подробности, в том числе как отредактировать план перед одобрением, — в статье Режим планирования Claude Code.

4. Дайте Claude проверку, которую он может запустить

Эта привычка окупается сильнее всех. Claude может знать, что закончил, только если ему есть что запустить: набор тестов, проверку типов, команду линтера, код выхода сборки, скрипт, сравнивающий вывод с эталоном. Если в репозитории такое есть, самая полезная строка в CLAUDE.md — команда, которая это запускает.

Насколько строго применять проверку, решаете вы:

  • В промпте. «После этого запусти тесты auth и продолжай, пока они не пройдут». Работает для любой задачи без настройки.
  • Как цель. /goal all tests in tests/auth pass and lint is clean задаёт условие, которое отдельная модель проверяет после каждого хода. Полезнее всего для долгих запусков.
  • Как Stop-хук. Claude Code запускает ваш скрипт, когда Claude пытается завершить ход, и возвращает его к работе, если скрипт завершается с кодом 2.
  • С независимым ревьюером. /code-review проверяет diff в свежем субагенте, который не видел вашего разговора.

Вариант «проверка типов должна пройти» в виде Stop-хука живёт в .claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Stderr возвращается Claude как причина, по которой он пока не может остановиться, поэтому вывод компилятора перенаправлен туда. Если хук блокирует восемь остановок подряд без вызова инструмента между ними, Claude Code всё равно завершает ход; CLAUDE_CODE_STOP_HOOK_BLOCK_CAP поднимает этот предел.

Что бы вы ни выбрали, просите доказательства: команду, которую запустил Claude, и её вывод. Само по себе «все тесты проходят» говорит мало. После изменения интерфейса /verify заставляет Claude собрать и запустить приложение и посмотреть на результат.

5. Держите задачи небольшими, а контекст чистым

Одна сессия — одна цель. Разговор, в котором скопились три несвязанные задачи, заново отправляет их все на каждом ходу четвёртой, а это дороже и делает ответы менее сфокусированными.

  • /clear между несвязанными задачами. /clear oauth-migration ещё и даёт имя сессии, из которой вы уходите, чтобы к ней можно было вернуться.
  • /compact keep the API changes and the test commands сокращает длинную сессию, сохраняя важное. В длинной сессии /compact сам по себе — крупный запрос.
  • /usage показывает, на что уходит ваш лимит, в том числе в разбивке по субагентам, skills и MCP-серверам на подписочных тарифах.

По состоянию на октябрь 2026 года у большинства актуальных моделей окно в 1M токенов, а сжатие запускается само, так что контекст заканчивается редко. Очистка нужна ради фокуса и стоимости, а не ради выживания. Кэш промптов живёт около часа на подписке и около пяти минут с API-ключом, поэтому сессию, простоявшую весь обед, продолжать дороже, чем начать новую. Механика описана в статье Управление контекстом в Claude Code.

6. Правила, которые нельзя нарушать, — в конфигурацию

CLAUDE.md хранит рекомендации, а Claude вправе решить, что рекомендация здесь неприменима. Для тех немногих правил, где «почти всегда» недостаточно, используйте механизмы, которые Claude Code применяет сам.

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

{
  "permissions": {
    "allow": ["Bash(pnpm tsc --noEmit)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
  }
}

Запреты действуют в любом режиме разрешений, а правило Read также перехватывает распространённые shell-команды чтения файлов вроде cat .env. Скрипт, который сам открывает файл, оно не поймает, поэтому для работы, чувствительной к безопасности, включите ещё и песочницу через /sandbox: она ограничивает shell-команды на уровне ОС в macOS, Linux и WSL2.

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

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write --ignore-unknown \"$(jq -r '.tool_input.file_path')\"" }
        ]
      }
    ]
  }
}

Используйте хуки только для правил без исключений; «предпочитай именованные экспорты» остаётся в CLAUDE.md. Все события и коды выхода разобраны в руководстве по хукам Claude Code.

Режимы разрешений. По состоянию на октябрь 2026 года новые интерактивные сессии начинаются в режиме auto, где рискованные действия проверяет классификатор, а не вы на каждом шаге. Это хорошо, но это суждение, поэтому ваши правила «никогда» всё равно должны быть в запретах и хуках. Если вы предпочитаете одобрять каждый шаг, Shift+Tab переключает в Manual, или запустите claude --permission-mode manual. Если Manual спрашивает слишком часто, /fewer-permission-prompts добавит ваши частые команды только для чтения в список разрешённых. Почему полностью пропускать разрешения — плохой размен, рассказано в статье Claude Code: пропуск разрешений.

7. Направляйте сразу и начинайте заново вместо споров

Следите за первой минутой задачи. Рычагов немного:

  • Esc останавливает Claude посреди действия и сохраняет всё сделанное, чтобы вы могли перенаправить его.
  • /rewind или двойное нажатие Esc на пустом промпте откатывает код, разговор или и то и другое к одному из прошлых промптов.
  • /clear начинает заново. После двух неудачных поправок третья в основном добавляет ещё одну неудачную попытку, которую Claude будет перечитывать. Очистите контекст и напишите один промпт получше, учитывающий то, что вы узнали.

Контрольные точки охватывают файлы, которые Claude изменил своими инструментами правки; файл, который тронула только Bash-команда, не восстанавливается. Они работают вместе с git, а не вместо него. Для работы, растянутой на несколько дней, /rename oauth-migration даёт сессии имя, а claude --resume oauth-migration позже её подхватывает.

8. Используйте субагентов осознанно

Claude Code и так делегирует сам: широкие поиски уходят встроенному агенту Explore, а субагенты по умолчанию работают в фоне. Каждый субагент отправляет свои запросы, поэтому тратит токены, и умнее ответ от этого не становится. Используйте их для:

  • Независимых частей работы, которые можно выполнять одновременно.
  • Того, чтобы длинный вывод, например полный прогон тестов, не попадал в основной разговор.
  • Ревьюера, который не видел, как писался код.
  • Задачи, которой нужно меньше инструментов, чем основной сессии.

Ревьюер только для чтения — это один короткий файл .claude/agents/reviewer.md:

---
name: reviewer
description: Reviews changed files against the spec they were built from. Use after implementing a feature, before opening the PR.
tools: Read, Grep, Glob
---
You're reviewing code you didn't write. Compare the changed files against the spec you're given,
check that every requirement is implemented and the listed edge cases have tests,
and report only the gaps that affect correctness. Skip style.

Для простых задач, например собрать файлы, которые импортируют модуль, добавьте в определение model: haiku. Затем попросите:

Пусть ревьюер сравнит ограничитель частоты запросов с SPEC.md.

Больше паттернов — в статье Субагенты Claude Code.

9. Запускайте параллельную работу в worktree

Две сессии, правящие одну рабочую копию, перезапишут друг друга. Дайте каждой свой git worktree:

claude -w feature-auth

Worktree — это свежая рабочая копия, поэтому файлов из .gitignore вроде .env там нет, а зависимости не установлены. Перечислите небольшие игнорируемые файлы в .worktreeinclude в корне репозитория, и Claude Code будет копировать их в каждый создаваемый worktree:

.env
.env.local
config/dev-credentials.json

node_modules туда не добавляйте: файлы копируются, а не связываются ссылками. Лучше держите команду установки в CLAUDE.md или используйте настройку worktree.symlinkDirectories. Когда вы выходите из безымянной сессии в worktree без изменений, Claude Code удаляет его, иначе спрашивает. Для одного крупного механического изменения /batch делит работу на части, запускает каждую в своём worktree и открывает PR на каждую часть. Подробнее — в статье Git worktree для параллельных агентов.

10. Читайте diff, коммитьте маленькими шагами, пушьте сами

Агент пишет, вы одобряете. Прежде чем принять ход, прочитайте git diff, а не сводку. Коммитьте после каждого рабочего шага, чтобы неудачный следующий шаг отменялся одним git reset. Пуши, слияния и деплои оставьте за человеком: правило ask для git push * выше делает ровно это. Вторая сессия, которая проверяет @src/middleware/rateLimiter.ts, не наблюдав за его написанием, — самый дешёвый независимый ревьюер, который у вас есть.

Бонус: прежде чем оставить Claude без присмотра

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

  1. Знает ли он, как выглядит «готово»? Цель, файл спецификации, падающий тест.
  2. Может ли он проверить свою работу? Тесты, Stop-хук, шаг ревью.
  3. Что ему можно трогать? Правила разрешений, dontAsk, песочница, worktree.
  4. Что его остановит? --max-turns, --max-budget-usd, лимит расходов.
  5. Куда идёт результат и кто его утверждает? PR и человек, который одобряет слияние.

Для скриптовых запусков и CI см. статью Headless-режим Claude Code.

Как это делать в AgentVera

Большая часть этого чек-листа — про дисциплину; AgentVera упрощает несколько пунктов, когда вы запускаете больше одной сессии. Каждая панель в рабочем пространстве — это настоящий терминал Claude Code, поэтому Shift+Tab, режим планирования, хуки и ваш CLAUDE.md работают как обычно. Из панели Git можно создать worktree для каждого агента, а координация агентов предупреждает, когда два агента правят один и тот же файл.

Для пункта 4 есть автоматическое код-ревью: выбранная вами модель Claude проверяет изменения каждого хода, перечисляет находки с серьёзностью и file:line и может отправить их обратно агенту. Verify (Pro и Team) превращает ваше сообщение в критерии приёмки, а отдельный проверяющий по завершении хода проверяет их с доказательствами. Для пункта 7 контрольные точки сохраняют снимок каждого хода в скрытую git-ссылку и хранят последние 60 на агента. Сетка, worktree, код-ревью и контрольные точки есть в бесплатном тарифе; скачайте AgentVera, чтобы попробовать.

Итог

Если взять только три пункта, возьмите эти: короткий CLAUDE.md с вашими настоящими командами, проверку, которую Claude запускает, прежде чем сказать «готово», и /clear между задачами. Добавьте запреты и хуки для того, что не должно случиться никогда, worktree, как только начнёте запускать сессии параллельно, а финальное ревью и пуш оставьте себе.

Вопросы

Какая привычка в Claude Code полезнее всего?

Дать Claude способ проверить свою работу. Запишите точные команды тестов, проверки типов и линтера в CLAUDE.md, назовите проверку в промпте и, когда Claude говорит, что закончил, попросите команду и её вывод. Без проверки «готово» означает лишь, что Claude остановился.

Какой длины должен быть CLAUDE.md?

Короткой. Claude Code загружает его в каждую сессию, поэтому каждая строка забирает немного внимания в каждой задаче. Официальное руководство по памяти советует укладываться в 200 строк. Запустите /init для первого черновика, а потом в основном удаляйте: оставьте команды, подводные камни и решения, которых не видно в коде.

Что использовать: /clear или /compact?

Используйте /clear между несвязанными задачами: это ничего не стоит, и следующая задача перестаёт платить за старую историю. Используйте /compact с указанием фокуса, например «/compact keep the API changes and the test commands», когда хотите продолжить ту же задачу с более короткой историей.

Безопасно ли разрешать Claude Code запускать команды без вопросов?

По состоянию на октябрь 2026 года интерактивные сессии начинаются в режиме auto, где рискованные действия проверяет классификатор. Это суждение, а не жёсткое правило, поэтому всё, что не должно случиться никогда, должно быть в запретах, хуках или песочнице. Shift+Tab переключает в режим Manual, если вы хотите одобрять каждый шаг.

Как запустить несколько сессий Claude Code одновременно без конфликтов?

Дайте каждой сессии свой git worktree, например через claude -w feature-auth. Каждый worktree — это отдельная рабочая копия на своей ветке, поэтому правки не пересекаются. Перечислите файлы из .gitignore, такие как .env, в .worktreeinclude, чтобы они копировались в новые worktree.

Соберите своих агентов за одним столом.

Скачайте AgentVera бесплатно; ваши установленные CLI уже готовы к работе.

Другие статьи