Claude Code – команди, настройки, флагове

Здравейте!

Това е справочник. Не разказ как се работи правилно с агента – за това имам отделна статия – а списък: какво може да се въведе, какво може да се запише в настройките, кое какво прави и как изглежда на практика.

Актуалност: август 2026. Списъците с команди, ключове и флагове са снети от билд 2.1.251, а онова, което можеше да се провери със стартиране, е проверено на 2.1.252. За техническа статия версията е по-важна от обикновено: между съседни билдове командите изчезват, сменят имената си и си разменят местата. Ако вие имате друга версия, /help и claude --help винаги са прави, а аз – само към момента на писане.

Изходът от конзолата в примерите е истински: или е снет от работещ билд, или е взет от официалната документация. Където не успях да намеря реален изход, няма никакъв, а какво ще се случи след командата, е описано с думи – измислени екрани в статията няма да има.

Три места, където се въвеждат команди

Преди да прелистите таблиците, полезно е да разберете, че повърхностите са три и не се застъпват.

Слеш командите се въвеждат вътре в работеща сесия, със / в началото на реда. Те управляват разговора: смяна на модела, свиване на контекста, връщане на промени, стартиране на ревю. В терминала не работят.

settings.json е файл на диска. Той определя с какво състояние ще стартира Claude Code: кой модел, какви права имат инструментите, какви хукове, какво да се показва в статус реда. Значителна част от настройките съществуват само тук и нямат команда-еквивалент.

Терминалните команди claude се въвеждат в обикновената командна обвивка, преди сесията или извън нея: инсталиране, автентикация, MCP сървъри, плъгини, фонови агенти, неинтерактивно стартиране за скриптове.

Разделението не е декоративно. Половината от въпросите от рода на „защо не работи“ се обясняват с това, че човек е написал /model в терминала или --effort във файла с настройки. Има обаче и приятно изключение: в неинтерактивния режим claude -p слеш командите в текста на промпта работят – за това по-нататък има отделен раздел.

Слеш команди

Въвеждат се вътре в работеща сесия, със / в началото на реда. За всяка команда по-долу всичко е събрано накуп: аргументи с всички стойности, тънкости и примери.

Обозначения: [Скил] – вграден скил, тоест готов сценарий-промпт; [Воркфлоу] – вграден мултиагентен воркфлоу; [извън плана] – плаща се с кредити отделно от абонамента; [не във всички планове] – наличността зависи от плана, организацията или доставчика; [няма в документацията] – има го в билда, а в публичните източници не е описано.

За примерите. В блоковете е онова, което реално се въвежда, с истински аргументи, а не голото име на команда. Изходът е показан там, където е могло да се вземе от работещ билд или от официалната документация; той е на английски, защото така се отпечатва. Където достоверен изход няма, няма го и тук, а какво ще се появи на екрана и между какво ще трябва да се избира, е казано с думи в описанието на командата. Измислени екрани в статията няма да има.

Командите, които в този билд са изключени или напълно премахнати, нямат свои раздели – събрани са в таблица в края на този раздел.

Сесии и разговор

Четирите команди от тази група правят сходни неща и постоянно се бъркат. Разликата е в това какво се копира и къде се появява резултатът:

/clear [име]

Започва нов разговор с чист контекст. Псевдоними: /reset, /new. Прибягвате към нея при преминаване към друга задача: старият контекст престава да помага и започва да пречи – моделът продължава да тегли в отговорите подробности от предишната работа.

Старият разговор не се изтрива – остава на диска и се отваря чрез /resume. Незадължителният аргумент му дава име в списъка: без име след седмица ще гледате десетина безименни реда.

Ако сте изчистили случайно, в същия процес това се отменя: в менюто на /rewind има запис за предишната сесия, който изглежда като /resume <id> (previous session).

Струва си да помните и цената: /clear не струва нищо, докато /compact е голяма заявка с целия контекст. Ако разговорът вече не ви трябва, изчистването е по-евтино от свиването с целия обем на прозореца.

/clear                                    # нов разговор с чист контекст
/clear експеримент с опашки, не се получи  # същото, но предишният разговор е подписан с тази фраза

/resume [id или фраза за търсене]

Връща ви към минал разговор. Псевдоним: /continue. Нужна е, когато работата е била прекъсната и искате да продължите не от нулата, а с целия натрупан контекст – или когато трябва да извадите отдавнашно обсъждане, за да си спомните докъде сте стигнали тогава.

Списъкът е вързан към работната папка: разговор от друг проект в него няма да се появи. А по идентификатор сесията се отваря от всяка папка на машината – до версия 2.1.223 се е търсело само в текущия проект и в неговите работни копия. За скриптове това е удобно: взели сте session_id от изхода на claude -p --output-format json и сте продължили от където и да е.

Транскриптите се чистят по cleanupPeriodDays, по подразбиране след тридесет дни. Ако смятате да се връщате към стари разговори, вдигнете стойността предварително – няма откъде да се възстанови изтритото.

Терминални форми: claude -c продължава последния разговор на папката без избор (фоновите сесии пропуска), claude -r отваря същия избор преди старта на сесията, claude -r <id> --fork-session продължава стар разговор с нов идентификатор, като оставя изходния недокоснат.

В списъка избирате кой от минали разговори да продължите: всеки ред е отделна сесия на тази папка със свой надпис и време. Избраният се отваря изцяло, с цялата кореспонденция и контекст, и пишете в него нататък, сякаш нищо не се е случвало.

/resume                    # избор от последните разговори на тази папка
/resume 8f3c1d2e-4b5a-...  # отваряне веднага по идентификатор, без избор
/resume дедлок в пула      # търсене по съдържание; избор от съвпадналите разговори

/branch [име]

Разклонява разговора от текущата точка; оригиналът се запазва изцяло.

Това е като запис на играта преди срещата с боса. Намирате се в точка, в която не е ясно кой от двата подхода е по-добър; разклонявате се, пробвате първия и ако не се получи – връщате се в оригинала чрез /resume и пробвате втория, без да влачите в контекста неуспешния опит. Името е незадължително, но с него по-късно е по-лесно да намерите нужния клон в списъка.

След командата се оказвате в разклонението и пишете нататък вече в него; изходният разговор остава цял и се отваря чрез /resume.

/branch                            # разклоняване от текущата точка
/branch опитай-през-опашка         # същото, разклонението е подписано с това име

/fork [задача]

Копира разговора във фонова сесия, която работи по задачата паралелно с вас.

Това е „нека някой се заеме с това, докато аз правя своето“. Копието получава целия натрупан контекст; резултата ще вземете, като се свържете с него чрез claude attach или екрана claude agents. Започвайки от 2.1.221, на копието освен това е наредено да си създаде собствено работно копие на git, преди да променя код – за да не си пречат двата агента в едно и също дърво.

Внимавайте с чужди инструкции. Във версиите от 2.1.161 до 2.1.211 онова, което сега се нарича /subtask, се наричаше /fork, а имената се разменят в 2.1.212. Статия или скрипт, писани преди това, имат предвид точно обратното. Плюс частен случай: ако екранът на агентите е изключен, /fork се връща към старото поведение и работи като субагент.

Имайте предвид и разхода: копието е пълноценна втора сесия със свой контекст и докато работи, лимитът се харчи едновременно с вашия.

Копието се създава веднага и получава свой идентификатор – той е нужен, за да се свържете с него по-късно. Със задание то се залавя за работа незабавно, без задание просто чака указания.

/fork събери бележките към изданието по комитите от предишния таг  # копието работи паралелно с вас
/fork                                                              # копието чака указания

/subtask <задача>

Изпраща субагент с вашия контекст; резултатът се връща в същия разговор.

Това е „иди да видиш и се върни“. Разликата от /fork е принципна: шумната част от работата – четене на двадесет файла, дълги листове с изход – остава в контекста на субагента, а при вас идва само изходът. Основният начин да не запушвате основния контекст с разузнаване.

Изисква версия 2.1.212; преди нея тази команда се наричаше /fork. При изключен екран на агентите е недостъпна.

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

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

/subtask намери всички извиквания на този метод                                          # разузнаване без боклук в контекста
/subtask прочети миграциите за месеца и кажи какво се е променяло в схемата на поръчките  # същото за дълго четене

/background [промпт]

Изпраща текущата сесия на фон и освобождава терминала. Псевдоним: /bg.

Нищо не се копира – на фон отива самата тази сесия, работата продължава. С аргумент ѝ давате и задание за из път. Връщате се после чрез claude attach или екрана claude agents; спира се с /stop или claude stop <id>. Прибягва се към нея, когато задачата е дълга, а терминалът ви трябва веднага.

Терминалът се освобождава веднага, а сесията остава да живее на фон под свой идентификатор – по него се връщате при нея.

/background                           # отиване на фон и освобождаване на терминала
/bg догони билда и оправи линтера     # същото, плюс задание за из път

/rename [име]

Преименува сесията. Псевдоним: /name [няма в документацията]. Смисълът е чисто практичен: когато отворените и фоновите разговори станат много, те трябва да се различават по име, а не по идентификатор.

Името се вижда в реда за въвеждане, в списъка на /resume и в заглавието на раздела на терминала. Без аргумент се генерира по темата на разговора.

С въведеното име стават три неща: управляващите и невидимите символи се заменят с интервали, дължината се отрязва до двеста знака, а ако след почистването не е останало нищо, името се отхвърля като празно. Ако такова име вече е заето от друга жива сесия на тази машина, ще се приложи негов вариант – не е грешка, просто името ще е малко по-различно.

Заглавието на терминала се сменя, ако е включено terminalTitleFromRename (по подразбиране – да); да се забрани изобщо пипането на заглавието може с променливата CLAUDE_CODE_DISABLE_TERMINAL_TITLE.

/rename                         # името се измисля по темата на разговора
/rename рефакторинг на плащането  # името е зададено ръчно

/cd <път>

Премества сесията в друга работна папка. Полезна е, когато работата се е преместила в съседна услуга или хранилище, а не искате да зарязвате разговора.

Настройките, хуковете, MCP сървърите, скиловете и агентите на новата папка започват да действат веднага, а не след рестарт, и блокът env на новата папка се наслагва върху стария. С това /cd се различава от /add-dir, която дава достъп до файловете, но не и до конфигурацията.

/cd ../backend  # преместване в съседното хранилище заедно с неговата конфигурация

/recap

Свива цялата сесия до един ред-резюме – бързо да си спомните за какво е ставало дума. Полезна е след почивка и в дълъг разговор, където началото вече е излязло извън екрана. Контекстът при това не се пипа: това е просто кратка извадка като отговор, а не свиване на разговора, с което се занимава /compact.

/recap  # за какво е този разговор и до какво се е стигнало в него

/btw [въпрос]

Задава кратък страничен въпрос, без да замърсява основния контекст: отговорът не се примесва в по-нататъшната работа. Това е за „а как се казва това нещо“ насред задача – за да не гради моделът след десет съобщения разсъждения около случайно зададен въпрос.

Без въпрос отваря предишните ви странични въпроси, за да прелистите отговорите; до версия 2.1.212 въпросът е бил задължителен.

/btw с какво се различава grpc-web от grpc  # отговорът е видим за вас, но минава встрани от по-нататъшния контекст
/btw                                         # връщане към предишните странични въпроси

/export [файл]

Изнася разговора във файл или в клипборда. Обикновено е нужно, за да приложите кореспонденцията към задача, да я препратите на колега или да запазите разбор, към който ще се върнете.

Без аргумент целият разговор отива в клипборда, с аргумент се записва във файл; ~ се разгъва. Форматът е текстов, с разметка на ролите: това е транскрипт за човек или за подаване на друг инструмент, а не машинен формат за импортиране обратно.

/export                    # целият разговор в клипборда
/export ~/logs/session.md  # същото, но във файл

/copy [N]

Копира в клипборда един отговор: без аргумент последния, с число – N-тия от края. Нужна е, когато от голям отговор трябва да вземете част в редактора или в тикета и не ви се иска да маркирате с мишката половин екран.

Броят се отговорите на асистента, а не редовете на екрана, затова /copy 2 означава „предпоследният отговор“. Малко известно: ако в отговора има блокове код, се отваря избор – може да вземете отделен блок, а не цялото съобщение. И точно там клавишът w записва избраното във файл вместо в клипборда; по SSH, където клипбордът е безполезен, това е единственият работещ начин.

Изборът в този списък е между цялото съобщение и всеки отделен блок код от него; избраното веднага отива в клипборда, а при w – във файл.

/copy    # последният отговор в клипборда
/copy 2  # предпоследният; ако в него има код, първо ще ви предложат да изберете блок

/stop

Спира текущата фонова сесия. Транскриптът и работното копие се запазват. Нужна е, когато фоновата работа е тръгнала накриво или вече не е нужна: сесията наистина преустановява работа, а не просто се отделя, както при /exit. Отвън същото прави claude stop <id>.

/stop  # спиране на фоновата сесия, транскриптът и работното копие остават

/exit

Излиза от CLI. Псевдоним: /quit. Във фонова сесия – отделя се, самата сесия продължава да работи.

/exit  # изход от CLI; във фонова сесия – само отделяне

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

/context [all]

Показва с цветна мрежа с какво е запълнен контекстът, плюс съвети какво може да се разтовари. Аргументът all разгъва подробностите: кои точно файлове и колко заемат. Прибягвате към нея, когато сесията е натежала осезаемо или е на път да премине в автосвиване: командата показва кой точно е заел прозореца, а от това зависи с какво се лекува. Не я бъркайте с /usage: тя е за лимитите на плана, а тази – за прозореца на текущата сесия.

Всяка клетка на мрежата е парче от контекстния прозорец, оцветено по източник. Смисълът не е в красотата: източниците се държат различно и се лекуват различно.

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

Нататък има развилка. Историята се е раздула – /compact. Раздули са се прочетените файлове – /clear и започвате отначало. Раздули са се описанията на инструменти и скилове – това се лекува с настройки, а не с команди: в следващата сесия контекстът ще е точно толкова раздут.

/context                                # с какво е зает контекстът в момента

Context Usage
Opus 5 (1M context)
claude-opus-5[1m]
138.8k/1m tokens (14%)

Estimated usage by category
  System prompt:    4.4k tokens  (0.4%)
  System tools:      21k tokens  (2.1%)
  MCP tools:         265 tokens  (0.0%)
  Memory files:     3.2k tokens  (0.3%)
  Skills:           6.2k tokens  (0.6%)
  Messages:       104.2k tokens (10.4%)
  Free space:      860.7k       (86.1%)

MCP tools · /mcp (loaded on-demand)
└ 126 tools · 265 tokens

Memory files · /memory
└ 1 file · 3.2k tokens

Skills · /skills
└ 48 skills · 6.2k tokens

/context all to expand

 Suggestions
 ℹ File reads using 76.1k tokens (8%) → save ~22.8k
   If you are re-reading files, consider referencing earlier reads.
   Use offset/limit for large files.

/context all                            # същото, с разбивка по всеки файл

Изходът по-горе е дословно копие на реална сесия на Opus 5 с прозорец от милион токена.

/compact [инструкции]

Свива историята на разговора до резюме, освобождавайки място. Аргументът не е флаг и не е филтър, а инструкция към съставителя на резюмето: на какво да обърне внимание, какво не бива да се загуби. Нужна е, когато прозорецът е почти пълен, а е рано да зарязвате разговора: работата ще продължи от същото място, но нататък ще се опира на преразказ.

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

Без да пита нищо, командата свива историята и отчита с един ред; самото резюме по подразбиране е свито и се разгъва с отделно натискане. С аргумент външно нищо не се променя – разликата е само в това, какво е задържано вътре в резюмето.

Самото свиване е скъпа заявка: в нея отива целият контекст. /clear не струва нищо. Ако разговорът вече не ви трябва, втората команда е по-евтина от първата с целия обем на прозореца.

Прагът, при който контекстът се свива сам, се управлява с /autocompact.

/compact                                # свиване на историята както се получи

⎿ Compacted (ctrl+o to see full summary)

/compact запази решенията по схемата на базата данни     # свиване, но без да се загуби тази линия

/compact остави само онова, което се отнася до модула за плащане

Редът на отчета е приведен дословно, снет е на билд 2.1.220.

/autocompact [auto|<токени>]

Настройва при какво запълване контекстът започва да се свива сам. Командата се появи в 2.1.221. Прагът е компромис: колкото е по-висок, толкова по-дълго живее пълната история, но толкова по-близо сте до тавана на прозореца; колкото е по-нисък, толкова по-често разговорът се превръща в преразказ. Към командата се прибягва, когато свиването се задейства не навреме – твърде рано и отнася нужното, или твърде късно и опира в тавана.

Стойности извън диапазона не се приемат. Постоянният еквивалент е ключът autoCompactWindow, автосвиването се изключва изцяло с autoCompactEnabled: false, има и флаг за стартиране --autocompact със същите стойности. Отделната настройка precomputeCompactionEnabled подготвя свиването предварително, докато върви обичайната работа – когато прагът бъде достигнат, паузата ще е по-кратка; работи само при включено автосвиване.

Диалог командата не отваря: без аргумент просто показва действащия праг, с аргумент – приема нов или отказва, ако числото е извън допустимия диапазон.

/autocompact                            # преглед на текущия праг

/autocompact auto                       # нека се подбира сам

/autocompact 400000                     # свиване при достигане на 400k токена

/memory

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

Кои от тях се зареждат, показва /context, а да ги приведе в ред умее /doctor: той чисти дубликатите, пренася рядко нужното в отделни файлове, зареждани при поискване, и изрязва онова, което агентът така или иначе ще изведе от кода.

/memory                                 # отваряне на файловете с памет за редакция

/init

Създава CLAUDE.md: агентът ще огледа хранилището и ще опише структурата и командите му. [Скил] Прибягвате към нея в хранилище, с което агентът още не е работил; вече съществуващ файл обикновено е по-бързо да се поправи на ръка през /memory, отколкото да се генерира наново.

CLAUDE.md е файл с инструкции, който се примесва в контекста на всяка сесия.

След като е сработила успешно, командата не отпечатва нищо. Документацията съветва резултатът да се провери в следващата сесия: извикайте /context и се уверете, че CLAUDE.md се е появил в раздела Memory files.

Малко известна променлива: CLAUDE_CODE_NEW_INIT=1 включва интерактивния вариант, който води не само през инструкциите на проекта, но и през скиловете, хуковете и личните файлове с памет. А ако в папката се намери конфигурация на друг кодинг агент, която /import умее да пренася, ще ви предложат да я вземете.

/init                                   # генериране на CLAUDE.md по хранилището

CLAUDE_CODE_NEW_INIT=1 claude    # интерактивен /init със скилове и хукове

/add-dir <път>

Добавя още една работна директория, за да вижда агентът файлове извън папката на проекта. Нужна е, когато работата не се побира в едно хранилище: съседна услуга, обща схема, изнесена библиотека – без това агентът просто няма да ги прочете.

Важна тънкост: тя дава достъп до файловете, а не до конфигурацията – хуковете и настройките на тази папка не се вземат. Единственото изключение са скиловете и командите: те се вземат от добавената папка. Да преместите сесията изцяло в друга папка, заедно с настройките и хуковете ѝ, е /cd, а не /add-dir.

/add-dir ../shared-protocol             # пускане на агента в съседното хранилище

/rewind

Връща кода и/или разговора към контролна точка или свива част от разговора. Псевдоними: /checkpoint, /undo. Нужна е, когато серия промени е завела накриво и да разберете какво точно е натворил агентът отнема повече, отколкото да се върнете една стъпка назад.

Първото, което трябва да знаете: командата не работи винаги. Копията на файловете се снемат преди промяна само ако е включено fileCheckpointingEnabled. Изключено е – няма какво да се възстановява.

Второто: менюто се отваря не само с команда. Двойно Esc в празен ред за въвеждане прави същото. Ако в реда има текст, двойното Esc го изчиства – затова първо изчистете реда.

В менюто има шест пункта и половината от тях не са за връщане:

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

