Подсказки за Claude Code: 25 готови за копиране подсказки и как да напишете свои собствени

Клиентите, които използват изтекъл купон, получават грешка 500 при плащане. Проверете @src/checkout/coupons.ts и тестовете към него. Очакваното поведение е съобщение за невалиден купон, без да се създава поръчка. Напишете тест, който да се провали и да възпроизведе грешката, след което я отстранете, без да променяте поведението при валиден купон. Изпълнете [команда за тестване на checkout] и покажете резултатите преди и след това. Ако не можете да възпроизведете грешката, докладвайте какво сте проверили, преди да промените реализацията.

Добавете избор на дата към [път към формуляра за резервация]. Спазвайте конвенциите за компоненти и валидиране в @src/components/TimeSelect.tsx. Потребителите трябва да могат да избират [допустими дати], докато [недостъпните дати] остават деактивирани. Не добавяйте библиотеки. Изпълнете [команда за тестване на компонента] и [команда за проверка на типовете] и докладвайте всички критерии, които тези проверки не обхващат.

Разделете @src/reports/export.py на по-малки функции, като запазите входните данни, формата на изхода и поведението при грешки. Изпълнете [командата за тестване на експорта] преди редактирането и докладвайте всички съществуващи грешки. След рефакторирането изпълнете тестовете отново и покажете и двата резултата. Не променяйте публичния интерфейс или файлове, които нямат връзка с задачата.

„Claude тества всяка промяна, която публикувам в claude.ai/code, чрез разширението Claude за Chrome. То отваря браузър, тества потребителския интерфейс и повтаря процеса, докато кодът не заработи и потребителското преживяване не стане добро. ”

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

Прегледайте историята в Git на [файл, функция или клас], като се съсредоточите върху [въпрос, свързан с поведението или дизайна]. Идентифицирайте комитовете, които са въвели или съществено променили това поведение. За всеки релевантен комит посочете неговия хеш, обобщете промяната и обяснете всяка обосновка, документирана в съобщението за комита или в свързаната дискусия, до която имате достъп. Обозначете изведените причини като „заключения“. Ако историята не обяснява дадено решение, посочете това. Не променяйте файловете или историята в Git.

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

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

Искам да създам [кратко описание] за [потребители и сценарий на употреба]. Прочетете първо [съответните файлове или изисквания], след което използвайте AskUserQuestion, за да изясните решенията, които биха оказали съществено влияние върху реализацията. Фокусирайте се върху крайните случаи, обработката на данни, разрешенията, очакваното поведение на потребителския интерфейс и компромисите. Не задавайте въпроси, на които предоставеният контекст вече дава отговор. След като ключовите решения бъдат взети, изгответе спецификация, обхващаща изискванията, критериите за приемане, ограниченията и това, което е извън обхвата. Отбележете всички останали предположения. Покажете ми спецификацията, преди да я запишете в [път към спецификацията], и не презаписвайте съществуващ файл без одобрение.

Оценете въздействието от промяната на [функция, компонент или интерфейс] от [текущо поведение] към [предложено поведение]. Претърсете [обхвата на репозиторията или директорията] за неговото определение, преки извикващи функции, импорти и свързани тестове. Избройте файловете, които вероятно ще се нуждаят от промени, и обяснете как всеки от тях би могъл да бъде засегнат, като посочите файлове и редове, където е възможно. Маркирайте динамично разрешените извиквания, външните потребители или други зависимости, които не можете да проверите. Идентифицирайте всички въпроси за съвместимост, които се нуждаят от отговор преди внедряването. Не променяйте файлове; изпратете оценката на въздействието и изчакайте моя преглед.

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

Имплементирайте [име на функцията] във [файл], за да отговорите на [изискванията]. Обхванете [нормален случай], [краен случай] и [поведение при невалиден вход]. Първо изпълнете [съответната тестова команда] и докладвайте всички съществуващи грешки. Напишете тестове за изискваното поведение, след което ги изпълнете преди имплементирането. Уверете се, че новите тестове се провалят по очакваната причина. Имплементирайте функцията и изпълнете тестовете отново. Не отслабвайте твърденията, не пропускайте тестове и не променяйте очакваното поведение, за да ги накарате да минат. Ако изискванията влизат в конфликт със съществуващите тестове, спрете и обяснете конфликта. Покажете резултатите „преди“ и „след“.

