Как сетапить проект с Claude Code

Что нужно перед стартом

Прежде чем запускать Claude Code, убедись что у тебя готово окружение:

• Доступ к коду проекта - локальная копия репозитория на диске. В идеале - в той ветке, в которой ты работаешь. Если есть опасения что Claude что-то сломает, заведи отдельную ветку.
• Локальный запуск - в идеале проект должен подниматься локально в Docker. Это позволит Claude самостоятельно проверять результат.
• Документация в папке проекта - всё что уже есть: PRD, спеки на API, описание архитектуры. Положи в корень или в docs/. Чем больше контекста - тем точнее результат.
• Файлы агентов и CLAUDE.md - если у тебя есть готовые примеры (я их раздавал), положи их в корень проекта.

Инициализация

Открываем терминал в папке проекта и запускаем:

claude

Если запуск был без предустановленных агентов или CLAUDE.md, выполни команду /init - Claude сам просканирует проект и создаст базовый CLAUDE.md.

Анализ проекта

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

Совет: Большие промпты удобнее класть в файл и передавать Claude имя файла, а не вставлять текст в терминал.

Пример промпта:

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

Можно сразу дать контекст о проекте и своей роли - это сильно повышает качество ответа:

Это сайт-каталог софта и игр на Django + PostgreSQL + Jinja2 + UIkit 3.
Я выступаю в роли фронтенд-разработчика. Дальше будем развивать проект в этой части.

Получив документ, внимательно его изучи: всё ли соответствует реальности? Если нет - внеси правки вручную или попроси Claude исправить.

Настройка окружения и правил разработки

Дальше нужно объяснить Claude, как устроен процесс разработки. Описывай просто и конкретно:

Доработай CLAUDE.md с точки зрения правил разработки и обнови соответствующих агентов:

- Разработку я веду локально, в папке `./../...`
- Проверка - в Docker: собирай и перезапускай контейнер, контролируй что порты свободны
- После подтверждения задачи/спринта - коммит на стейджинг в ветку/репо `.../.../`
- Ключи для работы с Git: `./../...` или `(....)`

После этого проверь обновлённый CLAUDE.md и инструкции агентов. Если всё ок - двигаемся дальше.

Важно: Чтобы обновлённые правила вступили в силу, нужно перезапустить сессию Claude в проекте.

Работа с документацией через Obsidian (опционально)

Мне удобнее править и верифицировать документацию в Obsidian, но можно работать и в своём IDE - кому как.

Для синхронизации Obsidian с папкой проекта:

1. Установи плагин BRAT - obsidian://show-plugin?id=obsidian42-brat
2. Через BRAT установи EVC Local Sync - github.com/entire-vc/evc-local-sync-plugin
3. Укажи папку проекта, папку в Obsidian и настрой режим синхронизации

После этого скажи Claude, что документацию нужно хранить и обновлять, например, в папке docs/ (та подпапка что указана в настройках плагина). А сам работай с ней в Obsidian.

Пример: библиотека компонентов + Storybook

Допустим, задача - создать библиотеку UI-компонентов и поднять Storybook. Говорим Claude прямо:

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

Claude создаст компоненты, проверит, что всё собирается. Дальше - обновление и доработка. Тут два подхода:

1. Через скриншоты - делаешь скрины новых/обновлённых компонентов из макетов, кидаешь Claude, просишь создать или обновить компоненты и добавить их в Storybook.
2. Через Figma MCP - если дизайн собран в Figma с правильной структурой (автолейауты, нормальный нейминг), подключаешь MCP-сервер Figma и указываешь, с какой компонентой работаешь.

Дальнейший процесс:

1. Смотришь результат, вносишь правки если нужно.
2. Просишь Claude создать шаблон страницы: указываешь откуда брать данные и куда вставить компонент. В идеале - описание структуры страниц и шаблонов тоже стоит сгенерировать и проверить заранее.
3. Проверяешь локально. Если всё ок - просишь Claude сделать коммит и пуш.

Полезные советы

Контекст и память

Claude не помнит ничего между сессиями - всё что он знает о проекте, он берет из CLAUDE.md и файлов вокруг. Поэтому:

• Держи CLAUDE.md актуальным. Это буквально мозг Claude в твоем проекте.
• Длинные сессии деградируют. Если чувствуешь что Claude начал тупить или повторяться - используй /compact или просто начни новую сессию.
• Не надо каждый раз объяснять что за проект и как он устроен - для этого и нужен CLAUDE.md.

Бей задачи на куски

Не надо давать промпт на три экрана и ждать чуда. Итеративность - ключевой навык:

• Дал задачу - проверил результат - подтвердил - следующий шаг.
• Крупные задачи типа "создай библиотеку компонентов" лучше разбивать: сначала анализ текущих компонентов, потом структура, потом реализация по одному или батчами.
• Если Claude уходит не туда - лучше остановить и переформулировать, чем ждать пока он закопается глубже.

Проверяй перед коммитом

Claude может уверенно написать код который не работает. Или "улучшить" рабочий код так что он сломается. Поэтому:

• Всегда делай git diff перед коммитом и смотри что реально изменилось.
• Если что-то пошло не так - git checkout . откатит все изменения.
• Не пуш вслепую, даже если Claude говорит "всё готово, проверил". Он проверил по-своему, ты проверь по-своему.

Типичные грабли

• Галлюцинации API - Claude может с абсолютной уверенностью использовать метод или параметр которого не существует. Если что-то незнакомое - проверь в доках.
• Зацикливание - иногда Claude пытается чинить ошибку одним и тем же способом по кругу. Если видишь что третий раз одно и то же - останови, объясни проблему по-другому или дай подсказку.
• Лишний рефакторинг - попросил поправить кнопку, а он переписал пол-компонента. В промпте можно прямо писать: "меняй только то что я прошу, остальное не трогай".

Токены и стоимость

Каждое сообщение в Claude Code - это токены, а токены - это деньги. Пара моментов:

• Большие файлы в контексте дорого. Не гоняй полный анализ проекта на каждый мелкий вопрос.
• Если нужно просто подправить пару строк - иногда быстрее сделать руками чем объяснять Claude.
• /compact не только помогает с качеством, но и экономит контекст.