Изборът тук е двустъпков: първо точката, към която се връщате, после едно от шестте действия над нея. От връщанията най-често е нужно „възстановяване на код“: промените са тръгнали накриво, но обсъждането, от което са поникнали, е ценно и да се загуби е глупаво.

Граници, които е добре да знаете, преди да са ви потрябвали. Пазят се сто последни контролни точки, а заедно със сесията се изтриват след тридесет дни – същият cleanupPeriodDays. Не се възстановява: онова, което са направили стартираните команди на командната обвивка, повечето промени на субагенти, промените, внесени отвън, и всичко, до което се стига през символни и твърди връзки. Тоест базата данни, изтрита от миграция, няма да се върне, git reset няма да се отмени, инсталираните пакети ще останат. Това е отмяна на последните промени, а не система за контрол на версиите и не замяна на комитите.

Възстановяването на код не винаги е пълно: ако на файла от момента на точката му се е сменил типът или директорията, той ще бъде пропуснат, а сесията отделно ще съобщи колко файла не е докоснала.

/rewind                                 # меню за връщане и свиване

Модел и производителност

/model [модел]

Сменя модела и запомня избора. [извън плана] плаща не самата команда, а част от онова, което с нея може да се избере: Fable 5 и вариантите с контекстен прозорец от милион токена в редица планове се таксуват с кредити извън абонамента и без включени кредити тези редове в списъка не работят. Без аргумент се отваря списък с наличното. Към командата се прибягва, когато се е сменил характерът на работата: тежък разбор има смисъл да се води на най-силния модел, а поток от дребни промени – на бърз и евтин.

Изборът се запомня и преживява рестарт – с това /model се различава от променливата ANTHROPIC_DEFAULT_MODEL, която той замества.

Положение към август 2026. Актуалните модели са Opus 5, Sonnet 5, Fable 5 и Haiku 4.5. Haiku 5 не съществува: псевдонимът haiku продължава да сочи към 4.5 и това редовно заблуждава хората при четене на примери с fallbackModel.

Какво стои зад псевдонима, зависи от доставчика, и това е неочевидна подробност за онези, които работят през облака. На собственото API sonnet е Sonnet 5, в Amazon Bedrock и Google Cloud – Sonnet 4.5, в Microsoft Foundry opus е изобщо Opus 4.6. Една и съща конфигурация при два доставчика дава различни модели.

Всичко това се настройва по три начина. Какво стои зад псевдонимите – с променливите ANTHROPIC_DEFAULT_OPUS_MODEL и сродните им (за best такава променлива няма). Самият списък за избор – с ключа modelPicker: в него се дописват свои редове с надписи, включително идентификатори на Bedrock и Vertex, а replaceBuiltInOptions заменя вградения списък изцяло. Отгоре всичко се ограничава от корпоративния availableModels; от версия 2.1.205 псевдонимът на семейство при това не се отхвърля, а се разрешава в най-новия разрешен модел.

Отделно живее fallbackModel – списък с модели, към които Claude Code ще превключи сам, ако основният е претоварен. Това не е смяна на вашия избор, а застраховка за времето на недостъпност.

Какво точно се таксува отделно. При Fable 5 разчетът с кредити зависи от плана и от типа място в организацията; там, където действа, в списъка на този ред има бележка, че са нужни кредити, а преди първата такава заявка Claude Code веднъж ще поиска потвърждение. В неинтерактивния режим (-p) и през Agent SDK този въпрос го няма – таксуването ще стане тихо. С прозореца от милион токена картината е друга: при Sonnet 4.6 той изисква кредити във всеки абонаментен план, включително Max; при Opus – само в Pro, а в Max, Team и Enterprise влиза в плана без никаква настройка. При Sonnet 5 на собственото API прозорецът от милион токена е винаги включен и не изисква кредити.

В списъка избирате между семействата и конкретните версии: вижда се кое е налично във вашия план и при кои редове има изискване за кредити. С аргумент списъкът не се отваря – моделът се сменя веднага. Избраният модел се прилага към текущата сесия и остава избран и следващия път.

/model                # избор от наличния списък
/model opus           # по псевдоним
/model opusplan       # планиране с Opus, изпълнение със Sonnet

/effort [ниво|auto|status]

Нивото на усилия задава колко моделът мисли над хода. Това не е същото като избора на модел: моделът определя кой мисли, усилията – колко. Практическият смисъл е да търгувате време и разход на токени срещу качеството на хода: при очевидна промяна дълбоките разсъждения само забавят работата, а при заплетен дефект икономията върху тях води до погрешна диагноза.

Четири неочевидности.

max не може да се запази в настройките. Ключът effortLevel приема само стойности до xhigh. Максимумът се задава за сесията – с команда или с флага --effort max – и нарочно не остава включен завинаги. Така е устроен и ultracode: командата и флагът работят, а сред изброените в схемата стойности него го няма; постоянно се включва с отделен булев ключ ultracode.

Нивото се помни по модел. От версия 2.1.248 всеки модел има свое запазено ниво: превключили сте на друг – получавате неговата настройка, а не последната ви.

Други команди го отменят. /code-review high повишава усилията за хода, /code-review low ги понижава, дори сесията да е вървяла на xhigh.

Думата ultracode работи направо в текста на промпта – по подразбиране е достатъчна, за да включи оркестрацията за един ход; за това отговаря workflowKeywordTriggerEnabled. Ако е сработила случайно, отменя се на място с Alt+W (на macOS Option+W). За да стартирате веднага с нея: claude --effort ultracode.

Отделно за разхода при ultracode. Извън плана не се таксува, но една ваша заявка се разгръща в няколко воркфлоу подред, а всеки воркфлоу ражда агенти – лимитът на плана при това се топи забележимо по-бързо, отколкото при обикновена сесия. Предупреждението за голямо изпълнение, което Claude Code показва, когато са планирани повече от 25 агента или прогнозата надхвърля милион и половина токена, в режим ultracode не се извежда: включвайки го, вече сте се съгласили на големи изпълнения. В плана Pro оркестрацията на воркфлоу първо трябва да се включи в /config.

Още в 2.1.251 поправиха един частен случай, на който лесно се попада: Opus 5 отказваше да работи с xhigh и max, ако разсъжденията са изключени. Сега при такава комбинация усилията просто се изпращат като high.

С аргумент нивото се превключва на място, за текущата сесия; status нищо не променя и само показва действащото ниво.

/effort status     # какво е нивото сега
/effort low        # евтино и бързо
/effort ultracode  # xhigh плюс постоянна оркестрация на воркфлоу

/fast [on|off]

Fast режим: същият модел, но с ускорено генериране на отговорите. [извън плана] безплатна норма няма – режимът винаги се плаща с кредити извън абонамента, дори лимитът на плана още да не е изчерпан, а докато кредитите не са включени, командата ще съобщи, че са нужни, и нищо няма да превключи. Към него се прибягва там, където чакането е по-скъпо от плащането: диалогово дебъгване, дълга серия дребни промени, демонстрация на живо. Това не е друг модел и не е друго ниво на усилия – това е режим на предоставяне на отговора.

Цената на ускорението при Opus 5 и Opus 4.8 е 10 долара за милион входни токена и 50 за милион изходни, еднакво върху целия прозорец от милион токена; това е по-скъпо от обичайните ставки на Opus. Има неприятна тънкост при първото включване насред диалог: целият вече натрупан контекст се преизчислява по пълната цена на входа на fast режима, затова е по-евтино да го включите в началото на сесията, а не на сотия ход. Ако кредитите свършат по средата на работата, нищо няма да се счупи – Claude Code ще повтори отхвърлените заявки с обичайна скорост и по обичайна цена. В Claude Console кредити няма изобщо: организацията плаща за токените заедно с останалия разход за API. В Amazon Bedrock, Claude Platform на AWS, Google Cloud Agent Platform и Microsoft Foundry режим няма.

Съседни ключове в настройките: fastMode го включва постоянно, а fastModePerSessionOptIn кара всяка сесия да стартира без него, дори да сте го включвали миналия път.

/fast on   # ускорен изход
/fast off  # връщане към обичайния режим

/brief

Режим „само накратко“: максимално сбити отговори без разгърнати обяснения. Аргументи командата няма. Полезно е, когато водите работата сами и от агента ви трябва резултат или кратък факт, а не разбор с примери. Върху обема на самата работа и върху дълбочината на разсъжденията това не влияе – съкращава се само онова, което ви се отпечатва; за дълбочината отговаря /effort.

/brief  # отговаряй максимално кратко

/advisor [модел|off]

Съветник: по-силен модел подсказва на основния агент в ключови моменти. [не във всички планове] нужен е достъп до собственото API на Anthropic – по абонамент или през Console; в Amazon Bedrock, Claude Platform на AWS, Google Cloud Agent Platform и Microsoft Foundry съветник няма и му е нужно включено получаване на флагове за възможности. Смисълът е да не плащате за силния модел през цялата сесия, а да го викате точково. Възможността е експериментална и да се води работен процес върху нея засега е рано.

Вторият модел се намесва не постоянно, а в ключови точки – когато основният агент взема решение, при което грешката струва скъпо. Аргументът е псевдоним или пълен идентификатор на модел; off изключва. Без аргумент се отваря избор. Има и флаг за стартиране --advisor <модел>, който, между другото, го няма в изхода на claude --help.

Разходът на съветника се взема от обичайния лимит на плана – с едно изключение: ако за съветник е назначен Fable 5, работата му се плаща с кредити там, където с кредити се плаща обичайното използване на Fable 5. Докато съгласието за такова таксуване не е дадено чрез /model fable, Claude Code просто няма да назначи Fable за съветник.

Без аргумент се отваря същият списък с модели, но в него избирате не работния модел, а помощника: основният модел остава предишният, избраният се включва върху него.

/advisor       # избор на съветник от списъка
/advisor opus  # съвети от Opus
/advisor off   # изключване на съветника

/plan [open|share|описание]

Режим на планиране: агентът чете, анализира и предлага план, но нищо не променя – промените във файлове и опасните команди са недостъпни. Излизането от режима става чрез приемане на плана; след него сесията се връща в обичайния режим и започва да го изпълнява. Нужен е там, където цената на погрешно разбрана задача е по-висока от времето за съгласуване: преди голяма преработка, в непознат код, когато промяната се разпростира върху десетина файла.

Файловете с планове се намират в ~/.claude/plans/, ако не е зададен plansDirectory – с него се пренасят в хранилището на проекта, за да се обсъжда и версионира планът заедно с кода.

В диалога за приемане на плана има опция „изчисти контекста“: планът остава, а цялото разузнаване, върху което е построен, се изхвърля. Показва се само при showClearContextOnPlanAccept, по подразбиране е изключена, и при дълги задачи това е една от най-полезните настройки – изпълнението започва с чист прозорец.

Режимът е достъпен и от самото начало: claude --permission-mode plan. И отделно е добре да знаете, че авто режимът по подразбиране действа и вътре в планирането; изключва се с ключа useAutoModeDuringPlan.

Готовият план се показва заедно с диалога за приемане и в него трябва да избирате от три варианта. „Yes, and use auto mode“ – приемане и продължаване в авто режим; там, където авто режимът е недостъпен, същият ред се нарича „Yes, auto-accept edits“, а в сесия, стартирана със заобикаляне на разрешенията – „Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session“. „Yes, manually approve edits“ – приемане, но потвърждаване на всяка промяна ръчно. „No, keep planning“ – оставане в планирането и казване какво да се поправи. Така е описано в документацията.

/plan                                      # влизане в режим на планиране
/plan изнеси плащането в отделна услуга    # влизане веднага със задача
/plan share                                # споделяне на плана

/goal [условие|clear]

Задава условие, при което работата се смята за завършена; агентът продължава сам, докато то не се изпълни, вместо да спира след всеки ход. Това променя ритъма: ходът не ви се връща на всяка стъпка и се налага да се намесвате само ако нещо е тръгнало накриво. Смислено е при дълга механична работа – да доведете билда до зелено, да прокарате една и съща промяна през целия проект.

Условието трябва да е проверимо – команда, състояние на файл, признак в изхода. Размитото „докато не стане добре“ се превръща в безкрайна работа, защото няма с какво да се провери.

Отделна статия от разходите, за която малцина се сещат: докато целта е активна, агентът периодично се събужда и проверява заседнала фонова работа и всяка такава проверка е пълноценен ход с пълния контекст. Честотата се задава от CLAUDE_CODE_GOAL_CHECKIN_MINUTES, нула изключва проверките изобщо; от версия 2.1.246 те са не повече от три за цел.

/goal докато всички тестове не станат зелени  # работа до изпълнение на условието
/goal                                         # показване на текущата цел
/goal clear                                   # сваляне на целта

Ревю на код и качество

Първите три команди гледат един и същ diff и затова лесно се бъркат, четвъртата изобщо нищо не анализира:

/code-review [ниво|ultra] [--fix] [--comment] [--post|--no-post] [цел]

Ревю на diff за грешки и опростявания [Скил]. Псевдоним: /review. Обичайното локално ревю се брои към лимитите на вашия план, а облачният режим ultra е [извън плана]: в Pro и Max има по три безплатни стартирания, след това се таксува с кредити, обикновено от пет до двадесет и пет долара за ревю, а ако кредитите не са свързани, платеното стартиране просто се блокира. Същият ultra е и [не във всички планове]: нужен е вход в claude.ai, при външни доставчици и в организации с нулево съхранение на данни го няма.