Реализирайте приложения дизайн в [компонент или страница], като използвате съществуващите компоненти и стилове на проекта. Запазете [изискваното поведение] и избягвайте промени извън [обхвата]. Използвайте [конфигуриран браузър или инструмент за екранни снимки], за да заснемете [локален маршрут] при [размери на прозореца] с [тестови данни и състояние на потребителския интерфейс]. Ако инструментът или приложението не са налични, докладвайте какво е необходимо, вместо да посочвате, че е извършена визуална проверка. Сравнете заснетия екран с референцията, като се съсредоточите върху [оформление, разстояние, типография или други критерии за приемане]. Направете до [брой] корекции, след което докладвайте оставащите разлики. Не променяйте референтното изображение. Изпълнете [съответните тестове на компонентите] и [команда за проверка на типа или за компилиране]. Включете заснетия екранен снимка и действителните резултати от проверката в обобщението си.

Потребителите срещат [симптом], когато [тригер или вход]. Очакваното поведение е [очакван резултат]. Започнете с проверка на [папка, функция или поток] и свързаните с тях тестове. Създайте тест, който да се провали и да възпроизвежда докладваното поведение. Ако не можете да го възпроизведете, обяснете какво сте проверили и каква информация липсва, преди да промените реализацията. След като го възпроизведете, отстранете причината, без да променяте [поведението, което трябва да остане непроменено]. Изпълнете новия тест и [свързаната тестова команда]. Покажете грешката преди поправката, резултатите след нея и всички останали грешки.

[Команда за компилиране] се проваля в [локална или CI среда] с този изход: [очистен лог с грешки]. Проверете съответния код и конфигурацията, за да идентифицирате причината. Проверете за разлики в средата или зависимостите, ако грешката не се възпроизвежда локално. Направете най-малката промяна, която отстранява причината. Не деактивирайте проверки, не потискайте грешки, не пропускайте тестове и не отпускайте настройките на компилатора само за да получите успешна компилация. Изпълнете компилацията отново след промяната. Ако тя все още се проваля след [брой] опита за поправка, спрете и докладвайте какво сте опитали, текущата грешка и следващата диагностична стъпка. Обобщете причината и включете действителния резултат от компилацията.

Помогнете ми да стесня обхвата на грешката, преди да предложите решение. Наблюдавано поведение: [какво се случва]Очаквано поведение: [какво трябва да се случи]Кога се случва: [условия или честота]Какво съм опитал: [стъпки и резултати]Задавайте по един въпрос наведнъж, като избирате този, който най-добре би разграничил вероятните причини. Не повтаряйте въпроси, на които предоставената информация вече дава отговор. Щом има достатъчно доказателства, обобщете най-вероятното обяснение, какво остава неясно и най-малкия тест, който би могъл да го потвърди или отхвърли. Все още не редактирайте файлове.

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

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

Обобщете как сте проверили завършената промяна спрямо [критериите за приемане]. За всеки критерий избройте извършената проверка, точната команда, където е приложимо, и наблюдавания резултат. Включете съответния изход, като скриете тайните и чувствителните данни. Идентифицирайте отделно всички вече съществуващи грешки. Ясно разграничавайте проверките, които са преминали успешно, тези, които са се провалили, и тези, които не са били изпълнени. Обяснете всички пропуснати проверки или ограничения в обхвата. Не описвайте цялата промяна като проверена, ако някои критерии остават непроверени.

Рефакторирайте [файл или модул] с цел [конкретна цел, като например разделяне на голяма функция или премахване на вложени callback-и]. Запазете публичния му интерфейс, стойностите на връщане, поведението при грешки и страничните ефекти. Изпълнете [съответната тестова команда] преди редактирането, за да установите базова линия. Ако тя се провали, докладвайте грешките, преди да продължите. Идентифицирайте всяко поведение, което съществуващите тестове не покриват, и добавете целенасочени тестове, където е необходимо. Извършете рефакторирането без несвързани промени или нови зависимости. Не отслабвайте съществуващите твърдения, за да се приспособите към имплементацията. Изпълнете отново тестовете и [команда за проверка на типовете или lint]. Покажете резултатите „преди“ и „след“, обобщете структурните промени и отбележете всяко поведение, което не сте могли да проверите.

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

