Съвети

Добри практики за работа с Claude Code — CLAUDE.md, фокусирани промптове, plan mode, управление на контекста, git worktrees и субагенти.

Инструментите ги има в останалите страници. Тук е как се използват заедно.

Почти всички проблеми при работа с Claude Code се свеждат до едно от двете: липсва му контекст или има твърде много контекст. Съветите долу са начини да държиш баланса.

CLAUDE.md

CLAUDE.md се чете при всяка сесия. Това е мястото за нещата, които иначе обясняваш всеки път.

Генерирай първата версия

/init анализира кодовата база и прави чернова. Не я оставяй такава — тя е стартова точка.

Изчисти я

Махни всичко, което Claude може да разбере сам от кода. Остави само това, което не е очевидно.

Поддържай я с `#`

Всеки път, когато повториш инструкция, я запиши с # префикс.

Какво влиза вътре

Влиза	Не влиза
Команди за build, test, lint (`pnpm test`, не „пусни тестовете“)	Преразказ на структурата на папките
Конвенции, които не се виждат от кода	Неща, които линтърът вече проверява
Изрични забрани — „никога не пипай `generated/`“	Дълга документация — сложи я във файл и сочи към него
Специфични капани в проекта	Общи съвети за програмиране

Има три нива и трите се четат:

~/.claude/CLAUDE.md
project/
- CLAUDE.md
- packages/
  - api/
    - CLAUDE.md

Малки, фокусирани промптове

Един промпт — една задача. Ако в изречението има „и после“, вероятно са две задачи.

Добре

„Добави validation на email полето в RegisterForm и покрий го с тест.“

По-зле

„Оправи формата за регистрация, добави тестове, обнови документацията и направи PR.“

Голямата задача не е забранена — просто ѝ дай plan mode или субагент, вместо да я пуснеш направо.

Plan mode за големи промени

Shift+Tab до plan mode, преди да пуснеш нещо, което ще пипне повече от няколко файла.

Печелиш две неща: виждаш подхода, преди да е написан код (поправката на план е една реплика, поправката на код е нова сесия), и Claude чете кода внимателно, вместо да започне да пише веднага.

Промпт, който предава решение, обикновено бие промпт, който предава инструкция. „Напиши ми функция, която прави X“ ти дава X. „Как да подходим към X?“ ти дава първо разсъжденията — а там изплуват грешките, докато още е евтино да се поправят.

Четири навика в този дух:

Накарай го да пита, докато не е сигурен

Plan mode прави част от това сам, но можеш да го поискаш направо: „keep asking me questions until you’re 95% confident you understand exactly what I need.“ Един кръг въпроси в началото струва по-малко от три кръга поправки после. Има и пакетирана версия на този навик — grilling скилът, интервю, което е просто промпт.

Вкарай проверката в списъка със задачи

Когато Claude си прави to-do списък, поискай и проверките да са точки в него — построй страницата, после я снимай и потвърди, че изглежда добре, после отвори браузъра и потвърди, че няма грешки. Добавянето на „don’t move to the next item until you’re 95% confident this one is done“ го спира да прескача счупена стъпка.

Спри го рано

В момента, в който тръгне накриво — Esc и питай наново. Всеки токен, похарчен в грешната посока, е контекст, който не се връща.

Не приемай „става“

„Работи, но направи по-елегантна версия“ е напълно валиден промпт. Когато вторият опит е този, който си искал, запиши защо — в CLAUDE.md или в съответния skill — за да не питаш два пъти следващия път.

ultrathink

Ако напишеш ultrathink в промпта, бюджетът за мислене се вдига, преди Claude да отговори. Струва си за архитектурни решения, зле възпроизводими бъгове и големи рефакторинги — или когато два обикновени опита не са уцелили. Не си струва за поправка от един ред; така или иначе плащаш токените за разсъждение.

Управление на контекста

/clear между несвързани задачи

Нова задача, която няма нищо общо с предишната — /clear. Останките от предишната работа объркват модела. CLAUDE.md се зарежда отново, така че не губиш конвенциите.

/compact при дълъг контекст

Същата работа, но сесията е станала дълга — /compact. Дай му и инструкции какво да запази: /compact запази решенията по схемата и списъка с останали задачи.

Не чакай да свърши контекстът

Компактирането по средата на сложна стъпка губи повече, отколкото ако го направиш по-рано, на естествена граница между задачите.

@ вместо „намери файла“

Прякото споменаване на файл спестява цикъл от търсене и слага в контекста точно това, което трябва.

Това е кратката версия. Контекст и цена отива по-нататък — защо дългата сесия става и по-скъпа, и по-неспособна, защо /rewind бие „не стана, пробвай пак“ и кой е handoff моделът, който замества /compact.

Кеширай документацията, която четеш пак и пак

Когато знаеш, че ще се връщаш към една и съща документация — feature, който въвеждаш, API на голям MCP сървър, библиотека, която учиш — накарай Claude да я прочете веднъж и да запише резюмето в проекта:

Read https://code.claude.com/docs/en/agent-teams and write a reference guide
for it in docs/agent-teams.md. It'll be used to answer questions about this
feature later, so keep the configuration details and the examples.

Всеки следващ въпрос след това чете локален файл, вместо пак да тегли страницата — по-бързо, по-евтино и оцелява след /clear. Насочи CLAUDE.md към папката („reference docs live in docs/“), за да знае Claude да гледа там, преди да посегне към мрежата.

Git worktrees за паралелни сесии

Няколко Claude сесии в една и съща директория си пречат — редактират едни и същи файлове и се объркват взаимно. Решението са git worktrees: отделна работна директория за всеки branch.

Claude Code сам ще ти направи такъв:

claude --worktree feature-auth    # или -w

Това създава изолирано работно пространство на собствен branch и стартира сесията в него. Пусни го пак в друг терминал с друго име и имаш две сесии по един проект, които не могат да се презапишат. Добави --tmux, за да се отвори в tmux сесия. Накрая branch-овете се сливат обратно като всеки друг.

Ръчният вариант, ако искаш директориите на конкретно място:

git worktree add ../proj-feature-auth -b feature/auth
git worktree add ../proj-bugfix-123 -b fix/issue-123

Тогава пускаш claude във всяка директория поотделно. И в двата случая сесиите са напълно изолирани — общ е само .git.

Когато приключиш:

git worktree remove ../proj-feature-auth

Субагенти за големи задачи

Субагентът работи в собствен контекст и връща само резултата. Междинните стъпки — прочетените файлове, неуспешните опити, дългите output-и — не влизат в твоята сесия.

Кога си струва:

Ситуация	Защо субагент
„Намери къде се случва X“ в голямо репо	Търсенето чете много файлове; ти искаш само отговора.
Няколко независими промени наведнъж	Пускат се паралелно, вместо една след друга.
Изследване с неясен изход	Ако не открие нищо, си спестил замърсяването на контекста.
Ревю на голям diff	Изолиран контекст, изолирано мнение.

Управляват се с /agents; дефинициите живеят в .claude/agents/.

Субагентът не е длъжен да върти същия модел като сесията ти. За работа с голям обем, но без много нюанс — четене на много файлове, събиране на данни, първоначално пресяване — сложи субагентите на по-евтин модел и остави основната сесия на скъпия. Плащаш ниската ставка за токените, които се изчитат, и високата само за резюмето, което се връща.

Накратко

Преди задачата

CLAUDE.md е актуален, plan mode за големи неща, worktree ако ще въртиш паралелно.

По време на задачата

Esc Esc при грешна посока, /compact при дълъг контекст, субагент за странични разклонения.