Най-настройваемата от вградените команди: ниво на усилия, четири флага, цел на ревюто и отделен облачен режим – и всяко се разбира по свои правила. Пълната форма е /code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [--post|--no-post] [<PR#>|<клон>|<път>|<бележка>] и всичко в нея е незадължително: голото /code-review е валидно извикване.

Какво търси. Две различни неща. Грешки в коректността: обърнато условие, off-by-one, достъп до null, забравен await, премахната проверка, погълната в catch грешка, счупени места, които извикват променената функция, класически капани на конкретния език. И чистота: нов код, който повтаря вече съществуващото в хранилището; излишна сложност и мъртъв код; излишна работа като повторни изчисления или последователно изпълнени независими операции; „грешно ниво на решение“, когато се слага кръпка там, където е трябвало да се оправи общ механизъм; преки нарушения на правилата от вашия CLAUDE.md.

Грешките в коректността винаги са по-важни от находките за чистота: ако находките са повече от лимита на нивото, първо режат вторите. Самото ревю нищо не поправя, докато не е подаден --fix.

Къде се изпълнява. Обикновено от фонов агент: сесията не се блокира, находките идват с отделно съобщение. В три случая ревюто заема цялата сесия: ако сте го стартирали повторно, докато предишното още върви; ако сте в неинтерактивния режим -p или в SDK; и ако е зададена променливата CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1, която изобщо изключва фоновите задачи.

Кой може да го стартира. Не само вие. При молба „погледни промените ми“ с обикновен текст агентът ще стартира ревюто сам, а и планирана задача с /code-review в промпта също ще сработи. Ако това пречи – да оставите командата въвеждаема, но да забраните на агента и на разписанието да я стартират:

{
  "skillOverrides": { "code-review": "user-invocable-only" }
}

Облачният режим е изключение: ultra агентът не стартира никога, нито сам, нито по разписание.

Редът на аргументите. Три правила, заради които извикването сработва не както се очаква:

1. ultra се разбира само като първа дума. /code-review ultra --fix е облачно ревю, а /code-review --fix ultra е обикновено локално, в което думата ultra е разбрана като цел.
2. Нивото е първата дума, след като от реда са махнати флаговете. Затова /code-review --fix high работи и нивото ще е high.
3. Флаговете могат да се слагат където и да е: в началото, в края, между нивото и целта. Единственото изключение е правило 1.

И четвърто, отделно: тази команда „изяжда“ командата, въведена след нея. Обикновено няколко скила се свързват в едно съобщение и /write-tests /fix-issue 123 ще зареди и двата. Но /code-review /fix-issue 123 от версия 2.1.218 разбира /fix-issue 123 като текст на целта, а не като втора команда. До 2.1.218 е било обратното.

Нива на усилия.

Числата в тази таблица са снети от бинарния файл: официалната документация описва нивата качествено – „ниските връщат най-уверените находки, високите разширяват обхвата и могат да включват по-малко уверени“, – а колко ъгъла на търсене има и какъв е таванът на находките, не публикува никъде.

Точният конвейер зависи от модела на сесията, затова таблицата е за смисъла на нивата, а не за гарантиран брой агенти. При Opus 5 medium и high засега се свеждат до един внимателен проход с лимит от петнадесет находки, а разликите започват от xhigh; при Sonnet 5 на нивата high, xhigh и max броят на търсещите агенти се подбира според размера на diff – от два до осем.

Отделна такса за горните нива няма, но всеки търсещ агент води свой контекст, затова xhigh и max харчат лимита на плана забележимо по-бързо от low. Да въртите max за всяка дребна промяна е най-простият начин да останете без седмичен лимит до сряда.

Запомняне на нивото. Ако нивото не е указано, взема се онова, което сте въвели последния път: то живее между сесиите и в началото на отчета за това ще кажат с ред от вида „използвам high, нивото от миналия път“. Две изключения: ниво, подадено в неинтерактивно стартиране -p, нищо не запомня, а ultra нито чете запомненото ниво, нито го променя. Ако не сте въвеждали нито веднъж, взема се нивото на усилия на текущата сесия. Въведеното ниво заедно с това задава усилията на модела за хода, включително надолу: /code-review low в сесия на xhigh ще ги понижи.

Печатна грешка не чупи извикването: при /code-review higher ще получите предупреждение, че стойността не е разпозната, и предишното или подразбиращото се ниво. Съкращението med се приема като medium.

Флагове.

--fix поправя намереното направо в работното дърво – и грешките, и чистотата. Находката се пропуска, ако промяната променя замисленото поведение, изисква промени далеч извън прегледания diff или изглежда като фалшиво задействане; накрая ще ви кажат какво са пропуснали и защо. При ultra промените се прилагат локално в момента, в който облакът върне резултата.

--comment изисква целта да е pull request. Ако целта не е такава, флагът се игнорира, находките просто се отпечатват и агентът ще ви каже за това. Коментарите тръгват през интеграцията с GitHub, а ако такава в сесията няма – през gh api.

--post не е същото като --comment: един общ коментар вместо забележки по редове и само за облачното ревю. В интерактивна сесия прозорецът за стартиране все пак пита за потвърждение, в неинтерактивен режим публикува веднага по флага. Подаден към обикновеното локално ревю, се игнорира – ще ви напомнят, че там публикува --comment.

--no-post е нужен, за да не виждате изобщо предложението за публикуване. Да се подават и двата едновременно е безсмислено: командата чете само --post, така че --post --no-post все пак ще предложи публикуване.

Целта на ревюто. Без цел се ревюира текущата работа: комитите на клона над неговия upstream плюс незакомитнатите промени. Затова командата има смисъл и преди комит.

В локалното ревю целта се предава на модела като низ и той сам решава какво е: номер на pull request, име на клон, път към файл или папка – или просто пожелание накъде да погледне най-напред. При ultra целта се разбира строго:

Ревю в облака: какво е нужно, колко струва и къде е таванът. ultra стартира фонов агент в Claude Code в уеб: той клонира хранилището в облачен пясъчник (sandbox), прокарва върху diff мултиагентно търсене и изпраща находките с известие във вашата сесия. Отнема минути, през цялото това време можете да работите нататък.

Изискват се git хранилище и GitHub remote, акаунт в claude.ai със свързан GitHub, а за частно хранилище – инсталирано върху собственика приложение на Claude. Недостъпно е при външни доставчици, при изключени незадължителни заявки, в организации с нулево съхранение на данни и при забрана от страна на организацията. Важна подробност: когато режимът е недостъпен, /code-review ultra не пада, а тихо изпълнява обикновено локално ревю – ако сте очаквали облачното, струва си да се уверите, че наистина е стартирало.

Таванът на diff е до петстотин променени файла и осем хиляди променени реда. Твърде голям pull request се отхвърля, а в отказа се посочват действащите лимити, размерът на вашия diff и най-едрите файлове; празен diff също се отхвърля.

Цена: в Pro и Max по три безплатни стартирания – дават се на акаунта еднократно и не се подновяват, – а в Team и Enterprise безплатни няма изобщо. Нататък – от кредитите, обикновено от пет до двадесет и пет долара за ревю в зависимост от размера на промените. Стартирането се брои от момента на старта на облачната сесия: спряно или паднало ревю безплатното стартиране все пак го харчи, а платеното се таксува само за отработената част. Ако кредитите не са свързани, платеното стартиране просто се блокира.

Какво потвърждавате преди старта. Платено облачно стартиране не тръгва тихо: първо ви показват прозорец с оценка на цената и искат да се съгласите с таксуването на кредити – веднъж за разговор. Там, ако е подаден --post, решавате дали да публикувате резултата с коментар в pull request или да оставите находките само при себе си. Докато не потвърдите, облачната сесия не стартира.

От CI. От версия 2.1.218 облачното ревю се стартира неинтерактивно:

claude -p '/code-review ultra'

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

claude ultrareview                       # облачно ревю на текущия клон
claude ultrareview 1234 --post           # ревю на PR, резултатът – коментар в него
claude ultrareview --json                # сурови находки вместо отчет
claude ultrareview dev --timeout 60      # спрямо клона dev, чакане до час

Кодът на изход е 0, ако ревюто е завършило (с находки или без), и 1, ако не е могло да бъде стартирано. --timeout по подразбиране е тридесет минути.

Каноничната форма е /code-review ultra; /ultrareview е нейният псевдоним, достъпен не за всички акаунти, и цялата възможност е отбелязана като изследователска. В статиите често пишат обратното, сякаш основната команда е /ultrareview.

В GitHub Actions. Ревюто има отделен живот в CI и там се настройва не с флагове, а с файл. В корена на хранилището се слага REVIEW.md, който задава правилата: кои пътища и клонове да се пропускат, кои категории находки да не се показват, какво да се смята за важно, как да се държи при повторно ревю на един и същ pull request.

Находките се делят на три нива: важни, дребни забележки и съществували в кода още преди тези промени. Нарушенията на вашите правила от CLAUDE.md попадат в дребните забележки. Проверката винаги завършва с неутрален статус и затова никога не блокира сливането сама – но с последния ред отпечатва брояч на находките в JSON от вида {"normal": 2, "nit": 1, "pre_existing": 0}, по който можете да поставите собствена бариера във вашия си пайплайн.

Какво ще дойде в отговор, зависи от режима: обикновеното ревю изпраща отчет с отделно съобщение, --fix добавя към него промени в работното дърво, --comment отвежда находките с коментари в pull request, а ultra първо ще поиска потвърждение в прозореца за стартиране и едва тогава ще даде връзка към облачната сесия.

/code-review                                   # текущите промени, ниво като миналия път
/code-review high --fix                        # по-дълбоко и веднага поправяне на намереното
/code-review medium --comment 1234             # ревю на PR 1234 с коментари направо в него
/code-review ultra 1234 --post                 # облачно ревю на PR, резултатът – коментар

/simplify [цел]

Намира в променения код опростявания и веднага ги прилага [Скил]. Това е почистване след себе си, когато кодът вече работи: грешки командата не търси изобщо, затова минава по-бързо от ревюто – но и да го замени не може. Прибягвате към нея, когато промяната е успяла да се разрасте: появили са се почти еднакви парчета, свои помощници върху вече съществуващите, излишни междинни слоеве.

Гледа същия diff като /code-review, но търси само чистота и го прави с четири паралелни агента: преизползване на вече написани помощници, опростявания, ефективност и дали това е правилното ниво на абстракция. Грешки не търси по принцип – това е разделение на труда, а не недоработка. И за разлика от ревюто, веднага прилага намереното. Аргументът е незадължителна цел: път, папка или номер на pull request.

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

Историческа клопка: до версия 2.1.147 днешната /code-review се наричаше /simplify и прилагаше промените по подразбиране. Стар скрипт, който е викал /simplify заради търсене на грешки, днес прави съвсем друго.

Да избирате по хода няма да се налага: командата нищо не пита, а в отговор идва списък на приложените опростявания – промените към този момент вече са в работното дърво.

/simplify                                # целият променен код
/simplify src/payments                   # само тази папка

/security-review

Проверява промените на клона за уязвимости. Аргументи няма. Това е трети поглед върху същия diff, но с друга оптика: не „работи ли“ и не „написано ли е спретнато“, а какво оттук може да се изтегли или счупи отвън. Има смисъл да я викате, преди клонът да замине към общото хранилище – особено ако промяната е докосвала автентикация, обработка на потребителски вход или тайни.

Търси инжекции, проблеми с оторизацията и автентикацията, течове на данни, небезопасна работа с тайни и с входни данни.

Единственото изискване, в което се спъват: нужен е remote с име origin – diff се смята спрямо неговия основен клон. Без него командата пада с git грешка за нееднозначен аргумент и това изглежда загадъчно.

В отговор идва списък на намереното: мястото в кода, характерът на проблема и с какво е опасен.

/security-review                         # уязвимости в промените на клона

/diff

Интерактивен преглед на незакомитнатите промени. Аргументи няма. Нищо не анализира, това е прегледник: незакомитнатите промени и, което е по-полезно, diff за всеки ход на агента поотделно. Полезен е, когато агентът е свършил много неща за няколко хода и трябва да се разбере на коя точно стъпка е свърнал накриво – тоест нещо, което си струва да се ползва преди /rewind, а не след него.

Вътре избирате какво да гледате: цялата незакомитната работа наведнъж или един конкретен ход на агента. Излизането от прегледника ви връща в същата сесия и нищо в кода не променя – връщането живее в /rewind, тук го няма.

/diff                                    # преглед на незакомитнатото

Разработка и работни процеси

/run и /verify постоянно се бъркат: и двете са за „проверка на живо“, но отговарят на различни въпроси.

/run

Стартира приложението на проекта и проверява промяната на живо, а не само с тестове. [Скил] Прибягва се до нея, когато по diff нищо не се разбира: сменил се е екран, поведение на форма, изход на команда – просто трябва да видите работещото приложение. Да не се бърка с /verify: тя отговаря за една конкретна промяна, а /run вдига всичко както си е.

Става дума за приложението като цяло: да се вдигне така, както се вдига в този проект, и да ви се даде да го видите. За да знае как точно, е нужен скил за стартиране – създава го /run-skill-generator, веднъж за проект. Без него /run ще се опита да налучка по типа на проекта и при нестандартен билд ще налучка зле.

След извикването вървят обичайните стъпки на билд и старт – записаните в скила или изведени от типа на проекта, – а нататък гледате самото приложение: вдигнало ли се е и прави ли онова, заради което е вдигано.

/run  # стартиране на приложението и гледане с очите

/verify

Потвърждава, че промяната работи: билд, стартиране, наблюдение на поведението. [Скил] Прибягва се до нея веднага след промяна, когато е важно да не повярвате на diff, а да видите резултата. Проверява се именно промяната, а не приложението като цяло – за второто има /run.

Логиката е проста: ревюто проверява, че diff се чете правилно, /verify – че работи правилно.

От версия 2.1.200 командата умее да запише намерената рецепта за проверка в собствен скил .claude/skills/verify/SKILL.md и тогава в корена на хранилището той замества вградения – тоест веднъж сте разбрали как се проверява този проект и нататък това работи за всички.

Важна промяна: от версия 2.1.215 /verify се стартира само от вас. Преди агентът можеше да я извика сам. Същото се случи с /deep-research в 2.1.218. Ако сте чели статия, където пише, че агентът ще се провери сам, тя е остаряла.

Проверката върви докрай сама: билд, стартиране, наблюдение на поведението, – а накрая получавате заключение дали всичко е наред и какво точно е било гледано. Ако рецепта за проверка в хранилището още не е имало, попътно ще ви предложат да я запишете.

/verify  # билд, стартиране, убеждаване, че работи

/run-skill-generator

Създава скил, който умее да стартира приложението на този проект – върху него после работи /run. [Скил] Командата разбира как тук всичко се билдва и стартира и записва намерената рецепта в скил, който се намира в хранилището и работи за всички.

Прави се веднъж за проект.

Работата тук не е мигновена: приложението наистина се вдига от нулата, като се запомня кои команди за инсталиране, променливи на средата и скрипт за стартиране са сработили. Резултатът е файл със скил в хранилището, а не текст в терминала.

/run-skill-generator  # научаване на проекта на командата /run

/batch <инструкция>

Планира мащабна промяна и я изпълнява паралелно в 5–30 изолирани работни копия, всяко от които отваря свой pull request. [Скил] Нужна е там, където една и съща промяна трябва да се внесе на десетки места и всяко място е самостоятелно парче работа. За една промяна в два файла е излишна: разходите за fan-out ще изядат цялата печалба.

Най-тежката от вградените команди и единствената, която по подразбиране ражда десетки агенти. Инструкцията първо се превръща в план – списък с конкретни места, които трябва да се поправят, – а после за всяко място се стартира свой агент в свое изолирано работно копие на git и всеки отваря отделен pull request.

Ключовото тук е изолацията. Агентите променят файлове паралелно и без отделни работни копия биха си пречили. Оттук и изискванията: git хранилище, чисто дърво и настроен gh, иначе няма с какво да се отварят pull request.

Броят на агентите е от пет до тридесет и се извежда от плана, а не се задава от вас: колкото места са намерени, толкова агенти, в рамките на тавана. Ако планът се получи за две места, fan-out не е нужен и командата ще го каже.

Отделна такса за нея няма, но лимита на плана го харчи многократно: двадесет агента са двадесет сесии, всяка със свой контекст.

Добрата инструкция е онази, в която границите на всяко място са очевидни и промените не са свързани помежду си. Лошата е „рефакторирай проекта“: планът ще се получи от размити пунктове, а тридесет агента независимо ще измислят тридесет различни архитектури.

Върху поведението на fan-out влияят настройките worktree: symlinkDirectories пести място на диска, ако проектът има тежки зависимости, sparsePaths ускорява изтеглянето в големи монорепозитории, baseRef определя дали да се разклонява от отдалечения основен клон или от текущото локално състояние.

Редът е такъв: първо ви показват плана и чакат съгласие – това е моментът, в който се решава дали местата са толкова, колкото сте очаквали. След одобрение агентите отиват да работят на фон, а връзките към отворените pull request-и се появяват по мере готовност.

/batch прехвърли всички контролери към новия клиент  # fan-out от изолирани агенти, всеки със свой PR

/batch разнеси общите DTO по модулите, които ги използват  # ако местата са малко, fan-out не е нужен – командата ще го каже

/debug [описание]

Включва дебъг логове за сесията и помага да се разбере проблемът. [Скил] Полезна е, когато не е ясно чия е бедата – ваша или на самия агент: в подробните логове се вижда какви инструменти са извиквани и с какво са отговорили. Логовете се включват до края на сесията, на следващата не се пренасят.

Описанието е незадължително – с него веднага казвате какво точно ловите.

Без описание нещата се ограничават до включване на подробните логове, нататък работите както обикновено. С описание командата веднага се заема с разбора на посочения проблем, опирайки се на онова, което ще се появи в тези логове.

/debug                                           # включване на дебъг логове

/debug пада само на CI, локално е зелено         # същото плюс описание на проблема

/fewer-permission-prompts

Прегледва транскриптите, намира често срещани безопасни извиквания и сглобява от тях списък с разрешения. [Скил] Смисълът е да престанете да потвърждавате по десет пъти на ден едно и също безобидно четене. Командата гледа вашата собствена история, а не общ списък, затова разрешенията излизат за конкретния проект.

Промяната се записва в настройките на проекта, тоест ще действа за всички, които работят с това хранилище.

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

/fewer-permission-prompts  # съставяне на списък с разрешения от историята

/commit [пожелания]

Прави комит: гледа статуса и diff, пише съобщение по приетия формат. [Скил] Форматът на съобщението се извежда от историята на комитите на това хранилище, а не от общи правила – в чужд проект комитът ще изглежда като съседните. Полезна е точно с това, че сваля две скучни стъпки: да решите какво влиза в комита и да формулирате какво, всъщност, сте направили.

Аргументът не са флагове, а пожелания с обикновен текст; това важи и за /pr. Пожеланията влияят върху онова, което ще попадне в комита, и върху това как ще бъде написано съобщението.

Какво ще попадне в съобщението на комита като атрибуция, се задава с обекта attribution с полета commit и pr, където празният низ я маха напълно. Вградените инструкции за комитите могат да се изключат изцяло чрез includeGitInstructions: false – тогава агентът ще ползва само вашите правила.

Преди създаването на комита се вижда какво е подбрано за него и с каква формулировка – тук се решава дали ви устройват и двете. С пожеланията от втория пример съставът на комита се стеснява до файловете на схемата, останалото остава в работното дърво недокоснато.

/commit  # комит със съобщение по формата на проекта

/commit само промените в схемата, останалото не пипай  # в комита ще влязат само файловете на схемата

/pr [пожелания]

Отваря pull request: създава клон, изпраща го (push) и създава описание чрез gh. [Скил] Описанието се съставя по онова, което реално е в diff, а не по вашия преразказ. Трите стъпки на ръка отнемат няколко минути и обикновено именно на описанието се пести; тук то се пише само.

Клонът се създава, ако още сте на основния. С пожелания се задават чернова, ревюъри, форма на описанието.

Стъпките вървят подред – клон, push, създаване на заявката чрез gh, – и накрая в ръцете ви е връзка към отворения pull request. Пожелания от рода на „като чернова“ променят начина, по който ще се отвори заявката, но не и реда на стъпките.

/pr  # клон, push, pull request с описание

/pr като чернова, не назначавай ревюъри  # същото, но заявката ще се отвори като чернова

/commit-push-pr

И трите стъпки наведнъж: комит, push, pull request. [Скил] Същото като /commit и /pr подред, но без паузи между тях – за случая, когато работата очевидно е свършена и няма какво да се обсъжда. Ако искате да погледнете комита, преди да замине, по-добре е с две команди.

Има особеност: опасните флагове на git и gh не се одобряват автоматично. --force, --amend, --no-verify все пак ще поискат потвърждение, дори да имате щедри права. Направено е нарочно: веригата от три стъпки се изпълнява бързо и човек не успява да забележи, че някъде по средата се пренаписва историята.

И трите стъпки минават без спиране и накрая остава връзка към заявката. Веригата може да прекъсне точно едно нещо – опасен флаг по пътя: на него все пак ще ви попитат дали да продължат.

/commit-push-pr  # и трите стъпки наведнъж

/update-config

Променя настройките: хукове, права, променливи на средата – с редактиране на settings.json вместо вас. [Скил] Главният ѝ случай е поведение от вида „всеки път, когато…“: такова нещо умее само хук, с молби и с памет това не се постига, защото ги изпълнява не моделът, а самата програма. Кажете с думи какво трябва да се случва – командата ще разбере в кой файл с настройки да го запише и в какъв вид.

Настройките са проектни и лични и това са различни файлове: проектните ги вижда всеки, който работи с хранилището, личните – само вие. Ако промяната засяга вашите навици, а не общия ред на работа, кажете го веднага.

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

/update-config добави хук за форматиране след промени

/claude-code-docs [въпрос]

Отговори за самия Claude Code: възможности, настройки, SDK, Claude API, приложението за Slack. [Скил] Отговаря по документацията, а не по паметта на модела, – а това са различни неща, защото програмата се променя от версия на версия по-бързо, отколкото се обновяват знанията на модела. Питайте по-добре с човешка фраза, както бихте попитали колега.

В отговор идва разбор по документацията с връзки към нейните раздели – по тях е удобно да се провери, че отговорът не е измислен.

/claude-code-docs как да ограничим достъпа на агента до папка

/claude-in-chrome

Разрешава работа във вашия Chrome: кликане, попълване на форми, четене на конзолата. [Скил] [не във всички планове] – изисква се вход в акаунт claude.ai: с API ключ и през Amazon Bedrock, Google Cloud и Microsoft Foundry разширението е недостъпно. Работата върви във вашия истински браузър, с вашите раздели и сесии, – затова е подходяща там, където трябва да се проверява не кодът, а живата страница: да се възпроизведе бъг в интерфейса, да се мине през форма, да се видят грешките в конзолата.

Достъпът се дава по сайтове и се настройва в самото разширение: на страница, която не сте разрешили, агентът няма да отиде.

След извикването агентът се свързва с вашия браузър и нататък работи с разрешените раздели. Ако нужният сайт не е сред разрешените, изборът е прост: да му дадете достъп в разширението или да се откажете от тази проверка.

/claude-in-chrome  # разрешаване на работа в браузъра

/plugin-types [папка]

Генерира типове на входните данни на свързаните MCP инструменти. Командата чете описанията на инструментите и ги разгръща в типове, така че в кода на плъгина извикванията да се проверяват от компилатора, а не да се налучкват по памет. Аргументът е папката на плъгина, за който да се генерира. Нужна е при разработка на собствен плъгин; в обикновената работа с проект няма да ви потрябва.

Тук няма какво особено да се гледа: резултатът от командата са файлове с типове вътре в указаната папка на плъгина.

/plugin-types ./my-plugin  # типове на MCP инструментите за плъгина

/workflow-authoring

Справочник по писане на скриптове за воркфлоу. [Скил] Разказва от какво се състои скриптът, как е устроено възобновяването след срив и в какво обикновено се спъват. Чете се, преди да пишете свой воркфлоу, а не по време на изпълнението му.

Самото стартиране на воркфлоу не разрешава.

В отговор идва самата справка – устройство на скрипта, възобновяване, типични грешки и разгледани примери, – след което можете да сядате да пишете своя.

/workflow-authoring  # как се пишат скриптове за воркфлоу

/claude-api [migrate|upgrade|prompt-audit|managed-agents-onboard|cost-optimize]

Помощ по Claude API и SDK. [Скил] Единствената команда в тази група с фиксиран набор от аргументи. Нужна е, когато пишете код, който сам ходи към Claude: идентификатори на модели, параметри, стрийминг, извикване на инструменти, кеширане – всичко това се сверява с документацията, а не с паметта на модела.

Аргументът избира сценарий: без него е обща справка, с него – конкретна работа по вашия код.

Скилът се включва и сам, без команда: ако в кода на проекта има импорт на официалната библиотека на Anthropic, той се активира при задачи, които я засягат.

С аргумент командата първо чете вашия код и се връща със списък на местата и предложени промени – да ги приемете всички или една по една, решавате вие.

/claude-api migrate       # миграция към нов модел

/claude-api prompt-audit  # намиране в промптовете на инструкции за стари модели

/deep-research <въпрос>

Fan-out от уеб търсения в множество източници, проверка на фактите и отчет с връзки. [Воркфлоу] Прибягва се до нея, когато едно търсене не стига: въпросът е спорен, източниците си противоречат или е нужен не първият попаднал отговор, а сверен. Търсенето върви по няколко независими линии, намереното се съпоставя помежду си и в отчета се вижда на какво точно се опира заключението.

От версия 2.1.218 се стартира само от вас – преди агентът можеше да я извика сам.

Това е динамичен воркфлоу: стартират се много агенти и едно изпълнение изяжда лимита на плана забележимо по-бързо от обикновена сесия. В плана Pro динамичните воркфлоу първо се включват с реда Dynamic workflows в /config.

Първо ще попитат за разрешение да се стартира воркфлоуът – и това е единственият ви избор по хода на работата. Нататък всичко върви на фон, сесията остава свободна, за напредъка при желание може да се следи чрез /workflows, а накрая идва отчет с връзки; твърденията, които не е могло да се проверят, са отбелязани като непроверени, а не се представят за факт.

/deep-research с какво се различават подходите към идемпотентността в опашките

Субагенти, фонови задачи, автоматизация

/list-agents

Показва всички, на които може да се пише директно от сесията: субагентите, които сте стартирали, тиймейтите, другите сесии на Claude Code на тази машина и облачните. Името в списъка е адресът: копирате го и изпращате съобщение точно на този агент. До списъка се стига не от любопитство, а когато трябва да разберете кой още е жив и как да се обърнете към него. Псевдоним: /peers.

Тиймейтите (екипите от агенти) са изключени навсякъде по подразбиране и се включват с променливата CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 – докато я няма, редове с тях в списъка няма да има. И трябва да помните цената: екип от агенти харчи около седем пъти повече токени от обикновена сесия, защото всеки тиймейт има свой контекстен прозорец и харчи, докато не приключи.

Командата само отпечатва списък и не предлага нищо за избиране: името на нужния агент го взимате оттам сами и после го поставяте в съобщението.

/tasks

Показва всичко, което работи до диалога: фоновите задачи, стартираните процеси, състоянието им и откога вървят. Оттук те се и управляват – това е единственото място, където се виждат наведнъж всички стартирани билдове и изпълнения на тестове. Върши работа, когато са няколко и не е ясно кои още са живи и кои отдавна са паднали. Псевдоним: /bashes.

В списъка избирате конкретен ред: после можете да видите изхода на тази задача или да я спрете, без да излизате от диалога и без да търсите процеса в системата.

/daemon

Управлява фоновите услуги на Claude Code – тези, които работят извън вашия диалог: асистентите, планираните задачи и отдалеченото управление. Тук се идва, когато нещо от това трябва да се включи, да се изключи или да спре да се задейства. Обърнете внимание: част от тези услуги – планираните задачи и отдалеченото управление – живеят само при влизане в акаунт в claude.ai, а с API ключ просто няма да ги има.

Изборът тук е между услуги, а не между задачи: намирате нужния ред и превключвате състоянието му, всичко останало става от само себе си.

/workflows

Историята на воркфлоу – тези изпълнения, при които задачата се разделя на много агенти и те работят паралелно. Показва и текущите, и приключилите: колко агента, на коя стъпка, с какво е свършило. Оттук изпълнението се слага на пауза и се възобновява – това е единственото място, където върху дълго изпълнение може да се повлияе, без да се убива цялото. Да не се бърка с фоновите задачи: те са за процеси и команди, а тези – за мултиагентни изпълнения.

Едно такова изпълнение изяжда осезаемо повече токени от същата работа в обикновен диалог – агентите са много, всеки има свой контекст. Таксува се като обикновен разход, отделна сметка няма. Когато в изпълнението има повече от 25 агента или прогнозата надхвърля 1,5 милиона токена, Claude Code предупреждава предварително; в режим ultracode предупреждението не се показва – като го включите, вече сте се съгласили с големи изпълнения. На плана Pro самите воркфлоу първо се включват в /config.

/loop [интервал] [промпт]

Повтаря промпт или команда през интервал; без интервал темпото се избира само. Псевдоним: /proactive. [Скил]

Командата приема две неща поредно: незадължителен интервал и това, което да се повтаря. Повтарят се както обикновен промпт, така и слеш команда.

Интервалът се пише с човешко съкращение: 5m, 30m, 1h. Режимът без интервал трябва да се разбира буквално: агентът избира паузата според това, което чака. Билд, който върви осем минути, ще чака с една пауза, а не с осем проверки през минута.

Капанът е точно един, но скъп: цикъл, който се събужда всяка минута, за да провери фонова задача, почти винаги е излишен. За завършването на фонова работа ще ви съобщят и без това, а всяко събуждане е пълноценна заявка с целия контекст.

Какво вече върви и с каква периодичност, показва /usage: отделна команда за това, /loops, в билда 2.1.251 е изключена.

Извикването създава цикъл и веднага връща управлението: после той се събужда сам, а всяко събуждане изглежда в сесията като обикновена заявка.

/loop 5m /code-review low               # на всеки пет минути – бърз преглед
/loop 1h провери дали не са се появили нови паднали тестове и поправи очевидното
/loop проверявай дали билдът не се е счупил  # без интервал: темпото ще се избере само

/schedule [описание]

Създава, обновява и стартира агент, който работи в облака по разписание. [не за всички планове] – нужно е влизане в акаунт в claude.ai: с ключ за Console API, под профил на Anthropic и през Bedrock, Google Cloud и Foundry командата я няма, там най-близкият заместител е /loop. [извън плана] – самите изпълнения се броят към обикновения лимит на плана, но акаунтът има дневен таван на броя изпълнения: когато опрете в него или в лимита на плана, продължаването е възможно само със свързани кредити, а без тях излишните изпълнения се отхвърлят до нулирането на прозореца. Псевдоним: /routines. [Скил]

Разликата от /loop е мястото на изпълнение. /loop работи във вашата сесия, на вашата машина, докато тя е отворена. /schedule създава задачата в облака: изпълнява се по разписание независимо от това дали лаптопът ви е включен.

Аргументът е описание с думи, от което се извеждат и разписанието, и задачата, и намерението: командата умее не само да създава, но и да обновява, да показва, да стартира извън разписанието и да изтрива. Останалите изисквания са същите като при всичко облачно: свързан GitHub и липса на забрана от организацията – при Team и Enterprise собственикът може да изключи разписанията за всички. Средата по подразбиране се взима от настройката remote. Цялата функционалност е отбелязана като изследователска, тоест ще се променя.

За разходите трябва да помните едно: планираната задача се събужда и изпраща пълния контекст, дори когато сте пред компютъра и сте заети с друго. Това е най-незабележимата позиция в разходите от всички.

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

/schedule всяка сутрин в 9 събирай отчет за паднали тестове    # създаване на задача
/schedule покажи ми планираните задачи                         # какво вече е заведено
/schedule стартирай сутрешната справка веднага                 # изпълнение извън разписанието
/schedule изтрий задачата за зависимостите                     # изтриване

/autofix-pr [промпт]

Стартира облачна сесия, която следи pull request-а на текущия клон и сама пуши поправки – например оправя паднал билд в CI. [не за всички планове] – работи през Claude Code в уеб, а за него е нужно влизане в claude.ai: с API ключ и през Bedrock, Google Cloud и Foundry облачни сесии няма. Незадължителният аргумент стеснява мандата: какво може да се поправя и какво не бива да се пипа. Управлението се връща веднага – после сесията живее сама в облака и да я гледате трябва там.

/autofix-pr                                           # следи PR-а и оправяй падналия CI
/autofix-pr оправяй само линтера, логиката не пипай   # същото, но с ограничение

Артефакти, документи и дизайн

Артефактът е публикувана в claude.ai страница, която може да се отвори, да се пощрака по нея и да се даде на колегите за преглед. Почти всичко по-долу са вградени скилове и наборът зависи от акаунта: част от тях се включват само за определени абонаменти и организации.

Публикуване има на Pro, Max, Team и Enterprise: на Team е включено веднага, на Enterprise го включва собственикът на организацията, а при CMEK, HIPAA или забрана за съхранение на данни е затворено напълно. Нужна е сесия с влизане в claude.ai – с API ключ, токен на шлюз и данни за достъп на Bedrock, Google Cloud и Foundry страницата няма да се публикува. Отделно артефактите не се таксуват: генерирането на страница харчи изходни токени като всеки друг отговор.

В официалния справочник на командите от тази група има само /artifacts, /design, /design-login и /design-sync, а останалите петнайсетина [няма в документацията] – нито в чейнджлога, нито в търсенето, така че по-долу е това, което има в билда, а не това, което някъде е обещано.

/artifacts

Показва вашите публикувани артефакти и тези, които са споделени с вас: име, връзка, кога са обновявани. [не за всички планове] – като всичко в тази група, изисква сесия с влизане в claude.ai. Главното приложение е практическо: да намерите връзката към страница, направена в минала сесия – без нея Claude Code ще публикува нова вместо да обнови старата. Освен това това е инвентар: вижда се какво вече е публикувано и не се ли е изгубило нещо.

Списъкът е интерактивен: на избрания ред артефактът или се отваря в браузъра, или връзката му се копира в буфера – за това не е нужно да напускате терминала.

/prototype

Превръща идеята в работещ прототип – една самодостатъчна страница, която може да се отвори, да се пощрака и да се покаже. [не за всички планове] – публикуването изисква влизане в claude.ai. Взима се, когато да спорите с думи излиза по-скъпо, отколкото да погледнете: екран на интерфейс, поток от няколко стъпки, чернова на лендинг. От дизайнерските команди по-долу се отличава с това, че прави работеща вещ, а не картинка.

Предварително нищо не се пита: описвате идеята с думи, после работата върви до готова страница и накрая остава връзка към нея.

/prototype страница за избор на план: три плана, превключвател месец-година, изчисляване на отстъпката

/doc

Публикува работен документ, който се редактира направо на страницата: бележка, наръчник, инструкция за екип. [не за всички планове] – нужно е същото влизане в claude.ai. Смисълът е, че документът не остава в разговора: има адрес, може да се отвори, да се допише и да се сподели връзката. Тук си струва да посегнете, когато резултатът е нужен на хора, а не само на вас в терминала.

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

/doc събери от решенията в този разговор кратък наръчник за внедряване за дежурния

/plan-artifact

Публикува плана като отделна страница, която може да се сподели: етапи, кое след кое върви, какво от кого е нужно. [не за всички планове] – публикуването изисква влизане в claude.ai. Удобно е, когато план, събран в режим на планиране, трябва да се покаже на хора, а не да се преразказва. От /doc се отличава само с шаблона: тук е план, а не произволен документ.

После уточнявате какво трябва да има в плана; резултатът е страница с етапите и връзка към нея.

/artifact-pr-review [номер или връзка]

Разглежда pull request и публикува разбора като отделна страница: заключение, препоръка, спорни места, слепи зони. [не за всички планове] – публикуването изисква влизане в claude.ai. Аргументът е номерът на PR или връзка към него. Нужна е, когато разборът трябва да се покаже на автора и на останалите; да не се бърка с /code-review – тя търси дефекти и работи в терминала, а тази прави четима страница със заключението.

Работата върви на два хода и не е мигновена: първо PR-ът се чете целия и чак след това се публикува страницата, връзката към която получавате.

/artifact-pr-review 1234

/artifact-dashboard

Сглобява дашборд по готов шаблон: показатели, графики, срезове на една страница. [не за всички планове] – публикуването изисква влизане в claude.ai. Взима се, когато има числа и те трябва да се покажат цялостно: статус на проекта, резултати от изпълнение, метрики за период. Шаблонът задава оформлението и вида – от вас са данните и разбирането кое тук е главното.

После давате данните и казвате кое в тях е главното; накрая остава връзка към сглобения дашборд.

/artifact-dashboard седмични метрики на опашката: дължина, време на изчакване, дял на повторенията

/artifact-report

Отчет по готов шаблон: изводите отгоре, разделите с подробности отдолу. [не за всички планове] – публикуването изисква влизане в claude.ai. Става за резултати от одит, разбор или голямо изпълнение, когато резултатът трябва да се предаде на хората цялостно, а не да се преразказва на парчета. Разликата от дашборда е, че тук има текст и разсъждение, а не плочки с числа.

После казвате за какво е отчетът; резултатът е публикувана страница и връзка към нея.

/artifact-report резултати от теста за натоварване за съседния екип

/artifact-data-table

Публикува данните като таблица по готов шаблон – като отделна страница вместо дълга простиня в терминала. [не за всички планове] – публикуването изисква влизане в claude.ai. Нужна е, когато редовете са повече, отколкото се събират в отговор, и искате да ги разгледате. Данните се взимат от това, което сте дали или което се е натрупало в тази сесия.

После давате редовете и колоните; накрая – връзка към страницата с таблицата.

/artifact-data-table таблица със SLA по услуги от последния отчет

/artifact-explainer

Страница с обяснение по готов шаблон: разбор на една тема или механизъм стъпка по стъпка. [не за всички планове] – публикуването изисква влизане в claude.ai. Взима се, когато трябва да обясните устройството на нещо на колега или на нов човек в екипа и обяснението трябва да живее по-дълго от един разговор. От отчета се отличава със задачата: отчетът съобщава резултат, а обяснението учи да се разбира.

После назовавате темата; резултатът е страница с разбор и връзка към нея.

/artifact-explainer как е устроена нашата схема за идемпотентност на поръчките

/artifact-components

Включва готови повторно използваеми компоненти, от които се сглобява артефактът. Смисълът е прост: да не се рисува всеки път отново това, което вече е направено и изглежда прилично. Сама нищо не публикува – работи върху страницата, която правите като следваща стъпка.

След извикването на екрана нищо не се появява: наборът от компоненти просто се оказва в контекста.

/artifact-design

Правила за оформление на артефактите: изграждане на страницата, типография, тъмна тема и, което е по-важно, съразмерност на усилията със задачата. Зареждат се, преди да правите страница, за да изглежда като готова вещ, а не като чернова от терминала. Нищо не публикува и не отпечатва.

/artifact-diagramming

Как се рисуват схеми, които показват реалния механизъм, а не набор от кутийки със стрелки: кога схемата изобщо е нужна, какво трябва да има на нея и как да се направи четима в светла и тъмна тема. Зарежда се, когато в артефакта е нужна схема. Нищо не публикува и на екрана не извежда.

/artifact-capabilities

Описва какво може публикуваната страница по време на изпълнение: да чете вашите данни, да запомня действията на посетителите (анкета, чеклист, документ, който се редактира направо на страницата), да държи общо състояние, да пита Claude. Зарежда се, преди да поискате такава страница: без това ще се получи обикновен статичен HTML, който нищо не помни. Наборът от възможности зависи от акаунта и командата показва какво е достъпно именно за вас.

/dataviz

Правила за оформление на графики и дашборди: какъв тип графика за какви данни, палитри, оси, надписи, достъпност, поведение в тъмна тема. Зареждат се, преди да е написан първият ред код на графика – да се преработва после излиза по-скъпо. Работи не само за артефакти: правилата са същите и за картинка, и за код с коя да е библиотека.

Самото извикване нищо не извежда: правилата се зареждат и действат върху следващата графика.

/whiteboard

Обща дъска: вие рисувате на ръка, а отговорите идват направо върху нея. [не за всички планове] – дъската живее като публикувана страница, а това значи, че е нужно влизане в claude.ai. Става там, където да обяснявате с думи е по-дълго, отколкото да хвърлите скица: разположение на елементи, структура на екран, връзки между части на системата.

Дъската се отваря като отделна страница и връзката към нея получавате в отговор на извикването.

/whiteboard скицирай обмена между услугата за поръчки и плащанията

/whiteboard-mp

Същото, но дъската е жива и върху нея рисува не само човекът: агентът добавя своето върху вашето и се получава съвместна работа. [не за всички планове] – като обикновената дъска, изисква влизане в claude.ai. Взима се, когато трябва не „да нарисуваш и да попиташ“, а да скицирате заедно.

Страницата е устроена по същия начин, с връзка в отговора; разликата е, че после на едно платно се оказват и вашите щрихи, и това, което е дорисувал агентът.

/whiteboard-mp да видим двамата къде в тази схема се губи идемпотентността

/workshop

Сглобява дизайн заедно с вас, по едно решение наведнъж: въпрос – ваш отговор – следваща стъпка, вместо голяма страница, направена веднага цялата. [не за всички планове] – резултатът се публикува, затова е нужно влизане в claude.ai. Става, когато и вие самите още не знаете какво искате и решението се избистря по пътя.

Разговорът започва с въпрос и върви с въпроси до края; готовата страница с връзка се появява чак накрая.

/workshop екран за настройки на известията – по едно решение наведнъж

/design [sync|login|consent|revoke|import|export|status|описание]

Хъбът на Claude Design – връзката на Claude Code с дизайн система в claude.ai. [не за всички планове] – има на Pro, Max, Team и Enterprise (на Enterprise е изключен по подразбиране), нужна е сесия, в която работят артефактите, и версия не по-ниска от 2.1.234; на Bedrock, Google Cloud, Foundry и Claude Platform on AWS командата я няма. Отделно не се таксува: разходът отива в същия общ лимит като при обикновената работа.

Официално това е една команда „с описание на дизайна“, а /design-login и /design-sync са две отделни. В бинарния файл /design допълнително разбира седем подкоманди и това никъде не е описано. Цялата тази история се появи във версия 2.1.234 и е отбелязана като изследователска – тоест ще се променя.

Подкомандите отговарят по различен начин: status съобщава състоянието на връзката, login праща в браузъра за потвърждаване на достъпа, а import и export пренасят дизайн системата между проекта и claude.ai.

/design status                           # състояние на връзката с Claude Design
/design login                            # влизане
/design import                           # взимане на дизайн системата оттам
/design export                           # качване там

/design-sync [подсказка]

Сглобява дизайн системата на React проект направо от кода и я качва в claude.ai/design, за да изглежда всичко, което се рисува там, като вашия продукт, а не като чужд шаблон. [не за всички планове] – същите изисквания като при /design: влизане в claude.ai и достъпно публикуване на артефакти. Аргументът е кратка подсказка как да се нарече качването или на какво да се обърне внимание в проекта. Ако достъпът още не е даден, започва се с /design-login.

Всичко става на един ход и без въпроси: проектът се разглежда, дизайн системата се сглобява и заминава към claude.ai/design – там я и разглеждат.

/design-sync Acme DS

/design-login

Оторизира достъпа до дизайн системата – същия, който е нужен за качването. [не за всички планове] – работи там, където и останалият Claude Design, и изисква влизане в акаунт в claude.ai. Отделена е като самостоятелна команда, защото влизането се прави веднъж, а качванията после са много. Ако /design-sync се оплаква от достъпа, започва се оттук, а резултатът се проверява през /design status.

Влизането се потвърждава в браузъра; след това достъпът остава даден и не е нужно да се повтаря преди всяко качване.

Конфигурация и интерфейс

/config [ключ=стойност]

Панел с настройки: без аргумент се отваря панел с всички настройки, които могат да се променят от интерфейса. Това е основната входна точка към цялото поведение на агента – от темата до модела и режимите на работа – и да надникнете тук е по-лесно, отколкото да помните имената на ключовете във файла с настройки. Псевдоним: /settings.

С аргумент настройката се задава веднага, без панел: /config theme=dark. Пълният списък с приеманите ключове отпечатва /config --help – не гадайте, той е по-къс от списъка с ключове на файла с настройки.

Директната форма се появи в 2.1.181, именуваните съкращения като theme и model – в 2.1.182. Работи и в неинтерактивен режим, и от телефона през отдалеченото управление, което я прави основния начин да смените настройка от скрипт.

Ограничението е точно едно, но неочевидно: формата „ключ=стойност“ не може да включи настройка, която изисква вашето потвърждение в панела. Например autoContinueAtUsageLimit тя може да изключи, но не и да включи – включването е придружено от диалог, а в тази форма няма къде да се покаже диалог.

/config                  # отваряне на панела с настройки
/config --help           # кои ключове приема формата ключ=стойност
/config theme=dark       # задаване веднага, без панел
/config model=sonnet     # същото за модела

/permissions

Правила за разрешаване и забраняване на инструменти, плюс раздел за авто-режима. Тук се идва в два случая: омръзнало ви е да потвърждавате една и съща безобидна команда – или, обратно, трябва да затворите на агента достъпа до нещо, което не бива да пипа. Правилото се записва в настройките и действа нататък само, без въпроси. Псевдоним: /allowed-tools.

Първо избирате списъка – разрешеното, забраненото или изискващото потвърждение, – а в него добавяте своето правило или махате излишното; промените действат от този момент, рестартиране не е нужно.

/permissions   # правила за правата на достъп

/theme

Смяна на цветовата тема на интерфейса. Темата променя само как Claude Code рисува себе си в терминала – подсветката на кода в диф-овете, рамките, селекциите; върху настройките на самия терминал не влияе.

Освен светла и тъмна има варианти за хора с цветна слепота, ANSI варианти за терминали със собствена палитра и auto, която се нагажда към фона на терминала. Собствените теми се слагат в ~/.claude/themes/ или идват от плъгини; направо в избора има опция за създаване на нова.

Изборът е със списък: избраната тема се прилага към целия интерфейс и се запомня в настройките, така че в следващата сесия ще остане същата.

/theme   # избор на тема

/keybindings

Отваря или създава файла с бързи клавиши – ~/.claude/keybindings.json. В него се предефинират комбинациите на интерфейса, включително акорди от две последователни натискания. Нужна е, когато познатата комбинация се прихваща от самия терминал или от мултиплексор и до Claude Code просто не стига. Файлът се отваря в редактор; ако го е нямало, се създава.

/keybindings   # собствени бързи клавиши

/terminal-setup

Настройване на комбинациите на терминала – например Shift+Enter за пренасяне на ред. Промените отиват в конфигурацията на самия терминал, а не на Claude Code: достатъчно е да се изпълни веднъж на машината, но след преминаване към друг терминал ще се наложи да се повтори.

/terminal-setup   # Shift+Enter и други комбинации на терминала

/statusline

Настройване на реда за състояние: със собствен скрипт или генериран от вашия shell промпт. Редът за състояние е това, което Claude Code печата до полето за въвеждане: обикновено директория, клон и модел, но съдържанието е изцяло ваше. Скриптът се извиква при обновяване на реда и в него попада това, което е отпечатал.

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

/statusline   # настройване на реда за състояние

/voice [hold|tap|off]

Гласово въвеждане. [не за всички планове] – диктуването изисква влизане в акаунт в claude.ai: с API ключ и при външни доставчици го няма. Върши работа, когато трябва да издиктувате дълго описание на задача, вместо да го пишете; режимът се избира според това как ви е удобно да държите ръцете си.

Аргументът се прилага веднага, без диалог: режимът на диктуване се превключва на посочения.

/voice hold   # говорене със задържан бутон
/voice tap    # натискане – говорене, натискане – изпращане
/voice off    # изключване на гласовото въвеждане

/tui [default|fullscreen]

Рендерер на интерфейса: fullscreen – на цял екран, без премигване, default – обратно към обикновения. Този на цял екран заема целия прозорец и сам се прерисува, затова дългият изход не подскача. Обикновеният пише в потока на терминала и историята се прелиства от самия терминал – ако копирате парчета изход с мишката или разчитате на скролването на терминала, останете на него.

Превключването не става във всяка сесия: ако в нея действат ограничения, които рестартът няма да пренесе – например права, зададени само за тази сесия, – командата ще откаже и нищо няма да промени.

/tui fullscreen   # рендерер на цял екран без премигване
/tui default      # обратно

# отказ в сесия с ограничения, които рестартът не пренася
# (така изглежда в документацията):
Cannot switch renderers in this session — it has restrictions a restart can't carry over (permission rules set for this session only). Nothing was changed. Running /tui fullscreen in a session started without them switches every later session too.

/color [цвят|default]

Цвят на реда за промпт за текущата сесия. Това не е тема, а именно цветът на реда за въвеждане; удобно е, когато са отворени четири терминала и не бива да се обърка кой е кой.

Палитрата е фиксирана: red, blue, green, yellow, purple, orange, pink, cyan, плюс default за нулиране. Ако е включено отдалечено управление, цветът се синхронизира и в уеб интерфейса.

/color purple    # цвят на реда за промпт
/color           # случаен цвят
/color default   # нулиране

/scroll-speed

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

/scroll-speed   # скорост на скролване с колелцето

/focus

Фокус-изглед: на екрана остават само вашият промпт, обобщението на инструментите и крайният отговор. Всичко междинно – подробностите от извикванията, съдържанието на прочетените файлове, дългият изход на команди – изчезва от екрана. Нужен е, когато сесията е нараснала и зад техническия изход се губи самият разговор, а също и когато показвате работата на агента на някой друг.

/focus   # да остане на екрана само същественото

/hooks

Преглед на настроените хукове по събития. Хукът е ваша команда, която Claude Code сам стартира при събитие: преди извикване на инструмент, след редакция на файл, в края на хода. Панелът показва какво към кое събитие е вързано – това е първото място, където да погледнете, когато хук мълчаливо не се задейства.

/hooks   # кои хукове са настроени

/auto-mode-setup

Запознаване на авто-режима с вашата среда и донастройване на правилата му. Авто-режимът е работа без потвърждение на всяка стъпка и по подразбиране той е предпазлив просто защото нищо не знае за вашия проект. Командата минава през средата заедно с вас и превръща отговорите в правила: какво тук може да се прави без питане и какво не бива да се пипа при никакви условия.

/auto-mode-setup   # запознаване на авто-режима със средата

/sandbox [exclude "шаблон"|install]

Настройване на пясъчника за команди. Пясъчникът ограничава къде стартираната команда може да пише и да ходи по мрежата и именно той позволява рутината да се изпълнява без потвърждаване на всяко извикване. Командата се вижда само там, където пясъчникът се поддържа.

exclude е случаят, когато билд или команда за контейнер не работи вътре в изолацията и вие съзнателно я вадите оттам; списъкът се трупа в ключа sandbox.excludedCommands.

/sandbox                      # панел на пясъчника
/sandbox exclude "docker *"   # изваждане на команда от пясъчника
/sandbox install              # доинсталиране на пясъчника (Windows)

/import [codex|gemini] [--dry-run] [--yes]

Пренасяне на конфигурацията от друг агент за програмиране: файловете с инструкции, MCP сървърите, командите, субагентите и скиловете. [не за всички планове] – недостъпна е при външни доставчици и при изключено зареждане на сървърни флагове. Поддържат се codex и gemini.

В неинтерактивен режим командата отпечатва какво е намерила и подсказва реда за потвърждаване на импорта. Изисква версия 2.1.213 и по-нова.

За файла AGENTS.md, който използват някои други агенти, /import не е нужен: от версия 2.1.277 Claude Code го чете сам, ако в проекта няма нито CLAUDE.md, нито CLAUDE.local.md. Ако CLAUDE.md има, добавете в него реда @AGENTS.md или пренесете конфигурацията с командата /import във вид, разбираем за Claude Code.

Без --yes изборът остава ваш: командата показва намереното по видове и пита какво точно да се пренесе – може да вземете само MCP сървърите, а командите и скиловете да оставите както са.

/import codex              # вземане на конфигурацията на друг агент
/import gemini --dry-run   # да видим какво би се пренесло
/import codex --yes        # пренасяне без въпроси

/cloud-plugins

Дали в облачните сесии да се използват плъгините, включени на тази машина. [не за всички планове] – самите облачни сесии изискват влизане през акаунт в claude.ai и са недостъпни с API ключ и при външни доставчици. Облачната сесия се стартира на чужда машина, където вашият набор от плъгини го няма: настройката решава дали да се пренася натам, или да се минава с това, което е вградено в Claude Code.

Изборът е прост, но с последствия: с плъгини облачната сесия се държи като вашата локална, без тях – работи на гола конфигурация, но пък не мъкнете в облака излишни източници.

/cloud-plugins   # плъгини в облачните сесии

/skills

Списък със скиловете и управление на тяхната видимост.

Описанията на всички достъпни скилове висят в контекста постоянно, всяка сесия, независимо дали ги използвате, или не. При голям набор от плъгини това е осезаем дял от прозореца – екранът /skills е за това.

Пишете – списъкът се филтрира по име, описание и източник. Клавишът t сортира по брой токени и тук обикновено се оказва, че половината от прозореца е заета от три скила, които не сте използвали нито веднъж. Space или Enter превключва видимостта на скила за модела и за менюто, Esc запазва и затваря.

Превключва се не всичко: скиловете от плъгини, скиловете с disable-model-invocation: true във frontmatter и тези, за които видимостта е зададена в корпоративните настройки или през --settings, не се поддават. Постоянният еквивалент е ключът skillOverrides, а да намерите това, което просто не се използва, помага /skill-doctor.

/skills   # списък със скиловете и тяхната видимост

/plugin

Управление на плъгините и маркетплейсите. Маркетплейсът е източник, от който се инсталират плъгини; самият плъгин носи със себе си команди, скилове, субагенти, хукове и MCP сървъри наведнъж, затова един плъгин може осезаемо да промени поведението на сесията. През този панел маркетплейсът се свързва, а плъгинът се инсталира, изключва и изтрива. Псевдоними: /plugins, /marketplace.

Редът на избиране е такъв: първо маркетплейсът, после плъгинът в него. Част от промените не влизат в сила мигновено – довършва ги /reload-plugins.

/plugin   # плъгини и маркетплейси

/reload-skills

Подхващане на скиловете и командите, променени на диска, без рестартиране на сесията. Нужна е, когато пишете свой скил и не искате да рестартирате при всяка промяна. Препрочитат се само файловете – разговорът и неговият контекст остават на място.

/reload-skills   # подхващане на промените в скиловете от диска

/reload-plugins [--force]

Активиране на отложените промени в плъгините – същото като /reload-skills, само че за плъгини. Върши работа веднага след /plugin, когато плъгинът вече е инсталиран, но сесията още не го вижда.

Смисълът на --force тук е обратен на интуитивния: това не е „препрочети по-дълбоко“. Ако презареждането би променило набора от заредени MCP инструменти, то ще нулира кеша на промпта и командата, след като предупреди, ще откаже да го направи – а --force я принуждава да го направи въпреки това. Тоест флагът преодолява отказа, а не задълбочава работата.

/reload-plugins           # прилагане на отложените промени в плъгините
/reload-plugins --force   # същото, дори ако това ще нулира кеша на промпта

MCP и интеграции

/mcp [reconnect|enable|disable [<сървър>|all]]

Управление на MCP сървърите и тяхната OAuth оторизация. MCP сървърът е външен процес или услуга, която внася в сесията свои инструменти, промптове и ресурси: тракер на задачи, база, браузър, вътрешно API. Тук се идва, когато сървър е паднал по средата на работата, когато иска да влезете отново или когато инструментите му в момента само пречат – излишният сървър е по-добре да се изключи, отколкото да се държат описанията му в контекста. Самите сървъри се описват в конфигурацията, тук е само текущото им състояние.

В списъка срещу всеки сървър се вижда дали е свързан, дали е паднал или чака оторизация – по това се решава какво да се свърже наново и какво да се изключи до края на работата. При свързан сървър панелът показва и броя на инструментите му и отделно отбелязва този, който се е свързал, но не е дал нито един.

Сървърите дават своите промптове като команди. Те се появяват в менюто във вида /име-на-сървъра:име-на-промпта – и това е формата, която си струва да запомните, защото втората, /mcp__сървър__промпт, също работи, но се среща само в стари статии. Аргументите се подават през интервал и се режат по интервалите: всеки аргумент е един токен, фраза в кавички да се подаде като един аргумент няма да стане.

Ресурсите на сървъра се вмъкват с @. Формата е @сървър:протокол://път и това е механизъм, отделен от инструментите: не „извикай инструмент“, а „сложи съдържанието в контекста“.

Във фонова сесия, към която не е свързан терминал, панелът изобщо няма да се отвори: сесията ще премине в състояние „нужно е въвеждане“, а за управление на сървърите ще предложат формата /mcp enable|disable|reconnect <сървър>.

/mcp                                     # списък със сървърите и състоянието им
/mcp reconnect github                    # вдигане на паднал сървър
/mcp disable jira                        # временно изключване на сървър
/jira:create_issue login-bug high        # промпт на сървъра, сегашната форма

/ide [open]

Интеграции с IDE и техният статус. Заради тази връзка промените се виждат в редактора като диф-ове, а фрагментът, избран там, попада в контекста, затова първото, към което посягате при „в редактора нищо не се случва“, е тук: обикновено се оказва, че връзката не се е установила. Без аргумент показва статуса на интеграцията с редактора, с open – отваря файл в свързаната IDE.

/ide                                     # статус на интеграцията с редактора
/ide open                                # отваряне на файл в свързаната IDE

/chrome

Настройки на Claude in Chrome. [не за всички планове] Разширението работи само при влизане в акаунт в claude.ai – с API ключ и при външни доставчици го няма. Claude in Chrome е когато агентът ходи по страниците на вашия собствен браузър: кликва, чете страницата, гледа конзолата. Разрешенията се дават по сайтове и без тях нищо няма да се изпълни, затова тук се наднича преди първата задача в браузъра.

/chrome                                  # настройки за работа в браузъра

Акаунт и оторизация

/login

Влизане в акаунт на Anthropic или превключване на акаунта. Тук се избира и с какво се плаща работата – с абонамент за claude.ai или с API ключ от Console, а от това зависи не само сметката: част от възможностите (уеб сесиите, мобилното приложение, кредитите извън плана) има само при абонамент. Влизането става в браузъра, след потвърждаване управлението се връща в терминала.

Към тази команда насочват и съобщенията, че трябва да влезете наново: Not logged in · Please run /login, OAuth token revoked · Please run /login, OAuth token has expired · Please run /login – и трите са дадени в документацията дословно.

/login                                   # влизане или превключване на акаунта

/logout

Излизане от акаунта. Запазените данни за достъп се изтриват и после сесията не може да работи, докато не влезете отново – нужно е, когато машината е споделена или когато трябва начисто да превключите към друг акаунт.

/logout                                  # излизане

/setup-bedrock

Настройване на Amazon Bedrock: оторизация, регион, фиксиране (pin) на модели. Нужна е там, където работата не върви директно през Anthropic, а през AWS – обикновено заради изискване трафикът да се държи в собствения облак. Вижда се при включен Bedrock.

Заедно със /setup-vertex това е пример за команди, скрити според състоянието: появяват се само когато е зададена съответната променлива на средата на доставчика. Докато я няма, няма ги и в /help.

/setup-bedrock                           # настройване на Amazon Bedrock

/setup-vertex

Настройване на Google Cloud: оторизация, проект, регион, фиксиране (pin) на модели. Смисълът е същият като при Bedrock: трафикът върви през вашия облак и се плаща там. Както /setup-bedrock, вижда се само при зададена променлива на средата на доставчика.

/setup-vertex                            # настройване на Google Cloud

/install-github-app

Инсталиране на Claude GitHub Actions за хранилището. Това е приложението, чрез което прегледът на pull request-и се случва от страна на GitHub, а не във вашия терминал. Инсталира се веднъж за хранилище; локалната /code-review не зависи от него и работи без каквато и да е инсталация.

/install-github-app                      # поставяне на ревю в CI за хранилището

/install-slack-app

Инсталиране на Slack приложение. [не за всички планове] Claude Code в Slack изисква влизане в claude.ai – с API ключ и при външни доставчици е недостъпен. След инсталацията задачата може да се постави направо от разговора и отговорът ще дойде там – удобно е там, където обсъждането и без това върви в Slack. В корпоративно пространство инсталацията може да опре в правата на администратора.

/install-slack-app                       # поставяне на приложението в Slack

/privacy-settings

Преглед и промяна на настройките за поверителност: какво излиза навън от вашата работа и как е разрешено да се използва. Тук се идва преди работа със затворен или чужд код – за да видите текущото състояние, а не да гадаете за него. В корпоративните акаунти част от превключвателите са затворени от политиката на организацията.

/privacy-settings                        # какво излиза навън

Използване и разходи

/usage

Разход на сесията, използване на лимитите на плана и статистика за активността. Псевдоними: /cost, /stats. Тук се идва в два случая: когато трябва да разберете дали ще доживеете до нулирането на лимита и когато разходът изведнъж е скочил и трябва да видите кой го създава.

Екранът показва три неща: колко е похарчено в тази сесия, доколко са запълнени лимитите на плана и за какво отиват токените – с разбивка по скилове, субагенти, плъгини и отделни MCP сървъри, плюс бележки за поведение, което дава повече от десет процента от разхода. Клавишите d и w превключват прозореца между денонощие и седмица, а планираните задачи от 2.1.242 получават свои редове.

Следват четири неща, които е важно да се разбират, и нито едно не е очевидно.

Разбивката се изчислява по локалната история на сесиите. Тоест по транскриптите на тази машина. Работата от друг компютър и от уеб интерфейса не попада в нея – при това самите лимити са общи за акаунта. Разминаването между „почти нищо не съм похарчил“ и „лимитът е на изчерпване“ обикновено се обяснява точно с това.

Лимитите са няколко и смяната на модела помага само при един от тях. Съобщенията „изчерпахте лимита на сесията“ и „изчерпахте седмичния лимит“ се отнасят до прозорци, общи за всички модели – /model тук няма да помогне. И само след „изчерпахте лимита на Opus“ или „лимита на Sonnet“ преминаването към модел от друго семейство ще ви върне в работата. От версия 2.1.234 Claude Code умее да изчака нулирането и да продължи прекъснатата задача сам; включва се през /rate-limit-options и ключа autoContinueAtUsageLimit.

Кешът на промпта живее час само при абонамент. Щом започнете да харчите кредити извън плана, времето на живот на кеша пада от час на пет минути – и същата пауза за обяд, която вчера не е струвала нищо, днес се превръща в преработване на целия контекст наново. При API ключ и при облачните доставчици по подразбиране са пет минути.

Броячът на сесията се нулира при /clear. До версия 2.1.211 той се трупаше през изчиствания и числата от старите статии не се връзват със сегашните.

Ако сървърът за лимитите е недостъпен, екранът ще покаже последните заредени данни с бележка и ще предложи да опитате пак с клавиша r. Докато са свързани кредити извън плана, за тях тук има отделен ред.

Незабележимите пера в разходите, които не се виждат в разбивката, но реално горят лимита, докато вие не правите нищо: планираните задачи се събуждат и тръгват с целия контекст; съобщение от друга ваша сесия идва като нов ход (лекува се с crossSessionInbound: "hold"); проверките на активната цел започват ходове, докато върви фонова работа; всеки жив тиймейт харчи, докато не приключи. И /compact сам по себе си е голяма заявка, докато /clear не струва нищо.

/usage                                   # лимити, разход, разбивка
# изходът изцяло, както го е цитирал авторът на доклада за грешка
Session
Total cost:            $86.94
Total duration (API):  1h 31m 17s
Total duration (wall): 1d 22h 35m
Total code changes:    2538 lines added, 312 lines removed
Usage by model:
    claude-opus-4-8:   9.0k input, 461 output, 50.4k cache read, 29.9k cache write ($0.3802)
    claude-haiku-4-5:  2.0k input, 43 output, 0 cache read, 0 cache write ($0.0022)
    claude-sonnet-5:   86.5k input, 448.0k output, 197.4m cache read, 3.4m cache write ($86.55)

Current session: 17% used, resets 1:29pm (Europe/Madrid)
Current week (all models): 19% used, resets Aug 13 at 8:59am (Europe/Madrid)
# на отделен ред там, от 2.1.251 насам – за кеша на промпта; така изглежда в документацията
Prompt cache (main):   14 requests · 91% of input tokens from cache · 2 misses (last 6m 10s ago, 310.2k tokens re-cached) · 1 expected rebuild (compaction or tool-result clearing) · warm (1h TTL, last activity 40s ago)

/stats                                   # същото, веднага в раздела за статистика
/cost                                    # същото, в обикновен вид

/usage-credits

Настройване на кредити, за да продължите работата при достигане на лимита на плана. [не за всички планове] Командата работи само след влизане с абонамент за claude.ai през /login; при оторизация с API ключ я няма. Кредитите са платен извън абонамента разход по обикновените тарифи на API, сметката за тях е отделна от плана. Без тях при изчерпан лимит просто чакате нулирането на прозореца; с тях ще дойде предложение да продължите и по-нататъшната работа ще върви срещу пари.

Накъде точно води командата, зависи от вашата роля: абонат на Pro или Max – към страницата за разходите в claude.ai, участник в Team или Enterprise с достъп до таксуването – към админските настройки, а участник без такъв достъп тя ще помоли да потвърди и ще изпрати заявка до администраторите на организацията. На самата страница се избират три неща: дали да се включат кредитите, или не, да се зададе месечен таван на разходите или да се махне, и да се зареди балансът. При абонирали се през мобилното приложение включването и зареждането работят само в уеб версията.

Помнете страничния ефект, описан по-горе: с началото на разходите извън плана кешът на промпта живее пет минути вместо час.

/usage-credits                           # свързване на кредити извън плана

Отдалечена работа и среди

/desktop

Продължаване на текущата сесия в десктоп приложението. [не за всички планове] На приложението му трябва влизане в claude.ai – при API ключ и при външни доставчици го няма. Сесията се премества заедно с контекста и историята: задачата не е нужно да се поставя наново. Върши работа, когато е по-удобно да продължите работата в прозореца на приложението, а не в терминала. Псевдоним: /app.

/desktop                                 # продължаване в приложението

/teleport

Издърпване на уеб сесия в този терминал. [не за всички планове] Уеб сесиите са research preview за Pro, Max и Team (при Enterprise е нужен подходящ тип място), изискват влизане в claude.ai и са недостъпни на Bedrock, Google Cloud и Microsoft Foundry. Контекстът, историята и състоянието на работата се пренасят при вас и нататък работите локално – това е нужно, когато задачата е поставена от телефона или от браузъра, а да се довърши е по-удобно на ръка. Избира се от активните ви уеб сесии; след избора терминалът продължава тази, която сте посочили. Отделна такса за облачната машина няма, харчат се обикновените лимити на акаунта. Псевдоним: /tp.

/teleport                                # взимане на уеб сесия в терминала

/remote-control

Отваряне на сесия за управление от телефон или от уеб. [не за всички планове] Изисква влизане в claude.ai; с API ключ е недостъпно. Работата при това остава на вашата машина – отвън само изпращате заявки и четете отговори, затова достъпът до хранилището и средата не заминава никъде. Удобно е, когато върви нещо дълго и искате да го следите, без да седите на бюрото. Псевдоним: /rc.

Отказът изглежда разбираемо: ако сесията работи не през api.anthropic.com, командата направо назовава причината и казва коя променлива на средата да се махне.

/remote-control                          # отваряне на сесия за телефона
# отказ при зададена CLAUDE_CODE_USE_BEDROCK – така изглежда в документацията
Remote Control is only available when using Claude via api.anthropic.com. CLAUDE_CODE_USE_BEDROCK is set, so this session is using Amazon Bedrock — unset it (or run in a shell without it) to use Remote Control.

/session

Показване на адреса на отдалечената сесия и QR код за нея. Нужна е след /remote-control, когато сте загубили връзката или свързвате второ устройство: с телефон е по-лесно да насочите камерата, отколкото да пренасяте адреса на ръка. Работи там, където и отдалеченото управление – тоест при влизане в claude.ai. Псевдоним: /remote.

/session                                 # адрес на сесията и QR код

/remote-env

Среда по подразбиране за уеб сесиите и телепорта. Смисълът е облачната машина да стартира вече подготвена за вашия проект, а не празна: иначе още първият билд или изпълнение на тестове се спъва. Настройва се веднъж и после се прилага към всички нови уеб сесии. Отнася се само до уеб, на който му трябва влизане в claude.ai.

/remote-env                              # среда по подразбиране за уеб

/web-setup

Свързване на GitHub към Claude Code в уеб през локалния gh. Тоест да се даде навън достъпът, който на вашата машина вече е настроен, вместо отделна оторизация в браузъра. Прави се веднъж; без това уеб сесията няма да види частните хранилища. Както цялото уеб направление, изисква влизане в claude.ai.

/web-setup                               # свързване на GitHub към уеб
# така изглежда в документацията
Connected as <your-github-username>

Диагностика и помощ

/help

Справка и списък с достъпните команди. Списъкът се сглобява за вашата сесия: командите, скрити според състоянието (като настройването на облачни доставчици) или изключени от администратора, няма да се появят в него – затова това е честният отговор на въпроса „какво изобщо имам“, за разлика от документацията. Добра проверка след инсталиране на плъгин: командите му трябва да се появят тук.

/help                                    # какво изобщо е достъпно

/status

Версия, модел, акаунт, връзка с API и статуси на инструментите. Първото място, където се гледа, когато поведението не се връзва с очакванията: не е този модел, не е този акаунт, не е стигнала настройка. Работи дори докато върви отговор.

Отваря панела с настройки в раздела за състоянието. Освен версията, модела, акаунта и връзката там има ред за вида на сесията: interactive за обикновената, background job · attached или background job · unattended за фонова – според това дали към нея е свързан терминал. Редът се появи в 2.1.221.

Плюс това от 2.1.243 там има и ред за пропуснатите източници на корпоративни настройки: ако админът е сложил файл с политика, а действа друг, с по-висок приоритет, тук ще се види кой точно е игнориран. Това е първото, което трябва да се гледа, когато „настройката от админа не е стигнала“.

Според документацията в същия раздел се срещат редове за профила, начина на влизане, API ключа, адреса на хоста и прокси, а зад корпоративен шлюз – редове за доставчика с неговия базов адрес.

/status                                  # версия, модел, акаунт, връзка
# редове от раздела за състояние, както ги е цитирал авторът на доклад за грешка (билд 2.1.199)
Version: 2.1.199
Session ID: 352ea81c-819d-4028-bba5-daef515d0815
Login method: Claude Enterprise account
…
Model: claude-fable-5[1m] (claude-fable-5)
Setting sources: User settings, Enterprise managed settings (remote)

/doctor

Диагностика на инсталацията и привеждане на конфигурацията в ред. Псевдоним: /checkup. Тук се идва, когато CLAUDE.md е нараснал и всяка заявка мъкне килобайти инструкции или когато след обновяване нещо се държи странно.

От версия 2.1.205 това не е екран с отчет, а пълноценен скил, който променя вашата конфигурация. Какво прави: чисти дублиранията между локалния и комитнатия CLAUDE.md; подрязва комитнатия, като изхвърля това, което агентът и без това ще изведе от кода; пренася вечно зарежданите инструкции в скилове и вложени файлове, зареждани при нужда; предлага авто-режимът да стане режим по подразбиране и предварително да се одобрят безопасните команди, които най-често сте забранявали. Първо показва находките, после променя.

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

Терминалният claude doctor е все така диагностика без поправки и без стартиране на сесия; чете файловете с настройки в текущата папка, без да пита за доверие към нея.

Командата остава достъпна, дори когато вградените скилове са изключени изцяло: тя е нарочно отбелязана като оцеляваща при disableBundledSkills. Да се скрие може с променливата DISABLE_DOCTOR_COMMAND или със запис "doctor": "off" в skillOverrides.

/doctor                                  # проверка и поправяне на конфигурацията

/feedback [доклад]

Изпращане на отзив за Claude Code. Текстът може да се подаде направо в аргумента или да се напише в отвореното поле. Става за „работи не така, както очаквах“ и за пожелания; за конкретна повреда с приложен разговор има /bug.

/feedback                                # изпращане на отзив
/feedback промените се прилагат, но не се показват в диф-а

/bug [доклад]

Съобщаване за грешка или споделяне на разговор. Използва се и когато просто трябва да предадете на някого хода на сесията изцяло. Преди да приложите разговора, трябва да си спомните какво има в него: имената на вътрешни услуги, парчета частен код и всичко, което е попаднало в контекста, ще заминат заедно с него. Псевдоним: /share.

Преди изпращане командата пита дали да приложи разговора.

/bug                                     # съобщаване за грешка

/heapdump

Снемане на дъмп на паметта – за диагностика на високото ѝ потребление. Скрита.

Записва снимка на паметта и разбор на потреблението на работния плот (в домашната папка на Linux без работен плот). Командата е скрита не със сървърен флаг, а с това, че не се показва в менюто: набира се цялата и работи. Важно предупреждение: при обръщане към поддръжката прилагайте само файла с разбора, а самата снимка съдържа целия ви разговор и данните за достъп и да се споделя не бива.

/heapdump                                # дъмп на паметта на работния плот

/insights

Отчет с анализ на вашите сесии: зоните на проекта, шаблоните на работа, точките на триене. Това е поглед към навиците, а не към парите – колко е похарчено, показва /usage. Има смисъл да се гледа веднъж на няколко седмици: от отчета обикновено излиза това, което отдавна е време да се изнесе в CLAUDE.md или в скил.

За едно изпълнение се разглеждат до двеста още невиждани сесии, съвсем късите се прескачат. Ако нещо е останало зад борда, в шапката на отчета до разгледаното число стои общото – например 200 sessions (412 total).

/insights                                # анализ на моите сесии

/skill-doctor

Кои заредени скилове не се използват и напразно заемат контекст. Всеки включен скил струва място в прозореца: описанието му се зарежда винаги, а тялото – само при задействане, и десетина забравени скила осезаемо стесняват полезния контекст. По резултатите се решава кое да се изключи и кое да се пренапише така, че да се задейства по предназначение.

/skill-doctor                            # кои скилове напразно висят в контекста

/explain-usage

Накъде са отишли токените на тази сесия, на човешки език. [Скил] За разлика от /usage, където има числа и разбивка, тук се получава разбор с изводи: кои ходове са излезли скъпи и защо. Полезно е, когато лимитът се топи по-бързо от очакваното, а по таблицата не е ясно какво точно да се прави.

/explain-usage                           # накъде са отишли токените

/install [версия] [--force]

Инсталиране на нативния билд направо от сесията – без пакетен мениджър и без излизане в терминала. Върши работа, за да преминете от npm инсталация към нативна или да се върнете към конкретна версия, когато свежата е счупила нещо важно. Аргументът е версия: stable или конкретен номер; --force я инсталира върху текущата.

/install stable                          # инсталиране на стабилния билд
/install 2.1.236 --force                 # конкретна версия, върху текущата

Информация и документация

/release-notes

Списък с промените по версии: какво се е появило, какво са поправили, какво са изключили. Да се чете си струва след всяко обновяване – значителна част от поведението на Claude Code се променя от билд на билд и „вчера работеше“ най-често се обяснява точно тук.

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

/release-notes                           # какво се е променило по версии

/powerup

Кратки интерактивни уроци за възможностите. Смисълът е, че много неща тук сами не се намират: планове, скилове, фонови задачи, хукове. Урокът върви направо в сесията и отнема няколко минути – това е начин да научите за едно нещо, а не да четете цялата документация.

/powerup                                 # кратък урок за възможностите

/mobile

QR код за инсталиране на мобилното приложение. Приложението е нужно заради работа извън работното място: да поставите задача по пътя и да видите с какво е свършила. Псевдоними: /ios, /android.

/mobile                                  # QR код на мобилното приложение

/radio

Lo-fi радио Claude FM в браузъра. Точно това, което изглежда: фонова музика, няма отношение към работата на агента.

/radio                                   # фонова музика

/passes

Споделяне на безплатна седмица с приятели и получаване на кредити. Командата не се вижда на всички: появява се само при акаунти, за които е достъпна, – така че в чужд /help може да я няма.

/passes                                  # споделяне на безплатна седмица

/upgrade

Преминаване към Max: по-високи лимити, повече Opus. Обикновено тук се попада направо от съобщението за изчерпан лимит. Ако опирате не в плана, а в конкретен модел, първо е по-евтино да опитате /model – смяната на семейството на модела решава точно този случай.

/upgrade                                 # преминаване към Max

/stickers

Поръчване на стикери. Няма отношение към работата на агента: отваря се форма за поръчка.

/stickers                                # поръчване на стикери

/team-onboarding

Генериране на онбординг ръководство за екипа от вашата история на използване. Смисълът е да не пишете такъв документ от нулата: той се сглобява от това как работите на практика, а не от общи съвети. На изхода е текст, който се редактира на ръка и се слага в хранилището.

/team-onboarding                         # ръководство за екипа от моята история

Премахнати и изключени команди

Свои раздели нямат – да ги набирате няма смисъл. Таблицата е нужна затова, че половината статии в интернет все още ги препоръчват и когато командата „не работи“, най-лесно е да погледнете тук.

Премахнати напълно:

Изключени отвътре в билда 2.1.251: регистрирани са, но не работят и в менюто не се показват.

Има и още команди, които се появяват според състоянието и които няма да видите, докато състоянието не настъпи: /limit-reset и /low-priority – когато сте опрели в лимита на сесията, /rate-limit-options, /pro-trial-expired, /design-consent и /design-revoke, а /setup-cowork живее само в режим Cowork. Плюс два съвсем вътрешни входа, __remote-workflow и workflow-launch-exec, през които сървърът предава на сесията готов воркфлоу.

И отделна категория – скиловете само за модела: keybindings-help, memory-types, cowork-plugin. Агентът ги зарежда сам, да се наберат не могат. Механизмът е общ и е достъпен и за вас – това е полето user-invocable: false във frontmatter на скила.

Две жилави заблуди накрая. Командата /alias не съществува: под това име в бинарния файл се намира описание на системната утилита alias за автодопълване на команди, въвеждани през !. И файлът .claudeignore също не съществува – за да накарате агента да игнорира файлове, използвайте .gitignore, който се отчита по подразбиране, или .ignore.

Как менюто търси команда

Дреболия, която спестява нерви. От версия 2.1.236 подсветката в менюто се задейства, ако буквите след / съвпадат с името на командата или с нейния псевдоним – от началото на името или от началото на дума в него, като разделителите :, _ и - при сравнението се игнорират. Затова /adddir подсветява /add-dir, а /new подсветява /clear през псевдонима ѝ.

Какво се е променило тогава и е по-важно: правописна грешка вече не се налучква. Преди Enter върху несъществуваща команда стартираше подобна. Сега след правописна грешка нищо не е подсветено, близките варианти остават в списъка и се избират със стрелките или с Tab, но Enter ще изпрати вашия текст както си е и ще съобщи за непозната команда.

Недостъпните команди от менюто просто изчезват – ще видите „няма команди по такава заявка“. Някои вместо това отговарят със свое съобщение за недостъпност: например /schedule при API ключ ще каже, че изисква акаунт. И с частично име скрита команда не може да се извади – трябва да се набере цялата.

Собствени команди

Собствената слеш команда е файл SKILL.md в папката на скила. Преди за това имаше отделна същност в .claude/commands/; сега командите и скиловете са слети в едно, старите файлове продължават да работят и дават точно същата команда.

Къде да търсите и къде да поставяте:

Името на командата се взема от името на папката, а не от полето name. При личните и проектните скилове name е само етикет в списъка. При плъгинните е обратното: name заменя последния сегмент, и my-plugin/skills/review/ с name: fancy дава /my-plugin:fancy. Краткият вариант /fancy също ще сработи, ако името не е заето от нищо друго.

Най-простият пример:

---
name: fix-issue
description: Разгледай issue по номер, намери причината и предложи поправка
argument-hint: <номер на issue>
allowed-tools: Bash(gh issue view:*), Bash(gh pr create:*)
---

Вземи issue номер $0 от това хранилище.

Текущо състояние на клона:

!`git status --short`

Прочети описанието, намери причината в кода, предложи минимална поправка
и обясни защо е минимална.

Извиква се като /fix-issue 4821. Тук $0 е първият аргумент, тоест 4821, а редът с ! се изпълнява, преди текстът да стигне до модела, и се заменя със собствения си изход. И за двете – подробно по-долу.

Полета на frontmatter

Те са двайсет. Полезно е да знаете, че изобщо съществуват – половината от тях решават проблеми, които иначе се решават с патерици.

Три ограничения, на които се спъват. Frontmatter се чете, само ако отварящите --- са на първия ред на файла. Полетата description и when_to_use в листинга се орязват до хиляда и петстотин знака – всичко над това моделът няма да види при избора на скил. А в старите файлове от .claude/commands/ работи същият frontmatter, освен name и paths – те там се игнорират.

Отделно за allowed-tools: това е предварително одобрение за един ход, а не ограничение. Разрешението отпада с вашето следващо съобщение, въпреки че съдържанието на скила остава в контекста. И има неприятно свойство, което трябва да знае всеки, който пуска агент в чуждо хранилище: доверието към папката не го ограничава. Проектният скил ще приложи своя allowed-tools и в папка, която никога не сте отбелязвали като доверена, включително при неинтерактивно стартиране. Тоест скил, който се намира в хранилището, може да си даде широки права – четете това поле в чужди хранилища, преди да стартирате.

Аргументи: номерация от нула

Най-неочакваното място в цялата тема, и си струва да се запомни дословно.

Да, $0 е първият аргумент, а не името на командата, както в шела. Грешката с единица е най-честата тук.

Индексираните аргументи се разбират с отчитане на кавичките: в /my-skill "hello world" second стойността на $0 е целият hello world. Индексирано заместване, за което не е стигнал аргумент, остава в текста както е; именуваното се превръща в празен низ. Ако в стойността на аргумент се окаже самият $1 или $ARGUMENTS, той се вмъква буквално и втори път не се разгъва. Екранирането е с една обратна наклонена черта: \$1.00. И ако нито едно заместване в тялото не е получило аргументи, редът ARGUMENTS: <стойност> просто се дописва накрая.

Вградени команди на шела

Записът !`команда` се изпълнява преди съдържанието да стигне до модела и се заменя със собствения си изход. Така в скила се подава актуално състояние: клонът, diff-ът, списъкът с паднали тестове. С какво точно да се изпълнява – bash или powershell – се задава от полето shell във frontmatter.

Има две правила, които спестяват половин час недоумение. Записът се разпознава, само ако ! е в началото на реда или веднага след интервал – в KEY=!`cmd` тя ще остане текст и няма да се изпълни. И заместването минава през файла веднъж: изходът на командата повторно не се сканира, затова командата не може да изведе друго заместване с надеждата за втори пас.

За многоредов скрипт се отваря блок с код с удивителен знак след трите обратни кавички.

Всичко това се изключва с ключа disableSkillShellExecution: всяка команда се заменя със съобщение, че е забранена от политиката. Действа върху потребителските, проектните, плъгинните скилове и скиловете от добавените папки; вградените и корпоративните не ги засяга. Скиловете, синхронизирани с claude.ai, никога не изпълняват такива команди локално, независимо от настройката.

Променливи за пътища

Вътре в тялото на скила и вътре в правилата на allowed-tools се подставят ${CLAUDE_SKILL_DIR} – папката на самия скил, ${CLAUDE_PROJECT_DIR} – коренът на проекта, ${CLAUDE_SESSION_ID}, а в плъгинните скилове още ${CLAUDE_PLUGIN_ROOT} и ${CLAUDE_PLUGIN_DATA}.

Това, че работят и на двете места, не е дреболия, а работен похват: така скилът стартира собствения си скрипт без нито един въпрос за права.

---
name: render
description: Изобразява схема от изходния файл
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *)
---