Проверете текущия клон, състоянието на Git и разликите за [функция или поправка]. Идентифицирайте файловете, принадлежащи към тази промяна, и избройте отделно несвързаните или непроследяваните файлове. Напишете чернова на съобщение за комит, следвайки формата на последните 10 комита. Подгответе описание на pull request, което обхваща какво се е променило, защо, тестовете, които действително са изпълнени, и всички останали ограничения. Покажете предложения списък с файлове, съобщението за комит и описанието на pull request-а, преди да поставите нещо в staging или да публикувате нещо. Изчакайте моето одобрение. След одобрение поставете в staging само одобрените файлове, направете комит в [feature branch], изпратете към [remote] и отворете pull request към [base branch]. Не променяйте съществуващи комитове, не правете force-push и не извършвайте сливане. Върнете хеш-кода на комита и линка към pull request-а.

Напишете раздел „README“ за [модул], насочен към [читател, например инженер по бекенд, който се присъединява към проекта]. Обхванете предварителните изисквания, настройката, трите команди, които ще използват най-често, и често срещаните грешки, описани в кода или съществуващата документация. Проверете имената на командите и опциите спрямо [скриптовете на пакета, Makefile, помощната информация за CLI или конфигурацията на CI]. Отбележете всичко, което не можете да потвърдите. Тествайте безопасни локални команди в [тестова среда], ако има такава. Преди да изпълните команди, които инсталират зависимости, изтриват файлове, мигрират данни, извършват разгръщане или осъществяват достъп до външни услуги, обяснете техните ефекти и поискайте одобрение. Ясно разграничавайте команди, които сте изпълнили успешно, от команди, проверени само спрямо конфигурацията или документацията. Покажете предложената секция в README, преди да редактирате [път към документацията], и запазете несвързаното съдържание.

Прегледайте [път към CLAUDE.md] в сравнение с текущата структура, скриптовете и конвенциите на репозиторията. Все още не редактирайте файла. Идентифицирайте остарели инструкции, дубликати, противоречия и правила, които могат да бъдат надеждно изведени от кода. Обяснете всяко предложено премахване, вместо просто да изтривате инструкции с цел съкращаване на файла. Предлагайте липсващи команди за компилиране или тестване само когато можете да ги проверите в скриптовете на проекта, Makefile, CI конфигурацията или съществуващата документация. Посочете източника за всяко добавяне. Върнете предложен diff, който запазва важните ограничения на проекта. Маркирайте инструкциите, специфични за дадена задача, които биха се вписали по-добре в правило с обхват на умение или път, и изчакайте одобрение, преди да приложите промените.

Предложете хук за команда в Claude Code, който изпълнява [съществуваща команда на форматиращия инструмент] след промени при „Редактиране“ или „Записване“ на [шаблони на файлове]. Първо проверете съществуващата конфигурация в claude/settings.json и конфигурацията на форматиращия инструмент. Използвайте подходящата конфигурация PostToolUse за инсталираната версия на Claude Code. Форматирайте само засегнатия файл, обработвайте пътеките безопасно и изключете [генерирани файлове или други изключени пътеки]. Не инсталирайте зависимости и не замествайте съществуващи хукове. Покажете разликите в предложените настройки и обяснете как ще се докладват грешките на форматиращия инструмент. Изчакайте одобрение, преди да го приложите. След одобрение го тествайте с временен файл в проекта и докладвайте резултата. Посочете кои пътища за редактиране обхваща и кои не, включително промените, направени чрез команди в терминала.

Проверете [инструмент] –help и помощната информация за подкомандите, свързани с [задача]. Не инсталирайте инструмента, ако липсва; вместо това докладвайте за тази предварителна необходимост. Предложете точните команди, необходими за изпълнението на задачата. Обяснете входните и изходните данни, както и дали те записват файлове, променят отдалечени ресурси или използват удостоверения за достъп. Включете опция за тестово изпълнение, ако инструментът я поддържа. Посочете липсваща конфигурация или разрешения и потърсете разяснения, вместо да гадаете имена на ресурси или дестинации. Изчакайте одобрение, преди да изпълните командите за задачата. След одобрение изпълнете само договорените команди и докладвайте действителните им резултати, включително евентуални грешки или незавършени стъпки.