Стартирай `${CLAUDE_SKILL_DIR}/scripts/render.sh $0` и покажи резултата.

Правилото разрешава точно онази команда, която тялото указва да се изпълни – нито по-широко, нито по-тясно.

Дреболии, които е полезно да знаете

Скиловете се комбинират. В началото на едно съобщение може да се поставят до шест команди: /write-tests /fix-issue 123 ще зареди двата скила и ще подаде 123 и на двата като аргумент. До версия 2.1.199 се зареждаше само първият, а останалото се считаше за текст. Изключение е /code-review, която си взема остатъка от реда.

ultrathink в тялото на скила моли модела да мисли по-дълбоко, когато скилът се задейства. Работи направо като дума в текста.

Имената на вградените команди са запазени, дори в сесията ви да са недостъпни: скил с конфликтно име, дошъл от синхронизация, ще бъде пропуснат.

Скил може да се провери и без плъгин: claude plugin validate <път> работи и върху обикновена папка със скилове и агенти. А за да стане папката със скилове плъгин, достатъчно е да сложите в нея .claude-plugin/plugin.json.

Настройки: settings.json

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

Означения: [експ] – експериментален или вътрешен ключ, може да се промени или да изчезне; [админ] – действа само от корпоративен източник; [остар] – остарял; [глобален] – живее не в settings.json, а в ~/.claude.json.

Къде се намира файлът

Нивата не са четири и не са пет, а повече, отколкото обикновено се пише. Да започнем с обикновените:

Последният ред е онова, което го няма почти никъде. Част от настройките живеят само в ~/.claude.json и ако ги напишете в settings.json, ще бъдат тихо пренебрегнати. Там Claude Code слага и сесията ви за вход, конфигурацията на MCP сървърите и решенията за доверие към папки. Обикновено този файл се пише сам и рядко се бърка ръчно в него – но трябва да знаете за него, защото „зададох ключа и нищо не стана“ най-често се обяснява точно с това.

Корпоративната политика също не е една. Източниците са четири и са наредени по ранг:

Политиката от системата и HKCU се прочита наново на всеки половин час, сървърните настройки – веднъж на час. По подразбиране източниците не се събират: прилага се най-старшият, останалите се отхвърлят. Това може да се промени с ключа managedSourcesBehavior: "merge", но той трябва да се зададе в най-старшия от внедрените източници – долният не може сам да поиска сливане, а HKCU не се слива никога.

Ако админът е сложил нещо, а то „не е стигнало“ – вижте в /status: от версия 2.1.243 там има ред за пропуснатите източници, където направо пише кой файл е игнориран.

Формат: строг JSON

Тук трябва да поправя самия себе си, защото преди мислех другояче и в интернет това се повтаря често.