Сравнете [invoices.csv] и [payments.csv], като използвате [идентификационен номер на фактура или ключ за съвпадение]. Не променяйте изходните файлове. Прилагайте следните правила: [валута и толеранс за закръгляване], [разпределение на частични плащания] и [обработка на възстановявания, кредити и надплащания]. Ако липсва правило или съвпадението е неясно, маркирайте го, вместо да присвоявате плащането автоматично. Запазете идентификаторите на редовете от изходните файлове. За всяка фактура покажете фактурираната сума, приложените плащания и остатъка. Докладвайте дублиращи се идентификатори, несъвпадащи фактури, несъвпадащи плащания и салда извън допустимото отклонение. Сравнявайте сумите по фактурите и плащанията поотделно. Отчитайте всеки изходен ред, без да го броите два пъти; ако дадено плащане е разпределено между няколко фактури, покажете всяко разпределение и потвърдете, че разпределенията не надвишават сумата на плащането. Запишете резултатите в [нови пътища за изход] и обобщете изключенията, изискващи преглед.

Напишете скрипт, който обобщава [export.csv] за периода от [начална дата и час, включително] до [крайна дата и час, изключително], като използвате [часова зона] и [колона с дата]. Групирайте записите според [правила за категоризация] и изчислете [необходимите показатели]. Обработете дублиращите се идентификатори и липсващите стойности съгласно [правилата]. Не променяйте входния файл. Изпълнете скрипта върху [точния входен файл]. Отчетете броя на включените и изключените редове, сумите по категории и записите, които не са могли да бъдат класифицирани. Сравнете резултатите за [три категории] с независимо проверените бройки в [референтен файл]. Ако тези бройки не са налични, посочете, че независимата валидация все още не е извършена. Покажете несъответствията и запазете отчета в [нова изходна папка].

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

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

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

Натиснете Shift+Tab, докато се появи режим „Plan“, или стартирайте Claude Code с командата claude --permission-mode plan. В този режим Claude може да проверява файлове и да изпълнява команди само за четене, без да редактира изходния ви код. Прегледайте предложените файлове, зависимости и тестове, преди да одобрите реализацията. Натиснете Ctrl+G, за да отворите предложения план във вашия редактор.

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

Изберете най-малкия полезен набор от източници. Включването на цял лог или цяла директория може да добави нерелевантна информация и да отнеме контекст. Премахнете идентификационните данни и чувствителната информация, преди да споделите логовете, и проверете дали Claude разполага с необходимите инструменти за извличане на предоставените от вас URL адреси на документация.

Например, командата cat error.log | claude -p "Explain this error" изпраща лог с неинтерактивно запитване. Използвайте я само след като проверите съдържанието на файла. Това е практическата полза от контекстуалния ИИ: предоставянето на модела на релевантна информация за задачата.

Когато добавяте нова функционалност, намерете подобен компонент или функция в репозиторията. Укажете на Claude кои конвенции да следва, като например API клиент, логика за валидиране, обработка на грешки или структура на тестовете.

„Проследете как @src/widgets/Weather.tsx извлича и кешира данни“ дава на Claude конкретна отправна точка. Посочете също така всички разлики, които изисква новата функция, за да не се копира поведение, което вече не е подходящо. Тези конвенции трябва да отразяват работния процес на вашия екип при разработката на софтуер.

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

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

За по-дълги задачи Claude Code предлага също условие /goal и „Stop hooks“. Оценителят на целта анализира доказателствата, изведени в разговора, вместо да проверява самостоятелно файловете или да изпълнява тестове. Конфигуриран „Stop hook“ може да блокира завършването, но има ограничения за повтарящо се блокиране. Нито едното, нито другото замества подходящите тестове и човешката проверка.

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

Ръководството за най-добри практики на Anthropic препоръчва да започнете отначало след две неуспешни корекции по един и същ проблем. Използвайте /clear, след което въведете преработена подсказка, която включва наученото от вас. Изчистването на разговора не отменя промените във файловете.

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

Запазете указанията за целия проект в CLAUDE.md, повтаряемите процедури в уменията и инструкциите за конкретни файлове в правила с обхват по пътека. Използвайте хукове за действия, свързани с конкретни събития, като например стартиране на форматиращ инструмент след редактиране.

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

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

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

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

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

Персонализираните подагенти са още един начин за организиране на повтаряща се работа. Дефинирайте специалист в claude/agents/, когато е необходима отделна роля за преглед или обхват на инструмента, вместо да добавяте всяка инструкция за специалиста към основната сесия. Тези ръководства за най-добрия модел на Claude за работа и видовете AI агенти предоставят допълнителен контекст.

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

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

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

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

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

Използвайте отделни сесии за несвързана работа. Ако няколко сесии ще редактират репозиторията, използвайте отделни Git работни дървета, за да не променят една и съща работна директория. Като кратък страничен въпрос, командата /btw на Claude Code запазва разговора извън основната история на разговорите.

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

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

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

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

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

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

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

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

Натиснете Shift+Tab, докато се появи режим „Plan“, или стартирайте Claude Code с командата claude --permission-mode plan. В този режим Claude може да проверява файлове и да изпълнява команди само за четене, без да редактира изходния ви код. Прегледайте предложените файлове, зависимости и тестове, преди да одобрите реализацията. Натиснете Ctrl+G, за да отворите предложения план във вашия редактор.

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

Изберете най-малкия полезен набор от източници. Включването на цял лог или цяла директория може да добави нерелевантна информация и да отнеме контекст. Премахнете идентификационните данни и чувствителната информация, преди да споделите логовете, и проверете дали Claude разполага с необходимите инструменти за извличане на предоставените от вас URL адреси на документация.

Например, командата cat error.log | claude -p "Explain this error" изпраща лог с неинтерактивно запитване. Използвайте я само след като проверите съдържанието на файла. Това е практическата полза от контекстуалния ИИ: предоставянето на модела на релевантна информация за задачата.

Когато добавяте нова функционалност, намерете подобен компонент или функция в репозиторията. Укажете на Claude кои конвенции да следва, като например API клиент, логика за валидиране, обработка на грешки или структура на тестовете.

„Проследете как @src/widgets/Weather.tsx извлича и кешира данни“ дава на Claude конкретна отправна точка. Посочете също така всички разлики, които изисква новата функция, за да не се копира поведение, което вече не е подходящо. Тези конвенции трябва да отразяват работния процес на вашия екип при разработката на софтуер.

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

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

За по-дълги задачи Claude Code предлага също условие /goal и „Stop hooks“. Оценителят на целта анализира доказателствата, изведени в разговора, вместо да проверява самостоятелно файловете или да изпълнява тестове. Конфигуриран „Stop hook“ може да блокира завършването, но има ограничения за многократно блокиране. Нито едното, нито другото замества подходящите тестове и човешката проверка.

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

Ръководството за най-добри практики на Anthropic препоръчва да започнете отначало след две неуспешни корекции по един и същ проблем. Използвайте /clear, след което въведете преработена подсказка, която включва наученото от вас. Изчистването на разговора не отменя промените във файловете.

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

Запазете указанията за целия проект в CLAUDE.md, повтаряемите процедури в уменията и инструкциите за конкретни файлове в правила с обхват по пътека. Използвайте хукове за действия, свързани с конкретни събития, като например стартиране на форматиращ инструмент след редактиране.

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

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

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

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

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

Персонализираните подагенти са още един начин за организиране на повтаряща се работа. Дефинирайте специалист в claude/agents/, когато е необходима отделна роля за преглед или обхват на инструмента, вместо да добавяте всяка инструкция за специалиста към основната сесия. Тези ръководства за най-добрия модел на Claude за работа и видовете AI агенти предоставят допълнителен контекст.

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

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

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

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

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

Използвайте отделни сесии за несвързана работа. Ако няколко сесии ще редактират репозиторията, използвайте отделни Git работни дървета, за да не променят една и съща работна директория. Като кратък страничен въпрос, командата /btw на Claude Code запазва разговора извън основната история на разговорите.

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

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

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

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

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

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

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

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