Файловете с настройки са строг JSON. Коментар // или висяща запетая е синтактична грешка и при следващото стартиране файлът ще бъде отбелязан като грешен изцяло. Никакъв JSONC. (Объркването възниква, защото JSONC в продукта наистина има на други места – например /terminal-setup разбира конфигурацията на редактора с коментари.)

Най-лесно е да проверите файла си със стартиране: грешките в настройките се печатат при старта. claude doctor ще ги покаже с разбор.

Полезен навик е редът $schema:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json"
}

Редакторът започва да подсказва имената на ключовете и да подчертава правописните грешки, а грешка в името на ключ е най-честата причина настройката да „не работи“: неизвестните ключове се игнорират тихо. Уточнение: схемата понякога изостава от продукта. Например teammateDefaultModel в нея още го има, а от Claude Code е премахнат във версия 2.1.234 и на нищо не влияе.

Кой кого припокрива

Редът на нивата е този от таблицата по-горе. Но „припокрива“ не е вярно за всичко, и ето три изключения, които чупят интуицията.

Списъците се събират, а не се заменят. Ако permissions.allow е зададен и в потребителския, и в проектния файл, ще получите обединението на двата. По-горното ниво не може да премахне запис на по-долното – единственото, което го може, е корпоративният allowManagedPermissionRulesOnly. Всяка таблица с приоритети, в която пише „всяко следващо припокрива предишното“, за списъците е невярна.