Натиснете Shift+Tab, докато се появи режим „Plan“, или стартирайте Claude Code с командата claude --permission-mode plan. В този режим Claude може да проверява файлове и да изпълнява команди само за четене, без да редактира изходния ви код. Прегледайте предложените файлове, зависимости и тестове, преди да одобрите реализацията. Натиснете Ctrl+G, за да отворите предложения план във вашия редактор.

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

Изберете най-малкия полезен набор от източници. Включването на цял лог или цяла директория може да добави нерелевантна информация и да отнеме контекст. Премахнете идентификационните данни и чувствителната информация, преди да споделите логовете, и проверете дали Claude разполага с необходимите инструменти за извличане на предоставените от вас URL адреси на документация.

Например, командата cat error.log | claude -p "Explain this error" изпраща лог с неинтерактивно запитване. Използвайте я само след като проверите съдържанието на файла. Това е практическата полза от контекстуалния ИИ: предоставянето на модела на релевантна информация за задачата.

Когато добавяте нова функционалност, намерете подобен компонент или функция в репозиторията. Укажете на Claude кои конвенции да следва, като например API клиент, логика за валидиране, обработка на грешки или структура на тестовете.

„Проследете как @src/widgets/Weather.tsx извлича и кешира данни“ дава на Claude конкретна отправна точка. Посочете също така всички разлики, които изисква новата функция, за да не се копира поведение, което вече не е подходящо. Тези конвенции трябва да отразяват работния процес на вашия екип при разработката на софтуер.

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

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

За по-дълги задачи Claude Code предлага също условие /goal и „Stop hooks“. Оценителят на целта анализира доказателствата, които се появяват в разговора, вместо да проверява самостоятелно файловете или да изпълнява тестове. Настроен „Stop hook“ може да блокира завършването, но има ограничения за многократно блокиране. Нито едното, нито другото замества подходящите тестове и човешката проверка.

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

Ръководството за най-добри практики на Anthropic препоръчва да започнете отначало след две неуспешни корекции по един и същ проблем. Използвайте /clear, след което въведете преработена подсказка, която включва наученото от вас. Изчистването на разговора не отменя промените във файловете.

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

Запазете указанията за целия проект в CLAUDE.md, повтаряемите процедури в уменията и инструкциите за конкретни файлове в правила с обхват по пътека. Използвайте хукове за действия, свързани с конкретни събития, като например стартиране на форматиращ инструмент след редактиране.

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

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

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

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

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

Персонализираните подагенти са още един начин за организиране на повтаряща се работа. Дефинирайте специалист в claude/agents/, когато е необходима отделна роля за преглед или обхват на инструмента, вместо да добавяте всяка инструкция за специалиста към основната сесия. Тези ръководства за най-добрия модел на Claude за работа и видовете AI агенти предоставят допълнителен контекст.

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

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

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

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

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

Използвайте отделни сесии за несвързана работа. Ако няколко сесии ще редактират репозиторията, използвайте отделни Git работни дървета, за да не променят една и съща работна директория. Като кратък страничен въпрос, командата /btw на Claude Code запазва разговора извън основната история на разговорите.

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

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

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

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

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

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

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

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

Натиснете Shift+Tab, докато се появи режим „Plan“, или стартирайте Claude Code с командата claude --permission-mode plan. В този режим Claude може да проверява файлове и да изпълнява команди само за четене, без да редактира изходния ви код. Прегледайте предложените файлове, зависимости и тестове, преди да одобрите реализацията. Натиснете Ctrl+G, за да отворите предложения план във вашия редактор.

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

Изберете най-малкия полезен набор от източници. Включването на цял лог или цяла директория може да добави нерелевантна информация и да отнеме контекст. Премахнете идентификационните данни и чувствителната информация, преди да споделите логовете, и проверете дали Claude разполага с необходимите инструменти за извличане на предоставените от вас URL адреси на документация.

Например, командата cat error.log | claude -p "Explain this error" изпраща лог с неинтерактивно запитване. Използвайте я само след като проверите съдържанието на файла. Това е практическата полза от контекстуалния ИИ: предоставянето на модела на релевантна информация за задачата.