Четири списъка се държат иначе: fallbackModel се взема изцяло от най-старшия файл, който го определя (това е наредена верига, смесването ѝ няма смисъл); modelPicker – изцяло от най-старшия сред корпоративния, --settings и потребителския, а в проектния и локалния се игнорира; availableModels от админа се прилага както е, без да поема вашите добавки; modelSettings се разрешава поотделно за всеки модел.

При седем ключа строгата стойност отдолу побеждава корпоративната. Обикновено политиката е абсолютна – не я бие дори --settings. Но за тези ключове по-строгият вариант от всяко ниво печели, защото да си забраните излишното никой няма да ви пречи: disableClaudeAiConnectors със стойност true, enableArtifact със стойност false (и disableArtifact: true), isolatePeerMachines със стойност true, remoteControlAtStartup със стойност false от проектния или локалния файл, crossSessionInbound с по-строга стойност по скалата „приемане – задържане – отказ“, useAutoModeDuringPlan и syncClaudeAiSkills със стойност false.

Проектните разрешения чакат доверие към папката. permissions.allow и permissions.additionalDirectories от проектния файл започват да действат едва след като потвърдите доверие към тази папка. deny и ask действат веднага – те само ограничават.

А ето най-важното и това трябва да го прочете всеки, който стартира claude -p в чуждо хранилище. В неинтерактивен режим диалогът за доверие не се показва, затова проектните разрешаващи правила се отхвърлят с предупреждение в потока за грешки – но хуковете на това хранилище се изпълняват, блокът му env се прилага, помощните му скриптове за авторизация се стартират, полето allowed-tools на скиловете му действа, а сървърите от неговия .mcp.json се свързват без въпроси. Отхвърлят се именно разрешенията, а не изпълнимите части.

Безопасното стартиране в непроверена папка е --setting-sources user, --bare, --restricted или --settings '{"disableAllHooks": true}'. Просто да зададете disableAllHooks в личния си файл не е достатъчно: проектният файл е по-старши и ще го върне обратно.

Променливите на средата не са ниво

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

• ANTHROPIC_MODEL от шела припокрива ключа model от всеки файл.
• ANTHROPIC_DEFAULT_MODEL действа само ако model не е зададен никъде.
• --model и /model припокриват ANTHROPIC_MODEL.
• А CLAUDE_CODE_EFFORT_LEVEL е устроен обратно и припокрива --effort и /effort.

И отделно: стойността от блока env в настройките побеждава експорта от шела, а не обратното, както е прието да се мисли. Claude Code записва всеки запис от блока в средата на процеса върху наследената стойност. Променлива не може да се премахне от файла с настройки – може да се зададе празен низ, което при избора на доставчик се смята за „не е зададена“ (макар дъщерните процеси да получат празна стойност). Променливите на шела се четат веднъж при старта, а стойностите от env се прочитат наново при промяна на файла – освен подсистемите, които се настройват само при стартиране, като телеметрията.

Скелет на файла

Скаларите като model, theme, числата и флаговете се пишат на най-горното ниво. Групираните настройки – permissions, env, hooks, statusLine, worktree, voice, sandbox, sshConfigs – са вложени обекти.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "opus",
  "outputStyle": "default",
  "theme": "dark",
  "autoCompactEnabled": true,
  "cleanupPeriodDays": 30,
  "includeCoAuthoredBy": false,
  "env": {
    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "1",
    "DISABLE_TELEMETRY": "1"
  },
  "permissions": {
    "allow": ["Bash(npm run build)", "Edit(src/**)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Read(./.env)"],
    "defaultMode": "acceptEdits",
    "additionalDirectories": ["../shared-lib"]
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm run lint" }]
      }
    ]
  },
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 1
  },
  "worktree": {
    "symlinkDirectories": ["node_modules"],
    "baseRef": "fresh"
  },
  "enabledPlugins": {
    "formatter@anthropic-tools": true
  }
}

Автентикация и доставчици

Стойността gateway на forceLoginMethod се взема предвид само от източник, намиращ се на самата машина: файл на политика, домен на настройките на macOS или клон HKLM. В потребителския, проектния, локалния и в HKCU се смята за незадена – иначе корпоративният вход би могъл да се пренасочи от хранилището.

Модел, мислене, усилия

Три стойности по подразбиране, които променят поведението и за които рядко се пише.

switchModelsOnFlag е включен. Тоест при задействане на филтъра за сигурност моделът тихо се сменя, за да не се прекъсва диалогът. Ако го изключите, интерактивната сесия ще спре и ще ви попита, а неинтерактивното стартиране ще завърши заявката с грешка – за скриптове това често е по-правилно, защото тихата подмяна на модела в CI изглежда като необяснима промяна в поведението.

promptCacheTtl се подбира сам: час при абонамент, иначе пет минути. Променливата на средата го припокрива.

effortLevel не приема max умишлено, за да не остава максималното ниво включено завинаги; за сесията се задава с команда или флаг.

Права за достъп на инструментите

Най-практически важната част от файла – и най-подценената по броя подводни камъни. Вложеният обект permissions:

Наред с тях са ключовете от най-горното ниво: skipDangerousModePermissionPrompt и skipAutoPermissionPrompt помнят, че вече сте приели съответното предупреждение; allowManagedPermissionRulesOnly [админ] нарежда да се вземат предвид само списъците от политиката; disableAutoMode изключва авто режима; useAutoModeDuringPlan позволява да се прилага в режим на планиране, по подразбиране – да.

Режими

dontAsk не значи „не питай за дреболии“. Това е най-опасното недоразумение в цялата тема за правата и аз самият го повтарях. Режимът не смекчава, а затяга: всичко, което в обикновения режим би породило въпрос, се забранява автоматично. Работи само онова, което е попаднало в allow, вграденият набор от безопасни команди за четене и онова, което е одобрил хук. Вашите собствени правила ask в този режим не питат, а отказват; въпросът на агента към вас също се отхвърля, дори да е разрешен.

Още една тънкост: стойността auto не действа от проектните и локалните настройки – трябва да се зададе в потребителския файл. А сесиите, стартирани от разширението за VS Code, четат само потребителския, корпоративния и --settings.

Формат на правилото