Когато добавяте нова функционалност, намерете подобен компонент или функция в репозиторията. Укажете на Claude кои конвенции да следва, като например API клиент, логика за валидиране, обработка на грешки или структура на тестовете.

„Проследете как @src/widgets/Weather.tsx извлича и кешира данни“ дава на Claude конкретна отправна точка. Посочете също така всички разлики, които изисква новата функция, за да не се копира поведение, което вече не е подходящо. Тези конвенции трябва да отразяват работния процес на вашия екип при разработката на софтуер.

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

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

За по-дълги задачи Claude Code предлага също условие /goal и „Stop hooks“. Оценителят на целта анализира доказателствата, изведени в разговора, вместо да проверява самостоятелно файловете или да изпълнява тестове. Конфигуриран „Stop hook“ може да блокира завършването, но има ограничения за многократно блокиране. Нито едното, нито другото замества подходящите тестове и човешката проверка.

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

Ръководството за най-добри практики на Anthropic препоръчва да започнете отначало след две неуспешни корекции по един и същ проблем. Използвайте /clear, след което въведете преработена подсказка, която включва наученото от вас. Изчистването на разговора не отменя промените във файловете.

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

Запазете указанията за целия проект в CLAUDE.md, повтаряемите процедури в уменията и инструкциите за конкретни файлове в правила с обхват по пътека. Използвайте хукове за действия, свързани с конкретни събития, като например стартиране на форматиращ инструмент след редактиране.

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

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

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

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

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

Персонализираните подагенти са още един начин за организиране на повтаряща се работа. Дефинирайте специалист в claude/agents/, когато е необходима отделна роля за преглед или обхват на инструмента, вместо да добавяте всяка инструкция за специалиста към основната сесия. Тези ръководства за най-добрия модел на Claude за работа и видовете AI агенти предоставят допълнителен контекст.

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

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

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

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

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

Използвайте отделни сесии за несвързана работа. Ако няколко сесии ще редактират репозиторията, използвайте отделни Git работни дървета, за да не променят една и съща работна директория. Като кратък страничен въпрос, командата /btw на Claude Code запазва разговора извън основната история на разговорите.

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

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

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

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

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

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

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

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

Натиснете Shift+Tab, докато се появи режим „Plan“, или стартирайте Claude Code с командата claude --permission-mode plan. В този режим Claude може да проверява файлове и да изпълнява команди само за четене, без да редактира изходния ви код. Прегледайте предложените файлове, зависимости и тестове, преди да одобрите реализацията. Натиснете Ctrl+G, за да отворите предложения план във вашия редактор.

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

Изберете най-малкия полезен набор от източници. Включването на цял лог или цяла директория може да добави нерелевантна информация и да отнеме контекст. Премахнете идентификационните данни и чувствителната информация, преди да споделите логовете, и проверете дали Claude разполага с необходимите инструменти за извличане на предоставените от вас URL адреси на документация.

Например, командата cat error.log | claude -p "Explain this error" изпраща лог с неинтерактивно запитване. Използвайте я само след като проверите съдържанието на файла. Това е практическата полза от контекстуалния ИИ: предоставянето на модела на релевантна информация за задачата.

Когато добавяте нова функционалност, намерете подобен компонент или функция в репозиторията. Укажете на Claude кои конвенции да следва, като например API клиент, логика за валидиране, обработка на грешки или структура на тестовете.

„Проследете как @src/widgets/Weather.tsx извлича и кешира данни“ дава на Claude конкретна отправна точка. Посочете също така всички разлики, които изисква новата функция, за да не се копира поведение, което вече не е подходящо. Тези конвенции трябва да отразяват работния процес на вашия екип при разработката на софтуер.

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

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

За по-дълги задачи Claude Code предлага също условие /goal и „Stop hooks“. Оценителят на целта анализира доказателствата, които се появяват в разговора, вместо да проверява самостоятелно файловете или да изпълнява тестове. Настроен „Stop hook“ може да блокира завършването, но има ограничения за многократно блокиране. Нито едното, нито другото замества подходящите тестове и човешката проверка.

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

Ръководството за най-добри практики на Anthropic препоръчва да започнете отначало след две неуспешни корекции по един и същ проблем. Използвайте /clear, след което въведете преработена подсказка, която включва наученото от вас. Изчистването на разговора не отменя промените във файловете.

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

Запазете указанията за целия проект в CLAUDE.md, повтаряемите процедури в уменията и инструкциите за конкретни файлове в правила с обхват по пътека. Използвайте хукове за действия, свързани с конкретни събития, като например стартиране на форматиращ инструмент след редактиране.

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

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

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

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

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

Персонализираните подагенти са още един начин за организиране на повтаряща се работа. Дефинирайте специалист в claude/agents/, когато е необходима отделна роля за преглед или обхват на инструмента, вместо да добавяте всяка инструкция за специалиста към основната сесия. Тези ръководства за най-добрия модел на Claude за работа и видовете AI агенти предоставят допълнителен контекст.

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

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

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

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

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

Използвайте отделни сесии за несвързана работа. Ако няколко сесии ще редактират репозиторията, използвайте отделни Git работни дървета, за да не променят една и съща работна директория. Като кратък страничен въпрос, командата /btw на Claude Code запазва разговора извън основната история на разговорите.

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

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

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

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

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

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

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

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

Натиснете Shift+Tab, докато се появи режим „Plan“, или стартирайте Claude Code с командата claude --permission-mode plan. В този режим Claude може да проверява файлове и да изпълнява команди само за четене, без да редактира изходния ви код. Прегледайте предложените файлове, зависимости и тестове, преди да одобрите реализацията. Натиснете Ctrl+G, за да отворите предложения план във вашия редактор.

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

Изберете най-малкия полезен набор от източници. Включването на цял лог или цяла директория може да добави нерелевантна информация и да отнеме контекст. Премахнете идентификационните данни и чувствителната информация, преди да споделите логовете, и проверете дали Claude разполага с необходимите инструменти за извличане на предоставените от вас URL адреси на документация.

Например, командата cat error.log | claude -p "Explain this error" изпраща лог с неинтерактивно запитване. Използвайте я само след като проверите съдържанието на файла. Това е практическата полза от контекстуалния ИИ: предоставянето на модела на релевантна информация за задачата.

Когато добавяте нова функционалност, намерете подобен компонент или функция в репозиторията. Укажете на Claude кои конвенции да следва, като например API клиент, логика за валидиране, обработка на грешки или структура на тестовете.

„Проследете как @src/widgets/Weather.tsx извлича и кешира данни“ дава на Claude конкретна отправна точка. Посочете също така всички разлики, които изисква новата функция, за да не се копира поведение, което вече не е подходящо. Тези конвенции трябва да отразяват работния процес на вашия екип при разработката на софтуер.

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

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

За по-дълги задачи Claude Code предлага също условие /goal и „Stop hooks“. Оценителят на целта анализира доказателствата, които се появяват в разговора, вместо да проверява самостоятелно файловете или да изпълнява тестове. Конфигуриран „Stop hook“ може да блокира завършването, но има ограничения за многократно блокиране. Нито едното, нито другото замества подходящите тестове и човешката проверка.

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

Ръководството за най-добри практики на Anthropic препоръчва да започнете отначало след две неуспешни корекции по един и същ проблем. Използвайте /clear, след което въведете преработена подсказка, която включва наученото от вас. Изчистването на разговора не отменя промените във файловете.

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

Запазете указанията за целия проект в CLAUDE.md, повтаряемите процедури в уменията и инструкциите за конкретни файлове в правила с обхват по пътека. Използвайте хукове за действия, свързани с конкретни събития, като например стартиране на форматиращ инструмент след редактиране.

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

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

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

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

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

Персонализираните подагенти са още един начин за организиране на повтаряща се работа. Дефинирайте специалист в claude/agents/, когато е необходима отделна роля за преглед или обхват на инструмента, вместо да добавяте всяка инструкция за специалиста към основната сесия. Тези ръководства за най-добрия модел на Claude за работа и видовете AI агенти предоставят допълнителен контекст.

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

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

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

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

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

Използвайте отделни сесии за несвързана работа. Ако няколко сесии ще редактират репозиторията, използвайте отделни Git работни дървета, за да не променят една и съща работна директория. Като кратък страничен въпрос, командата /btw на Claude Code запазва разговора извън основната история на разговорите.

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

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

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

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

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

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