Правилото се записва като Инструмент(уточнение): Bash(npm run build), Edit(src/**), Read(~/.zshrc).

{
  "permissions": {
    "allow": ["Bash(npm run:*)", "Edit(src/**)", "Read(~/.config/**)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Read(./secrets/**)", "Read(./.env)"],
    "defaultMode": "acceptEdits",
    "additionalDirectories": ["../shared", "/tmp/workspace"]
  }
}

Изглежда просто. По-нататък са дванадесет правила за поведение, всяко от които обяснява някой популярен въпрос „защо правилото ми не работи“.

Ред на проверка: първо забрана, после въпрос, после разрешение

Правилата се проверяват в строго определен ред – deny, после ask, после allow – и печели първото съвпадение, а не най-точното. Оттук две следствия, които чупят очакванията.

Широката забрана припокрива тясното разрешение: deny с Bash(aws *) ще блокира allow с Bash(aws s3 ls). Изключения от забраната няма – механизъм „забрани всичко освен“ тук няма.

Съвпаднало ask пита, дори да има по-точно allow. Това не е грешка, това е начин да кажете „тази команда винаги я потвърждавам ръчно“, и работи върху всякакви разрешения.

Между нивата на настройките е същото: забрана от потребителския файл бие разрешение от проектния и обратно, защото всички deny от всички нива се проверяват преди всяко allow.

Още една дреболия с големи последствия: голо име на инструмент в deny премахва инструмента от контекста изцяло. Записът "Bash" в забраните означава, че агентът изобщо няма да научи за този инструмент. А Bash(rm *) оставя инструмента видим и забранява само съвпадащите извиквания.

Защитените пътища се проверяват преди вашите правила

Съществува списък с пътища, записът в които се проверява преди да се погледне allow. Затова Edit(.claude/**) във всеки файл с настройки не дава съвсем нищо – и това е най-честият източник на въпроса „защо разрешението ми се игнорира“.

В списъка със защитени каталози са: .git, .config/git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn и .claude изцяло, освен .claude/worktrees. От файловете – .gitconfig, .gitmodules, всички файлове на профили и стартиране на шела, .envrc, .npmrc, .yarnrc*, .pnp.cjs, bunfig.toml, .bazelrc, .pre-commit-config.yaml, lefthook.*, gradle-wrapper.properties, .ripgreprc, pyrightconfig.json, .mcp.json и .claude.json.

Логиката е ясна: всичко това са файлове, чиято промяна променя поведението на самата ви машина при следващата команда, чак до това, че ще се изпълни нещо вместо git commit. Какво ще стане при опит, зависи от режима: обикновеният и acceptEdits ще попитат, plan ще позволи само ако е достъпно заобикалянето, auto ще го предаде на класификатора, dontAsk ще откаже, bypassPermissions ще позволи. В диалога има и отделна опция – да разрешите промяна на собствените си настройки за тази сесия.

Предпазител при изтриване

rm и rmdir, насочени към критични пътища, не се одобряват с нищо: нито с правило в allow, нито с хук, върнал разрешение.

Критичните пътища са коренът на файловата система и всеки негов пряк потомък, домашната папка, корените на дисковете в Windows и техните каталози от първо ниво, текущата работна папка и нейните родители, както и шаблоните вътре в добавените директории.

Най-интересна е таблицата по режими, защото е устроена не така, както всички очакват:

Тоест режимът „заобикаляй всички потвърждения“ тук е по-строг от авто режима: --dangerously-skip-permissions на такова изтриване въпреки това ще спре.

Брои се и онова, което изглежда безобидно: rm -rf "$DIR"/* попада под предпазителя, защото празната променлива го превръща в изтриване от корена. Скриването на командата в заместване, обратни кавички или заместване на процес няма да помогне – проверката ги вижда.

Четири котви на пътя

Правилата Read и Edit използват синтаксиса на .gitignore и в него има четири различни начина да се закачи път. Постоянно ги бъркат.

Третият ред е капан. Единична наклонена черта в началото не означава абсолютен път: тя вързва правилото към онзи файл с настройки, където е написано. Правилото Read(/secrets/**) в ~/.claude/settings.json означава ~/.claude/secrets/**, а съвсем не secrets във вашия проект. В проектните настройки същата черта се отчита от основната работна папка, в --settings – от папката на посочения файл, а правилата от локалните настройки от версия 2.1.211 са вързани за работната папка на сесията, а не за корена на хранилището – тоест в отделно работно копие Edit(/src/**) ще попадне в собствения му src.

Голото име на файл се държи като в .gitignore и съвпада на всяка дълбочина: Read(.env) е същото като Read(**/.env). А Read(//**/.env) е вързано за корена на файловата система.

В Windows пътищата се привеждат към POSIX вид преди сравнението: C:\Users\alice се превръща в /c/Users/alice. Затова правилото за всички дискове се пише като //**/.env, а за конкретен – //c/**/.env.

Едно и също правило хваща различна дълбочина в allow и в deny

Едносегментният относителен шаблон на папка се държи асиметрично и това е нарочно.

Edit(src/**) в allow съвпада само с папката src в корена на работната директория. Същото в deny или ask съвпада с папката src на всяка дълбочина – тоест хваща и vendor/pkg/src/lib.js.

Смисълът е ясен: разрешението трябва да е тясно, забраната – широка. Всички останали форми се държат еднакво във всеки тип правила: Edit(/src/**) и Edit(src/components/**) съвпадат само там, където са написани, Edit(**/src/**) – навсякъде. Поведението се промени във версия 2.1.214: до нея Edit(src/**) хващаше всяка дълбочина и в разрешенията.

Двоеточие само в края, а интервалът пред звездичката е значим

Формата Bash(ls:*) е точно същото като Bash(ls *). Но се разпознава само в края на шаблона: в Bash(git:* push) двоеточието е обикновен символ и правилото няма да съвпадне с нищо.

Интервалът пред звездичката е част от правилото. Bash(ls *) изисква интервал и затова не съвпада с lsof; Bash(ls*) – съвпада. Завършващата звездичка хваща и голата команда без аргументи, но само ако е единствена в правилото: Bash(ls *) ще съвпадне с ls, а Bash(* --help *) ще съвпадне с npm --help x и няма да съвпадне с npm --help.

Всичко, което стои пред първата звездичка, се сравнява буквално. Оттук и неприятността: Bash(git * main) разрешава всяка подкоманда на git, включително -c с произволна конфигурация. От версия 2.1.246 за разрешаващите правила със звездичка пред подкомандата при стартиране се печата предупреждение.

Съставни команди

Разделителите, които Claude Code разбира: &&, ||, ;, |, |&, & и нов ред. Всяка част трябва да съвпадне с правило поотделно – общо разрешение за целия ред няма.

Отделен случай: ако операторът е в края и след него няма нищо – например npm test && – командата се смята за неразбираема и изобщо не се дели. Тогава дори Bash(npm *) няма да я одобри.

Когато отговорите „да, и повече не питай“ на съставна команда, се запазва отделно правило за всяка част, за която е било нужно. Преминаването в подпапка ще породи собствено правило за четене. Повече от пет правила от една команда не се запазват.

Пренасочванията на изхода >, >>, 2> се проверяват като запис във файл – спрямо вашите правила Edit, списъка със защитени пътища и работните директории. /dev/null е изключен от проверката; цел, започваща с ~ или съдържаща шаблон, изисква потвърждение винаги.

Кои обвивки се свалят и кои не

Преди да се сравни с правилата, от командата се махат: timeout, time, nice, nohup, stdbuf, вградените command и builtin, noglob от zsh и голият xargs – последният само без флагове, xargs -n1 grep се разбира като команда xargs.

Свалява се и водещото присвояване на позната безопасна променлива, затова Bash(npm test *) ще съвпадне с NODE_ENV=test npm test. Разрешаващото правило не минава през присвояване на каквато и да е друга променлива, а забраняващото минава през всяка.

Списъкът е фиксиран и не се настройва. И в него няма нито един стартер на среда: npx, docker exec, direnv exec, devbox run, mise exec не се свалят. Практически извод: Bash(devbox run *) е разрешение за devbox run rm -rf ., защото за проверката това е команда devbox, а не rm.

Отделно има команди, които не могат да се одобрят с префиксно правило никога: watch, setsid, ionice, flock, а също find с -exec или -delete. В обикновения режим те ще питат винаги.

Правилата за Write, Glob, NotebookEdit и MultiEdit се приемат и не работят

Файловите права се проверяват само спрямо правилата Edit(...) и Read(...). Правило от вида Write(docs/**) или Glob(docs/**) ще бъде разпознато, запазено, показано в /permissions – и никога използвано. От версия 2.1.210 за такова нещо при стартиране се печата предупреждение.

Пишете Edit(...) вместо Write, NotebookEdit и MultiEdit и Read(...) вместо Glob. Голото име на инструмента без път работи: Write може да се забрани изцяло.

Полезно следствие: забраняващо правило Read за път блокира и редактирането, и записването в него – но не и NotebookEdit.

Символични връзки

Всяко обръщение към файл се проверява едновременно по два пътя: по самата връзка и по онова, накъдето води. Правилата тук са асиметрични.

Разрешението действа, само ако съвпаднат и двата пътя. Затова връзка вътре в разрешена папка, водеща навън, все пак ще попита.

Забраната действа, ако съвпадне поне единият. Затова връзката към забранен файл е забранена сама.

На практика: ако е разрешено Read(./project/**) и забранено Read(~/.ssh/**), то ./project/key, който води към ~/.ssh/id_rsa, ще бъде блокиран.

Правила по параметри на инструмента

Малко известно семейство. Забраняващите и питащите правила могат да съвпадат по скаларно поле от входните данни на инструмента:

{
  "permissions": {
    "deny": ["Agent(model:opus)", "Agent(isolation:worktree)", "Bash(run_in_background:true)"]
  }
}

Един параметър на правило, вложени полета не се поддържат, * се подставя вместо стойност. Параметър, който моделът не е подал, не съвпада никога – тоест Agent(model:opus) няма да хване извикване, където моделът изобщо не е посочен. Стойността се сравнява с онова, което е дошло, преди нормализацията: псевдонимът opus ще съвпадне, а пълният идентификатор на същия модел – не.

Основното поле на инструмента по този начин не се съпоставя нарочно: command, file_path, path, notebook_path, url са изключени. Правилото Bash(command:rm *) се игнорира с предупреждение – твърде лесно би се заобиколило със съставна команда.

За MCP инструментите параметричните правила работят само през флага --disallowedTools: всяко правило с mcp__ и скоби във файл с настройки се пропуска и попада в списъка с некоректни настройки и в изхода на claude doctor.

Шаблони в името на инструмента

В забраняващите и питащите правила името на инструмента може да се зададе с шаблон и той трябва да покрива името изцяло: "*" – всички инструменти, "mcp__*" – всички инструменти на MCP.

В разрешаващите правила шаблонът е допустим само след буквален префикс mcp__<сървър>__, при това името на сървъра трябва да е без шаблони. Тоест mcp__github__get_* работи, а "*", "B*" и "mcp__*" в allow се пропускат с предупреждение и не разрешават нищо.

И още един капан: името на инструмента на екрана може да се различава от каноническото. Онова, което е показано като „Stop Task“, канонически се нарича TaskStop, и в правилата и във филтрите на хуковете работи само каноничното име.

WebFetch – две различни правила с подобен вид

Голото WebFetch и WebFetch(domain:*) не са едно и също, защото втората форма заедно с това променя списъка с домейни на пясъчника.

Шаблони в домейна: *.example.com хваща поддомейни на всяка дълбочина, но не и самия example.com. На всяка друга позиция звездичката съвпада само с текста между две точки – example.* ще хване example.org и няма да хване example.evil.com.

И една трезва забележка: докато агентът има достъп до шела, разрешенията на WebFetch не ограничават мрежовия достъп по никакъв начин.

Вграден набор от безопасни команди

Част от командите се изпълняват без въпрос във всеки режим и този списък е зашит: ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd и read-only формите на git. Не може да се разшири, може само да се припокрие със свое правило ask или deny.

Но и той ще попита, ако: в команда, която има флагове за запис или стартиране (find, sort, sed, git – шаблонът би могъл да се разгърне в -delete), е срещнат шаблон без кавички; при docker има -H, --context, --url или --connection; при file има -m, --magic-file, -f или --files-from; в аргументите има мрежов път на Windows; командата е по-дълга от десет хиляди знака или не се разбира. Освен това cd заедно с git ще попита, ако папката наистина се сменя – в новата папка може да има свои хукове на git.

PowerShell

Правилата за PowerShell са устроени по същия начин, сравняват се без отчитане на регистъра и привеждат популярните псевдоними към канона: PowerShell(Get-ChildItem *) ще съвпадне и с gci, и с ls, и с dir. Командата се разбира по синтактичното дърво и се дели по |, ;, а в седма версия още и по && и ||; всяка част се проверява поотделно.

Remove-Item има своя проверка, по-строга от тази на rm: системните пътища и целите с шаблон – гола *, всичко, което завършва на /* или \*, включително $dir/*, – се забраняват във всички режими без въпрос, още преди класификатора. По обикновените правила на режима минава само случаят „работната папка или нейният родител с рекурсия“, и именно за него режимът за заобикаляне на потвържденията премахва въпроса.

И отделно за Windows: всяка команда, в чиито аргументи има мрежов път от вида \\сървър\ресурс\файл, ще поиска потвърждение, дори в останалото да е безобидна, – такъв път може да отмъкне идентификационните данни на Windows.

Авто режим

От версия 2.1.283 това е режимът по подразбиране за интерактивните сесии в терминала и VS Code при всички планове; в по-ранните версии – само при Pro, Max, Ultra и Team. Решението за всяко действие се взема от класификатор, а не от списък с правила, и се настройва с отделен обект autoMode.

Три неща, които тук са по-важни от самата таблица.

Редът "$defaults" е задължителен почти винаги. Във всеки от четирите списъка той добавя стандартния набор правила. Ако не го напишете, целият вграден списък на тази секция тихо изчезва – заедно с меките блокове за форс-пуш, за curl | bash, за внедряване в продукция и за заобикаляне на самия авто режим, и с твърдия блок за изтичане на данни. Вашите правила трябва да допълват набора, а не да го заменят.

Тесните разрешения заобикалят класификатора. Правило като Bash(npm test) в авто режима продължава да действа и се разглежда преди класификатора. Спират се само широките разрешения за произволно изпълнение – Bash(*), интерпретатори със звездичка – и всички правила, назоваващи инструмент за наблюдение. Тоест тясно правило може да пропусне разрушителен аргумент, който никой не е погледнал. Затваря се с classifyAllShell: true, и тогава за времето на авто режима се изключват всички разрешаващи правила на шела.

Класификаторът не чете настройките на проекта. Взема autoMode само от потребителския файл, корпоративния и --settings. Иначе хранилището би могло да си подхвърли разрешения; локалните настройки се четяха до версия 2.1.207, сега вече не.

Конфигурацията може да се разгледа и разбере от терминала:

claude auto-mode config                       # какво действа и откъде идва
claude auto-mode defaults                     # стандартните правила на всичките четири списъка
claude auto-mode defaults --label 'Git Destructive'   # пълният текст на едно правило
claude auto-mode critique                     # разбор на вашите правила от модела
claude auto-mode reset --yes                  # връща стандартните без въпрос

Подкомандата critique е подценена: тя моли модела да анализира вашите собствени правила и да покаже онези, които са двусмислени, излишни или ще дават фалшиви задействания.

Режимът се изключва с ключа disableAutoMode, и тук има капан: стойността трябва да е низът "disable". Масив или true схемата ще пропусне без грешка, но кодът сравнява именно с низ и режимът тихо ще остане включен. Съветникът за настройка може да се скрие със записа "auto-mode-setup": "off" в skillOverrides; disableBundledSkills не го изключва, защото това е вградена команда, а не скил.

MCP сървъри

Последният ред поправя разпространено твърдение, което и аз самият преди повтарях: „сървърите се задават само в .mcp.json, а в настройките – само правата за тях“. Това е вярно за вас, но не и за администратора: managedMcpServers в корпоративните настройки съдържа именно конфигурациите на сървърите и се разгръща върху всички през файл на политика или система за управление на устройства.

Обикновените сървъри се задават в .mcp.json или през claude mcp add.

Хукове

Хуковете са тема за отделна статия и аз имам такава: там са разгледани всички събития, форматите за обмен и работни примери. Тук са ключовете на настройките и онова, което най-често се чупи.

hooks е обект от вида „събитие → масив от матчери“. Матчерът има филтър matcher и списък с обработчици.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npm run lint" },
          { "type": "command", "command": "echo", "args": ["done"] }
        ]
      }
    ]
  }
}

Събитията са трийсет и три. За инструментите: PreToolUse, PostToolUse, PostToolUseFailure, PostToolBatch. За разговора: UserPromptSubmit, UserPromptExpansion, Stop, StopFailure, Notification, MessageDisplay. За сесията: SessionStart, SessionEnd, Setup, InstructionsLoaded, ConfigChange. За свиването и смяната на модела: PreCompact, PostCompact, PreModelSwitch, PostModelSwitch. За правата: PermissionRequest, PermissionDenied. За субагентите и задачите: SubagentStart, SubagentStop, TeammateIdle, TaskCreated, TaskCompleted. За файловете и папките: FileChanged, CwdChanged, DirectoryAdded, WorktreeCreate, WorktreeRemove. И две за формите на MCP: Elicitation, ElicitationResult.

Обработчикът е от пет вида, видът се задава с полето type: command стартира програма или ред на шела, prompt пита малък бърз модел, agent изпраща пълноценен агент, http извиква адрес, mcp_tool извиква инструмент на MCP сървър. Общите незадължителни полета са if с условие, timeout, statusMessage за спинъра, once за еднократно изпълнение за сесия и async със свързаното asyncRewake.

Три неща, заради които хукът „работи, но нищо не прави“

Изходен код 1 нищо не блокира. Блокира само код 2, и то само при около една трета от събитията. Единицата и всеки друг ненулев код при повечето събития са просто неблокираща грешка в журнала. Код 2 при това е по-силен от вашия собствен JSON: дори да сте върнали решение „разреши“, двойката ще забрани.

Къде двойката блокира: PreToolUse, UserPromptSubmit (изтривайки промпта), UserPromptExpansion, Stop, SubagentStop, TeammateIdle, TaskCreated, TaskCompleted, ConfigChange, PostToolBatch, PreModelSwitch. Къде се игнорира: PermissionRequest и PermissionDenied – там решават полетата на JSON, – и StopFailure. При PostToolUse двойката не блокира, а се показва на модела. При WorktreeCreate прекъсва всеки ненулев код. И отделна асиметрия: изтекъл таймаут при PreToolUse не блокира, а при PreModelSwitch – блокира.

Изходът на хука моделът почти никога не го вижда. Обикновеният текст в стандартния изход при код 0 попада в журнала за дебъгване, а не в разговора. На модела се показва точно при четири събития: UserPromptSubmit, UserPromptExpansion, SessionStart и PostModelSwitch. Потокът за грешки не се показва никъде и никога. При останалите събития нещо може да се предаде на модела само със структуриран отговор – поле за допълнителен контекст или системно съобщение. JSON при това се разбира само ако изходът започва с { и завършва с }.

Филтърът понякога се игнорира изцяло, а понякога е регулярен израз. "*", празен низ или липса на полето означават „всички“. Филтър, състоящ се само от букви, цифри, _, -, интервали, запетаи и |, е точно съвпадение или изброяване. Всеки друг символ го превръща в регулярен израз, който се проверява без привързване към началото и края, ако не сте ги написали сами. Регистърът се отчита.

И филтърът не винаги е за името на инструмента. При SessionStart се сравнява с начина на стартиране, при SessionEnd – с причината за завършване, при свиването – с manual или auto, при ConfigChange – с това кой файл с настройки е променен, при FileChanged – с името на файла, при смяна на модела – с каноничното име на модела. А събитията UserPromptSubmit, PostToolBatch, Stop, CwdChanged, TeammateIdle, задачите, работните копия и MessageDisplay изобщо не приемат филтър и тихо игнорират написания.

Таймаутите по подразбиране са различни: при command, http и mcp_tool – десет минути, но при UserPromptSubmit и при събитията за смяна на модела трийсет секунди, а при MessageDisplay десет; при prompt – трийсет секунди, при agent – минута; на всички хукове SessionEnd заедно се отделя секунда и половина. Асинхронните изобщо не са ограничени.

В Windows е добре да помните за формата с отделен списък с аргументи: тя се изпълнява без шел и ѝ трябва истински изпълним файл – обвивките .cmd и .bat изискват или низова форма, или стартиране през интерпретатор.

Git: комити, pull request, атрибуция

{
  "attribution": { "commit": "", "pr": "" },
  "includeGitInstructions": true
}

Интерфейс и терминал

Стойности на theme: auto (по фона на терминала), dark, light, light-daltonized, dark-daltonized, light-ansi, dark-ansi, а също custom:<име> за тема от ~/.claude/themes/ и custom:<плъгин>:<име> за тема от плъгин.

Част от ключовете се четат само от потребителския файл, --settings и политиката: spinnerTipsOverride с файл с подсказки, footerLinksRegexes и spellcheck. Проектният файл не може да ги припокрие – иначе хранилището би могло да ви дорисува в интерфейса произволна връзка.

Настройки, които живеят в ~/.claude.json

Тези ключове в settings.json се игнорират тихо. Обикновено ги пише самият Claude Code или /config, но е полезно да знаете за тях.

Първият ключ си струва да се научи: комбинацията Ctrl+E върху въпроса за стартиране на команда дава човешки разбор на това какво прави тази команда – без да се изпълнява. При непозната команда от чуждо хранилище това е точно бутонът, който липсва.

Ред на състоянието

Полета на statusLine: type със стойност "command", command със скрипта, padding, refreshInterval – преизчислява на всеки толкова секунди, – и hideVimModeIndicator, ако скриптът рисува режима на vim сам.

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 1,
    "refreshInterval": 5
  }
}

Скриптът получава на входа JSON с контекста на сесията: модел, папка, цена, запълненост на контекста. Той печата един ред. Това е може би най-подценената настройка: постоянно видимите цифри за разхода променят поведението по-силно от всякакви инструкции за икономия. Имайте предвид само, че disableAllHooks изключва и нея.

Контекст, памет, сесии

За autoContinueAtUsageLimit си струва да знаете две неща: включен е по подразбиране и се чете само от потребителския файл, --settings и политиката – тоест проектен или локален файл, който го задава, не се игнорира, а изключва възможността.

Скилове

skillOverrides си струва да го знае всеки, който има много скилове: описанията им висят в контекста постоянно, и name-only за рядко нужните освобождава забележимо парче. Същият ключ е начин да забраните на агента сам да стартира конкретна команда, оставяйки я на вас: стойността user-invocable-only.

Плъгини и маркетплейси

Workflow-и, агенти, тиймейти

Стойността auto на teammateMode е определена точно: разделени панели, ако сесията върви вътре в tmux, или вътре в iTerm2 с достъпна помощна програма за командния ред, или ако tmux е инсталиран; иначе всичко се изпълнява вътре в процеса. Стойността iterm2 – родни разделени панели на iTerm2, появи се във версия 2.1.186.

Ключът teammateDefaultModel в схемата още го има, но е премахнат от продукта във версия 2.1.234 и на нищо не влияе.

Worktree

Вложеният обект worktree управлява как се създават отделни работни копия за сесиите и фоновите агенти.

{
  "worktree": {
    "symlinkDirectories": ["node_modules", ".cache"],
    "sparsePaths": ["packages/app", "packages/shared"],
    "baseRef": "fresh",
    "bgIsolation": "worktree"
  }
}

Отдалечено управление, SSH, среди

Три от тези ключове приемат само истинско булево true: низът "true" или единицата ще бъдат игнорирани с предупреждение в журнала. Това са disableDesktopLocalSessions, disableBrowserExternalNavigation и disableMobileSimulatorTools. Терминалният CLI изобщо не ги чете – те са за desktop приложението.

За requireCoworkFullVmSandbox има важен страничен ефект: вътре в пълната виртуална машина няма нито политика на устройството, нито файл с корпоративни настройки – доставянето им там ще трябва да стане по друг начин.

{
  "remote": { "defaultEnvironmentId": "env-123" },
  "sshConfigs": [
    {
      "id": "prod-box",
      "name": "Prod",
      "sshHost": "[email protected]",
      "sshPort": 22,
      "startDirectory": "~/app"
    }
  ]
}

Известия, глас, почивки

{
  "voice": { "enabled": true, "mode": "hold", "autoSubmit": true },
  "breakReminder": { "enabled": true, "intervalMinutes": 120 },
  "quietHours": { "enabled": true, "start": "22:00", "end": "07:00" }
}

Пясъчник и мрежа

Обектът sandbox управлява какво е разрешено на процесите вътре в изолацията. Най-дългият раздел от схемата и най-рядко използваният – но ако пускате агента в режим, в който той не пита за разрешения, четете именно него.

Веднага ще поправя една разпространена грешка в структурата: пътищата за четене и запис стоят не директно в sandbox, а в sandbox.filesystem. Правилото "sandbox": {"denyRead": [...]} няма да сработи.

Три неща си струва да се подчертаят.

allowUnsandboxedCommands е включено по подразбиране. Тоест команда, блокирана от пясъчника, агентът може да повтори отвън чрез специален параметър. Ако сте включили пясъчника заради изолацията, това най-вероятно не е това, което сте искали – изключва се с изрично false.

enabledPlatforms прави конфигурацията изцяло инертна. На система, която не е в списъка, няма да има нито пясъчник, нито автоматични разрешения, нито предупреждение при стартиране, нито спиране заради failIfUnavailable. Тихо, сякаш раздела го няма.

Маскирането на тайни не работи навсякъде. На macOS и Windows режимът mask се изражда в deny: няма с какво да се подмени стойността в движение. При записите за маскиране има още едно поле – onExtractNoMatch, което казва какво да се прави, ако регулярният израз не е намерил нищо: warn (по подразбиране) ще пропусне променливата немаскирана, deny ще я премахне вътре в пясъчника, error ще спре стартирането.

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["api.example.com", "*.githubusercontent.com"],
      "deniedDomains": ["telemetry.example.com"]
    },
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"],
      "denyWrite": ["~/.config"]
    }
  }
}

Обновления и всичко останало

Схемата приема още няколко служебни ключа: modelProposedGoals, totalTokensReminder с роднините му и disableDeepLinkRegistration. Те са вътрешни, в интерфейса не се появяват и никъде не са описани.

Променливи на средата

Блокът env в настройките е обект „име → стойност“. Всички стойности са низове: числата и флаговете се пишат в кавички, "PORT": "3000", флагът е "1".

Честна уговорка за пълнотата: официалната документация изброява поименно триста четиридесет и девет променливи, включително по региони за всеки модел при всеки доставчик и целия набор за телеметрия. Да ги преразказвам тук е безсмислено. По-долу са тези, които наистина се използват, плюс поведението на блока env, което никъде не е събрано на едно място.

{
  "env": {
    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "1",
    "ANTHROPIC_MODEL": "claude-opus-5",
    "BASH_DEFAULT_TIMEOUT_MS": "120000",
    "DISABLE_TELEMETRY": "1"
  }
}

Как се държи блокът env

Той има предимство пред експорта от шела. Стойността от файла с настройки се записва в средата на процеса върху наследената. Това е точно обратното на това, което обикновено се очаква.

Променлива не може да се изтрие – може да се зададе празен низ. При избора на доставчик празната стойност се счита за незададена, но дъщерните процеси ще получат именно празен низ.

Стойностите се прочитат наново в движение, когато файлът се промени – освен подсистемите, които се настройват само при стартиране, като телеметрията. А /cd от версия 2.1.246 налага env на новата папка върху този на старата.

На настройките на проекта и на локалните не е разрешено всичко. Отхвърлят се три групи: променливи, задаващи местоположението на файлове (CLAUDE_CONFIG_DIR, CLAUDE_CODE_TMPDIR, HOME, TMPDIR, TMP, TEMP, XDG_*); променливи, включващи изнасяне на съдържанието на сесията (OTEL_LOG_RAW_API_BODIES, ENABLE_BETA_TRACING_DETAILED, BETA_TRACING_ENDPOINT); и променливи, влияещи на стартирането и синхронизацията (CLAUDE_CODE_PROCESS_WRAPPER, CLAUDE_CODE_SYNC_SKILLS, CLAUDE_CODE_SYNC_PLUGINS, кешът и seed папката на плъгините). Списъкът се разшири именно в 2.1.251. Предупреждението за това се вижда само при дебъгване.

Още няколко променливи се игнорират във всеки файл и се четат само от средата при стартиране: CLAUDE_CODE_REMOTE, CLAUDE_CODE_ACCOUNT_UUID, сокетът и токенът за обмен между сесиите, CLAUDE_CODE_PROJECT_DIR_NAME и CLAUDE_CODE_RESTRICTED.

И обратната посока, за която почти не се пише: Claude Code сам задава променливи на дъщерните процеси. Виждат се от хуковете и от всеки стартиран скрипт: CLAUDECODE=1, CLAUDE_CODE_CHILD_SESSION=1, CLAUDE_CODE_SESSION_ID, CLAUDE_PID – собственият идентификатор на процеса, CLAUDE_EFFORT с текущото ниво на усилие (режимът ultracode се показва като xhigh), а в облачните сесии CLAUDE_CODE_REMOTE=true и идентификатор на отдалечената сесия. Хук, на който трябва да знае нивото на усилие или да различи дъщерна сесия от основната, го взема оттук, а не гадае.

Доставчици и автентикация

Доставчиците, между другото, не са два или три: освен Anthropic API, Amazon Bedrock и Google Cloud се поддържат Microsoft Foundry и Claude Platform на AWS, като всеки има собствен набор от променливи и собствено съответствие на алиасите на моделите.

Модели, контекст, лимити

Поведение и среда

Три капана в тази таблица заслужават да се изговорят.

Таймаутите на MCP се различават с повече от три порядъка. Стартирането на сървър е тридесет секунди. А извикването на инструмент по подразбиране е около двадесет и осем часа, тоест на практика без ограничение. Освен това при сървърите по HTTP и при облачните конектори всяка заявка е допълнително ограничена до една минута и това е отделен лимит.

CLAUDE_CODE_PROJECT_DIR_NAME сама не работи – само заедно с CLAUDE_CONFIG_DIR и само от средата, а не от файла с настройки.

Безопасният режим отнема повече, отколкото изглежда. CLAUDE_CODE_SAFE_MODE не е само инструкции и скилове: не се зареждат плъгини, хукове, MCP сървъри, собствени команди и агенти, стилове на изхода, работни процеси, теми, бързи клавиши, статус лентата, източникът на подсказки за файлове, езиковите сървъри и автопаметта. Остава само корпоративната политика, включително зададените от нея хукове и статус лента. Това е режим за дебъгване „изключи всичко, което съм настроил“ и за търсене на счупена конфигурация е идеален.

Рендериране и достъпност

С един ред, защото променливите са много, а са нужни рядко. Класическият рендерер се връща с CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN и той е по-силен и от CLAUDE_CODE_NO_FLICKER, и от настройката tui. Има отделни превключватели за мишката и кликовете, скоростта на превъртане, виртуалното превъртане, пълното пререндериране, родния курсор, оцветяването на синтаксиса, хипервръзките и truecolor в tmux. За достъпност – CLAUDE_AX_SCREEN_READER и сродните ѝ.

Поверителност, телеметрия, обновления