Podněty pro Claude Code: 25 podnětů připravených k zkopírování a návod, jak napsat vlastní

Zákazníci, kteří při placení použijí kupón s prošlou platností, obdrží při dokončení objednávky chybu 500. Prohlédněte si soubor @src/checkout/coupons.ts a jeho testy. Očekávaným chováním je zobrazení zprávy o neplatném kupónu bez vytvoření objednávky. Napište test, který selže a reprodukuje tuto chybu, a poté ji opravte, aniž byste změnili chování platného kupónu. Spusťte [příkaz pro testování pokladny] a ukažte výsledky před a po opravě. Pokud se vám nepodaří chybu reprodukovat, uveďte, co jste zkontrolovali, než jste provedli změnu v implementaci.

Přidejte výběr data do [cesta k rezervačnímu formuláři]. Dodržujte konvence pro komponenty a validaci uvedené v souboru @src/components/TimeSelect.tsx. Uživatelé musí mít možnost vybrat [povolená data], zatímco [nedostupná data] zůstanou deaktivována. Nepřidávejte knihovny. Spusťte [příkaz pro testování komponenty] a [příkaz pro kontrolu typů] a nahlaste všechna kritéria, která tyto kontroly nezahrnují.

Rozdělte soubor @src/reports/export.py na menší funkce, přičemž zachovejte jeho vstupy, formát výstupu a chování při chybách. Před úpravami spusťte [příkaz export test] a nahlaste všechny existující chyby. Po refaktoringu znovu spusťte testy a ukažte oba výsledky. Neměňte veřejné rozhraní ani nesouvisející soubory.

„Claude testuje každou jednotlivou změnu, kterou nasadím na claude.ai/code pomocí rozšíření Claude pro Chrome. Otevře prohlížeč, otestuje uživatelské rozhraní a opakuje tento proces, dokud kód nefunguje a uživatelský zážitek není uspokojivý. ”

Prostudujte si soubor README, konfiguraci projektu a strukturu adresářů nejvyšší úrovně tohoto repozitáře. Používejte odkazy pouze v případě, že je to nezbytné k vysvětlení: Co aplikace dělá, jaké jsou její hlavní vstupní body a klíčové komponenty, kde se nacházejí testy a jaké příkazy repozitář definuje pro jejich spuštění. Uveďte cesty k souborům, které vaše vysvětlení podpoří. Rozlišujte mezi zdokumentovaným chováním a vašimi vlastními závěry a označte vše, co nedokážete určit. Nečtěte soubory s tajnými údaji ani soubory prostředí, neprohlížejte nainstalované závislosti a neměňte žádné soubory. Na závěr uveďte tři soubory, které bych si měl přečíst jako první, a zdůvodněte proč.

Projděte si historii Git [souboru, funkce nebo třídy] se zaměřením na [chování nebo otázku týkající se návrhu]. Identifikujte revize, které toto chování zavedly nebo podstatně změnily. U každé relevantní revize uveďte její hash, shrňte změnu a vysvětlete případné odůvodnění zdokumentované ve zprávě revize nebo v související diskusi, ke které máte přístup. Odvozené důvody označte jako „dedukce“. Pokud historie rozhodnutí nevysvětluje, uveďte to. Neupravujte soubory ani historii Git.

Sledujte, co se stane při [akci uživatele nebo systémové události], počínaje [známou trasou, handlerem nebo složkou]. Sledujte příslušná volání přes validaci, obchodní logiku a veškeré zápisy do databáze či externí požadavky. Uveďte soubory a funkce v pořadí provádění, pokud možno s odkazy na řádky. Vysvětlete hlavní cesty selhání a identifikujte stávající testy pokrývající daný tok. Označte jakékoli připojení, které nelze z kódu potvrdit. Neprovádějte tento tok, nevolávejte externí služby ani neupravujte soubory.

Naplánujte, jak implementovat [funkci] v [oblasti repozitáře]. Očekávané chování je [požadavky] a tyto oblasti musí zůstat beze změny: [omezení]. Projděte příslušný kód a stávající testy. Určete soubory, které je třeba změnit, pořadí implementace a případná rizika týkající se kompatibility nebo migrace dat. Každý požadavek přiřaďte k navrhovanému testu nebo jinému ověřovacímu kroku. Nevyřešené otázky a předpoklady uveďte samostatně. Funkci zatím neimplementujte. Předložte mi plán ke kontrole.

Chci vytvořit [krátký popis] pro [uživatele a případ použití]. Nejprve si přečtěte [relevantní soubory nebo požadavky], poté použijte AskUserQuestion k vyjasnění rozhodnutí, která by měla podstatný vliv na implementaci. Zaměřte se na okrajové případy, práci s daty, oprávnění, očekávané chování uživatelského rozhraní a kompromisy. Nepokládejte otázky, na které již poskytnutý kontext odpovídá. Jakmile budou vyřešena klíčová rozhodnutí, vypracujte návrh specifikace zahrnující požadavky, kritéria přijatelnosti, omezení a to, co je mimo rozsah. Označte všechny zbývající předpoklady. Ukažte mi specifikaci před jejím uložením do [cesta ke specifikaci] a nepřepisujte existující soubor bez schválení.

Posuďte dopad změny [funkce, komponenty nebo rozhraní] z [současného chování] na [navrhované chování]. Prohledejte [rozsah repozitáře nebo adresáře] a najděte její definici, přímé volající, importy a související testy. Uveďte seznam souborů, u nichž bude pravděpodobně nutné provést změny, a vysvětlete, jak by mohla být každý z nich ovlivněn, včetně odkazů na soubory a řádky, jsou-li k dispozici. Označte dynamicky vyřešená volání, externí spotřebitele nebo jiné závislosti, které nemůžete ověřit. Identifikujte všechny otázky týkající se kompatibility, které vyžadují odpověď před implementací. Neupravujte soubory; předložte posouzení dopadu a vyčkejte na mou kontrolu.

Přidejte [funkci] do [souboru nebo stránky] s tímto chováním: [akceptační kritéria]. Prohlédněte si [stávající implementaci] a dodržujte její konvence pro načítání dat, zpracování chyb a organizaci komponent. Používejte pouze knihovny, které jsou již v projektu nainstalovány. Udržujte změny v rámci [rozsahu] a zachovejte [stávající chování nebo veřejné rozhraní]. Přidejte nebo aktualizujte testy pro akceptační kritéria. Spusťte [testovací příkaz] a [příkaz pro kontrolu typů nebo lint], poté nahlaste změněné soubory, výsledky a všechny kontroly, které se vám nepodařilo dokončit. Pokud stávající vzor koliduje s požadavkem, vysvětlete tento konflikt předtím, než budete pokračovat.

Implementujte [název funkce] v [souboru], aby splňovala [požadavky]. Zahrňte [normální případ], [hraniční případ] a [chování při neplatném vstupu]. Nejprve spusťte [příslušný testovací příkaz] a nahlaste všechny existující chyby. Napište testy pro požadované chování a poté je spusťte před implementací. Ověřte, zda nové testy selhávají z očekávaného důvodu. Implementujte funkci a znovu spusťte testy. Neoslabujte tvrzení, nevynechávejte testy ani neměňte očekávané chování, aby testy prošly. Pokud jsou požadavky v rozporu se stávajícími testy, zastavte se a vysvětlete tento rozpor. Ukažte výsledky před a po.

Implementujte přiložený návrh do [komponenty nebo stránky] s využitím stávajících komponent a stylů projektu. Zachovejte [požadované chování] a vyhněte se změnám mimo [rozsah]. Použijte [nakonfigurovaný prohlížeč nebo nástroj pro pořizování snímků obrazovky] k zachycení [lokální trasy] při [rozměrech zobrazení] s [testovacími daty a stavem uživatelského rozhraní]. Pokud není nástroj nebo aplikace k dispozici, uveďte, co je potřeba, místo toho, abyste uváděli vizuální kontrolu. Porovnejte snímek s referenčním obrázkem a zaměřte se na [rozvržení, mezery, typografii nebo jiná kritéria přijatelnosti]. Proveďte až [počet] korekčních cyklů a poté nahláste zbývající rozdíly. Referenční obrázek neupravujte. Spusťte [příslušné testy komponent] a [příkaz pro kontrolu typů nebo sestavení]. Do svého shrnutí zahrňte pořízený snímek obrazovky a skutečné výsledky kontroly.

Uživatelé se setkávají s [příznakem], když dojde k [spouštěči nebo vstupu]. Očekávané chování je [očekávaný výsledek]. Začněte kontrolou [složky, funkce nebo toku] a souvisejících testů. Vytvořte test, který selže a reprodukuje nahlášené chování. Pokud jej nemůžete reprodukovat, vysvětlete, co jste zkontrolovali a jaké informace chybí, než provedete změnu v implementaci. Jakmile se vám podaří chování reprodukovat, odstraňte příčinu bez změny [chování, které musí zůstat beze změny]. Spusťte nový test a [související testovací příkaz]. Ukažte selhání před opravou, výsledky po opravě a případná zbývající selhání.

[Příkaz sestavení] selže v [lokálním nebo CI prostředí] s tímto výstupem: [upravený protokol chyb]. Projděte příslušný kód a konfiguraci, abyste zjistili příčinu. Pokud se selhání nedá lokálně reprodukovat, zkontrolujte rozdíly v prostředí nebo závislostech. Proveďte nejmenší možnou změnu, která příčinu odstraní. Nevypínejte kontroly, nepotlačujte chyby, nepřeskakujte testy ani neuvolňujte nastavení kompilátoru pouze proto, abyste dosáhli úspěšného sestavení. Po provedení změny spusťte sestavení znovu. Pokud i po [počet] pokusech o opravu stále selhává, zastavte se a nahlaste, co jste zkusili, aktuální chybu a další diagnostický krok. Shrňte příčinu a uveďte skutečný výsledek sestavení.

Pomozte mi zúžit rozsah chyby, než navrhnu opravu. Pozorované chování: [co se děje] Očekávané chování: [co by se mělo dít] Kdy k tomu dochází: [podmínky nebo četnost] Co jsem zkusil: [kroky a výsledky] Ptejte se vždy na jednu otázku a vyberte tu, která nejlépe rozliší mezi pravděpodobnými příčinami. Neopakujte otázky, na které již poskytnuté informace odpovídají. Jakmile budete mít dostatek důkazů, shrňte nejpravděpodobnější vysvětlení, co zůstává nejisté a jaký je nejmenší test, který by to mohl potvrdit nebo vyloučit. Zatím neupravujte soubory.

Použijte podřízeného agenta k revizi [rozdílů nebo větve ve srovnání se základním stavem] proti [schválenému plánu nebo souboru požadavků]. Pokud požadavky chybí nebo jsou nejednoznačné, nahlaste to před posouzením úplnosti. Zkontrolujte, zda je každý požadavek implementován, zda jsou relevantní okrajové případy otestovány a zda žádné změny nepřesahují dohodnutý rozsah. V případě potřeby prozkoumejte okolní kód, abyste porozuměli rozdílům. Nahlaste problémy se správností a nesplněné požadavky s odkazy na soubory a řádky, jejich dopadem a důkazy podporujícími každý nález. Oddělte potvrzené problémy od nevyřešených otázek. Nevymýšlejte nálezy, abyste naplnili kvótu, ani nezahrnujte nesouvisející stylistické preference. Neupravujte soubory.

Projděte [soubory nebo diff] z hlediska rizik injekce, chybějících kontrol oprávnění, odhalených tajných údajů a nebezpečného zacházení s uživatelskými vstupy. Před nahlášením nálezu zkontrolujte příslušné volající funkce a validační logiku. U každého problému identifikujte dotčený soubor a řádky, podmínky potřebné k jeho vyvolání, pravděpodobný dopad a navrhovanou opravu. Rozlišujte mezi potvrzenou zranitelnou cestou a podezřením, které vyžaduje další testování. V zprávě neuvádějte hodnoty tajných údajů, neupravujte soubory ani neprovádějte testy na živých službách. Uveďte, které oblasti jste zkontrolovali a co zůstává mimo rozsah kontroly.

Shrňte, jak jste ověřili provedenou změnu podle [kritérií přijatelnosti]. U každého kritéria uveďte provedenou kontrolu, případně přesný příkaz a pozorovaný výsledek. Přiložte relevantní výstup, přičemž utajované a citlivé údaje vymažte. Samostatně uveďte všechny již existující chyby. Jasně rozlišujte mezi kontrolami, které prošly, kontrolami, které selhaly, a kontrolami, které nebyly spuštěny. Vysvětlete všechny přeskočené kontroly nebo omezení v pokrytí. Nepopisujte celou změnu jako ověřenou, pokud některá kritéria zůstala neověřena.

Přepracujte [soubor nebo modul] s cílem [konkrétního cíle, jako je rozdělení velké funkce nebo odstranění vnořených zpětných volání]. Zachovejte jeho veřejné rozhraní, návratové hodnoty, chování při chybách a vedlejší účinky. Před úpravami spusťte [příslušný testovací příkaz], abyste stanovili výchozí stav. Pokud test selže, nahlaste chyby předtím, než budete pokračovat. Identifikujte jakékoli chování, které stávající testy nepokrývají, a v případě potřeby přidejte cílené testy. Proveďte přepracování bez nesouvisejících změn nebo nových závislostí. Neoslabujte stávající tvrzení, abyste se přizpůsobili implementaci. Znovu spusťte testy a [příkaz pro kontrolu typů nebo lint]. Ukažte výsledky před a po, shrňte strukturální změny a označte jakékoli chování, které jste nemohli ověřit.

Najděte použití [starého API nebo knihovny] v rámci [rozsahu adresáře], s výjimkou generovaných a dodavatelských souborů. Uveďte seznam dotčených souborů a veškerých sdílených konfigurací nebo závislostí, kterých se migrace může dotknout. Navrhněte tři reprezentativní soubory pro pilotní migraci na [nové API nebo verzi] s využitím [průvodce migrací nebo existujícího příkladu]. Vysvětlete, proč jste je vybrali, a označte všechny požadované změny chování. Před úpravami počkejte na mé schválení. Po schválení migrujte pouze pilotní soubory a výslovně schválené sdílené závislosti. Spusťte [příslušné testy] a [příkaz pro sestavení nebo kontrolu typů]. Migraci nerozšiřujte na další soubory. Nahlaste rozdíly, výsledky testů, problémy s kompatibilitou a případné změny potřebné v přístupu k migraci. Před pokračováním se zbývajícími soubory zastavte a požádejte o kontrolu.

Prohlédněte si aktuální větev, stav Git a rozdíly pro [funkci nebo opravu]. Identifikujte soubory patřící k této změně a samostatně uveďte nesouvisející nebo nesledované soubory. Napište návrh zprávy k commitu v souladu s formátem posledních 10 commitů. Připravte popis žádosti o pull request, který bude obsahovat, co se změnilo, proč, jaké testy byly skutečně spuštěny a případná zbývající omezení. Před zařazením do stagingu nebo publikováním čehokoli ukažte navrhovaný seznam souborů, zprávu o commitu a popis žádosti o pull. Počkejte na mé schválení. Po schválení zařaďte do stagingu pouze dohodnuté soubory, proveďte commit na [větev s funkcí], odešlete na [vzdálený server] a otevřete žádost o pull vůči [základní větvi]. Neupravujte stávající commity, neprovádějte vynucené odeslání ani neslučujte. Zašlete hash commitu a odkaz na žádost o pull.

Napište část README pro [modul] určenou pro [čtenáře, například backendového inženýra, který se připojuje k projektu]. Uveďte předpoklady, nastavení, tři příkazy, které budou používat nejčastěji, a běžné chyby, které kód nebo stávající dokumentace podporují. Ověřte názvy příkazů a volby podle [skriptů balíčku, Makefile, nápovědy CLI nebo konfigurace CI]. Označte vše, co nemůžete potvrdit. Bezpečné lokální příkazy otestujte v [testovacím prostředí], je-li k dispozici. Před spuštěním příkazů, které instalují závislosti, mažou soubory, migrují data, provádějí nasazení nebo přistupují k externím službám, vysvětlete jejich dopady a požádejte o schválení. Jasně rozlišujte příkazy, které jste úspěšně spustili, od příkazů, které jste ověřili pouze podle konfigurace nebo dokumentace. Před úpravou [cesty k dokumentaci] ukažte navrhovanou část README a zachovejte nesouvisející obsah.

Porovnejte [cesta k souboru CLAUDE.md] s aktuální strukturou repozitáře, skripty a konvencemi. Soubor zatím neupravujte. Identifikujte zastaralé pokyny, duplicity, rozpory a pravidla, která lze spolehlivě odvodit z kódu. Vysvětlete každý navrhovaný odstranění, místo toho, abyste pokyny vynechávali pouze za účelem zkrácení souboru. Chybějící příkazy pro sestavení nebo testování navrhujte pouze tehdy, pokud je můžete ověřit v projektových skriptech, souboru Makefile, konfiguraci CI nebo stávající dokumentaci. U každého doplnění uveďte zdroj. Odevzdejte navrhovaný diff, který zachovává důležité omezení projektu. Označte pokyny specifické pro daný úkol, které by lépe zapadly do pravidla v rámci dovednosti nebo cesty, a před aplikací změn počkejte na schválení.

Navrhněte háček příkazu Claude Code, který spustí [stávající příkaz formátovače] po provedení změn pomocí funkcí Edit nebo Write v [vzorech souborů]. Nejprve zkontrolujte stávající konfiguraci v souboru claude/settings.json a konfiguraci formátovače. Použijte konfiguraci PostToolUse odpovídající nainstalované verzi Claude Code. Formátujte pouze dotčený soubor, bezpečně zpracovávejte cesty a vylučte [generované soubory nebo jiné vyloučené cesty]. Neinstalujte závislosti ani nenahrazujte stávající háčky. Ukažte rozdíl v navrhovaných nastaveních a vysvětlete, jak budou hlášeny chyby formátovače. Před aplikací počkejte na schválení. Po schválení to otestujte s dočasným souborem v projektu a oznamte výsledek. Uveďte, které cesty úprav pokrývá a které ne, včetně změn provedených pomocí příkazů shellu.

Prohlédněte si příkaz [nástroj] –help a nápovědu k podpříkazům relevantním pro [úkol]. Pokud nástroj chybí, neinstalujte jej; místo toho nahláste tento předpoklad. Navrhněte přesné příkazy potřebné k dokončení úkolu. Vysvětlete jejich vstupy, výstupy a uveďte, zda zapisují soubory, mění vzdálené zdroje nebo používají přihlašovací údaje. Uveďte možnost simulace (dry-run), pokud ji nástroj dokumentuje. Označte chybějící konfiguraci nebo oprávnění a požádejte o objasnění, místo abyste hádali názvy zdrojů nebo cíle. Před spuštěním příkazů úkolu počkejte na schválení. Po schválení spusťte pouze dohodnuté příkazy a nahlaste jejich skutečné výsledky, včetně případných chyb nebo neúplných kroků.

Porovnejte soubory [invoices.csv] a [payments.csv] pomocí [ID faktury nebo odpovídajícího klíče]. Neupravujte zdrojové soubory. Použijte tato pravidla: [měna a tolerance zaokrouhlování], [přidělení částečných plateb] a [zpracování refundací, dobropisů a přeplatků]. Pokud pravidlo chybí nebo je shoda nejednoznačná, označte ji, místo abyste platbu přiřadili automaticky. Zachovejte ID zdrojových řádků. U každé faktury uveďte fakturovanou částku, přiřazené platby a zbývající zůstatek. Nahlásit duplicitní ID, neporovnané faktury, neporovnané platby a zůstatky mimo toleranci. Zúčtovat součty faktur a plateb samostatně. Zohlednit každý zdrojový řádek bez dvojího započítání; pokud je platba rozdělena mezi více faktur, uvést každé přiřazení a ověřit, že přiřazení nepřesahují částku platby. Výsledky uložit do [nových výstupních cest] a shrnout výjimky vyžadující kontrolu.

Napište skript, který shrne soubor [export.csv] za období od [počáteční datum a čas včetně] do [koncové datum a čas bez] s použitím [časového pásma] a [sloupce s datem]. Seskupte záznamy podle [pravidel kategorií] a vypočítejte [požadované metriky]. Zpracujte duplicitní ID a chybějící hodnoty podle [pravidel]. Neupravujte vstupní soubor. Spusťte skript na [přesném vstupním souboru]. Uveďte počet zahrnutých a vyloučených řádků, součty kategorií a záznamy, které nebylo možné zařadit. Porovnejte výsledky pro [tři kategorie] s nezávisle ověřenými počty v [referenčním souboru]. Pokud tyto počty nejsou k dispozici, uveďte, že nezávislé ověření dosud nebylo provedeno. Zobrazte nesrovnalosti a uložte zprávu do [nové výstupní cesty].

Prostudujte [určené soubory nebo složky] a vypracujte návrh [typ a délka dokumentu] pro [cílová skupina], který bude pokrývat [otázky nebo témata]. Každé tvrzení o faktických skutečnostech podložte názvem souboru a odkazem na stránku, oddíl nebo řádek, jsou-li k dispozici. Rozlišujte přímé citace od parafrází a nepovažujte návrh nebo zastaralý dokument za potvrzené aktuální rozhodnutí. Označte si protichůdné zdroje, chybějící informace a tvrzení, která nemůžete ověřit. Nevyplňujte mezery domněnkami ani neupravujte zdrojové soubory. Odevzdejte návrh s odkazy a krátkým seznamem nevyřešených otázek pro recenzenta.

Chcete-li šablonu přizpůsobit, nahraďte v ní zástupné symboly údaji z vašeho projektu a před provedením změn se rozhodněte, co má Claude udělat. Pomocí těchto kroků připravte požadavek a zkontrolujte výsledek.

V případě malé, jasně definované změny můžete požádat Clauda, aby ji přímo implementoval. U neznámého kódu, změn zasahujících do několika souborů nebo nevyřešených požadavků začněte s plánem.

Stiskněte klávesy Shift+Tab, dokud se nezobrazí režim plánování, nebo spusťte Claude Code příkazem claude --permission-mode plan. V tomto režimu může Claude prohlížet soubory a spouštět příkazy pouze pro čtení, aniž by upravoval váš zdrojový kód. Před schválením implementace zkontrolujte navrhované soubory, závislosti a testy. Stisknutím kláves Ctrl+G otevřete navrhovaný plán ve svém editoru.

Poskytněte Claudovi podklady potřebné k pochopení úkolu: odkaz na soubor, očištěný protokol chyb, snímek obrazovky nebo dokument s požadavky. Chcete-li vložit obsah daného souboru, použijte znak @ následovaný cestou k souboru.

Vyberte nejmenší užitečnou sadu zdrojů. Zahrnutí celého protokolu nebo adresáře může přidat irelevantní materiál a zabírat kontext. Před sdílením protokolů odstraňte přihlašovací údaje a citlivá data a zkontrolujte, zda má Claude k dispozici nástroje potřebné k načtení všech URL adres dokumentace, které poskytnete.

Například příkaz `cat error.log | claude -p "Explain this error"` odešle protokol s neinteraktivním požadavkem. Použijte jej až po zkontrolování obsahu souboru. V tom spočívá praktická hodnota kontextové AI: poskytnutí modelu relevantních informací pro daný úkol.

Při přidávání nové funkce vyhledejte v repozitáři podobnou komponentu nebo funkci. Sdělte Claudovi, jaké konvence má dodržovat, například ohledně API klienta, validační logiky, zpracování chyb nebo struktury testů.

„Sledujte, jak soubor @src/widgets/Weather.tsx načítá a ukládá data do mezipaměti“ poskytuje Claudovi konkrétní vodítko. Uveďte také případné rozdíly, které nová funkce vyžaduje, aby se nekopírovalo chování, které již není vhodné. Tyto konvence by měly odrážet pracovní postupy vašeho týmu při vývoji softwaru.

V případě změn v kódu uveďte příslušný příkaz pro testování, sestavení nebo kontrolu kódu a chování, které by měl ověřit. Pro výzkumné účely požádejte o odkazy na soubory nebo ID commitů. Pro práci s uživatelským rozhraním poskytněte referenční obrázek a nakonfigurovaný způsob, jak zachytit implementaci ve stejném zobrazení.

Požádejte Clauda, aby vám nahlásil, co skutečně zkontroloval, včetně selhání a přeskočených kontrol. Zkontrolujte, zda důkazy pokrývají daný požadavek; úspěšná kompilace ještě neznamená, že funguje každé požadované chování.

Pro delší úkoly nabízí Claude Code také podmínku /goal a háčky Stop. Vyhodnocovač cílů posuzuje důkazy, které se objevily v konverzaci, namísto samostatné kontroly souborů nebo spouštění testů. Nakonfigurovaný háček Stop může zablokovat dokončení, má však omezení ohledně opakovaného blokování. Ani jedno z nich nenahrazuje odpovídající testy a lidskou kontrolu.

Pokud opakované opravy problém nevyřeší, zastavte se a zjistěte, co v původním požadavku nebylo jasné. Před vymazáním konverzace si uložte užitečné poznatky, aktuální stav v Git a zbývající práci.

Průvodce osvědčenými postupy společnosti Anthropic doporučuje začít od začátku po dvou neúspěšných opravách stejného problému. Použijte příkaz /clear a poté zadejte upravený příkaz, který zahrnuje to, co jste se naučili. Vymazání konverzace nezruší změny v souborech.

Stisknutím klávesy Esc přerušíte probíhající odpověď. Pokud je pole pro zadání příkazu prázdné, stiskněte dvakrát klávesu Esc, otevřete nabídku převinutí zpět a vyberte, co chcete obnovit. Převinutí zpět nezruší všechny externí účinky, proto pro změny v databázích nebo vzdálených službách používejte kontrolní body Git a samostatné postupy obnovy.

Uložte si pokyny pro celý projekt do souboru CLAUDE.md, opakovatelné postupy do dovedností a pokyny pro konkrétní soubory do pravidel s rozsahem na úrovni cesty. Používejte háčky pro akce vázané na konkrétní události, jako je spuštění formátovače po úpravě.

Vyberte si podle toho, kdy by se pokyn měl uplatnit:

Požadavek na jednu funkci obvykle patří do zadání úkolu nebo specifikace, nikoli do souboru CLAUDE.md. Přidávání dočasných pokynů do souboru platného pro celý projekt ztěžuje jejich odlišení od konvencí, které by měly platit v celém repozitáři.

Například uložte testovací příkaz projektu do souboru CLAUDE.md, umístěte konvence specifické pro jednotlivé komponenty do pravidla s rozsahem na cestu a uložte opakující se postup revize jako dovednost. Tyto soubory zkontrolujte, když dojde ke změně příkazů nebo konvencí, stejně jako byste to udělali u jiné projektové dokumentace.

Pokyny, soubor CLAUDE.md a průvodce dovednostmi určují chování Claude; nezaručují však, že bude daný pokyn splněn. Hooky mohou provádět kontroly při nakonfigurovaných událostech, ale jejich spolehlivost závisí na typu hooku a jeho implementaci.

Hook příkazu spouští skript. Hook výzvy nebo agenta se spoléhá na úsudek modelu. Jak vysvětluje průvodce osvědčenými postupy společnosti Anthropic: „Hook výzvy nebo agenta žádá jiný model o rozhodnutí, takže ani on není deterministický.“ U pravidla, které musí být vynuceno, použijte příslušné ovládací prvky oprávnění a otestujte příslušný hook příkazu nebo HTTP, včetně toho, jak zpracovává selhání.

Vlastní subagenti představují další způsob, jak organizovat opakující se úkoly. Pokud potřebujete specifickou revizní roli nebo rozsah nástrojů, definujte specialistu v adresáři in.claude/agents/, místo abyste každou instrukci pro specialistu přidávali do hlavní relace. Další informace najdete v těchto průvodcích věnovaných nejvhodnějšímu modelu Claude pro práci a typům agentů AI.

Pokud váš tým spravuje podněty napříč několika produkty umělé inteligence, podívejte se na tyto nástroje pro tvorbu podnětů, které umožňují správu knihoven i mimo Claude Code.

Pokud relace vygeneruje neúplný nebo nevhodný výsledek, zkontrolujte, zda požadavek nezanechal nevyřešená důležitá rozhodnutí. Těchto pět chyb může zkomplikovat diagnostiku a revizi práce.

Pokyn „Prozkoumat repozitář“ dává Claudovi jen málo informací o tom, které soubory jsou důležité nebo kdy má přestat. Může se stát, že obdržíte obecné shrnutí bez odpovědi na problém, který vedl k zadání dotazu.

Pojmenujte chování nebo rozhodnutí, které potřebujete pochopit, určete výchozí bod a definujte očekávaný výstup. Například: „Sledujte, jak tento koncový bod kontroluje oprávnění, a uveďte příslušné funkce.“ Pokud používáte podagenty, zadejte každému z nich ohraničenou otázku, místo abyste jim delegovali stejné neomezené vyhledávání.

Při přepínání mezi funkcí, nesouvisející chybou a požadavkem na dokumentaci zůstává v konverzaci kontext, který se nemusí vztahovat k aktuálnímu úkolu. Odkazy jako „ten soubor“ nebo „předchozí přístup“ se stávají nejednoznačnými.

Pro nesouvisející práci používejte samostatné relace. Pokud bude repozitář upravovat více relací, použijte samostatné pracovní stromy Git, aby neupravovaly stejný pracovní adresář. Krátká poznámka na okraj: příkaz /btw v Claude Code udržuje tuto výměnu mimo hlavní historii konverzace.

Sestavení může projít, i když se funkce chová nesprávně. Sada testů může projít, protože nikdy neprověřila vstup, který by způsobil selhání. Požádání Clauda o „spuštění testů“ nezjišťuje, který požadavek tyto testy ověřují.

Přiřaďte akceptační kritéria ke konkrétním kontrolám. Při opravě chyby požadujte důkaz, že test reprodukovatelnosti selhal před provedením změny a po ní prošel. Nechat na očích netestovaná kritéria, místo toho, abyste jeden úspěšný příkaz považovali za ověření celé změny.

Rozšiřující se soubor CLAUDE.md může obsahovat zastaralé příkazy, duplicitní pravidla a pokyny, které jsou v rozporu s požadavky konkrétních úkolů. Použití důraznějšího znění tyto konflikty nevyřeší.

Porovnejte soubor s aktuálním repozitářem. Odstraňte zastaralé pokyny, vyjasněte si navzájem si odporující pravidla a přesuňte úzce použitelná pokyny do pravidel nebo dovedností s rozsahem platnosti na konkrétní cestu. Pokud je třeba požadavek vynutit, nakonfigurujte a otestujte příslušné kontrolní mechanismy, místo abyste se spoléhali na opakovaná upozornění.

Revize může odhalit skutečné chyby, nejisté problémy i volitelné návrhy na refaktoring. Aplikace všech návrhů může změnu rozšířit, aniž by došlo ke zlepšení požadovaného chování.

Žádejte důkazy a informace o dopadu každého zjištění. Upřednostňujte problémy se správností a nesplněné požadavky, prověřujte nejisté tvrzení a vyřazujte nesouvisející vylepšení z aktuálního rozdílu. Recenzent by měl být schopen nahlásit, že neexistují žádná zjištění vyžadující opatření, pokud důkazy tento závěr podporují.

Chcete-li šablonu přizpůsobit, nahraďte v ní zástupné symboly údaji z vašeho projektu a před provedením změn se rozhodněte, co má Claude udělat. Pomocí těchto kroků připravte požadavek a zkontrolujte výsledek.

V případě malé, jasně definované změny můžete požádat Clauda, aby ji přímo implementoval. U neznámého kódu, změn zasahujících do několika souborů nebo nevyřešených požadavků začněte s plánem.

Stiskněte klávesy Shift+Tab, dokud se nezobrazí režim plánování, nebo spusťte Claude Code příkazem claude --permission-mode plan. V tomto režimu může Claude prohlížet soubory a spouštět příkazy pouze pro čtení, aniž by upravoval váš zdrojový kód. Před schválením implementace zkontrolujte navrhované soubory, závislosti a testy. Stisknutím kláves Ctrl+G otevřete navrhovaný plán ve svém editoru.

Poskytněte Claudovi podklady potřebné k pochopení úkolu: odkaz na soubor, očištěný protokol chyb, snímek obrazovky nebo dokument s požadavky. Chcete-li vložit obsah daného souboru, použijte znak @ následovaný cestou k souboru.

Vyberte nejmenší užitečnou sadu zdrojů. Zahrnutí celého protokolu nebo adresáře může přidat irelevantní materiál a zabírat kontext. Před sdílením protokolů odstraňte přihlašovací údaje a citlivá data a zkontrolujte, zda má Claude k dispozici nástroje potřebné k načtení všech URL adres dokumentace, které poskytnete.

Například příkaz `cat error.log | claude -p "Explain this error"` odešle protokol s neinteraktivním požadavkem. Použijte jej až po zkontrolování obsahu souboru. V tom spočívá praktická hodnota kontextové AI: poskytnutí modelu relevantních informací pro daný úkol.

Při přidávání nové funkce vyhledejte v repozitáři podobnou komponentu nebo funkci. Sdělte Claudovi, jaké konvence má dodržovat, například ohledně API klienta, validační logiky, zpracování chyb nebo struktury testů.

„Sledujte, jak soubor @src/widgets/Weather.tsx načítá a ukládá data do mezipaměti“ poskytuje Claudovi konkrétní vodítko. Uveďte také případné rozdíly, které nová funkce vyžaduje, aby se nekopírovalo chování, které již není vhodné. Tyto konvence by měly odrážet pracovní postupy vašeho týmu při vývoji softwaru.

V případě změn v kódu uveďte příslušný příkaz pro testování, sestavení nebo kontrolu kódu a chování, které by měl ověřit. Pro výzkumné účely požádejte o odkazy na soubory nebo ID commitů. Pro práci s uživatelským rozhraním poskytněte referenční obrázek a nakonfigurovaný způsob, jak zachytit implementaci ve stejném zobrazení.

Požádejte Clauda, aby vám nahlásil, co skutečně zkontroloval, včetně selhání a přeskočených kontrol. Zkontrolujte, zda důkazy pokrývají daný požadavek; úspěšná kompilace ještě neznamená, že funguje každé požadované chování.

Pro delší úkoly nabízí Claude Code také podmínku /goal a háčky Stop. Vyhodnocovač cílů posuzuje důkazy, které se objevily v konverzaci, namísto samostatné kontroly souborů nebo spouštění testů. Nakonfigurovaný háček Stop může zablokovat dokončení, má však omezení ohledně opakovaného blokování. Ani jedno z nich nenahrazuje odpovídající testy a lidskou kontrolu.

Pokud opakované opravy problém nevyřeší, zastavte se a zjistěte, co v původním požadavku nebylo jasné. Před vymazáním konverzace si uložte užitečné poznatky, aktuální stav v Git a zbývající práci.

Průvodce osvědčenými postupy společnosti Anthropic doporučuje začít od začátku po dvou neúspěšných opravách stejného problému. Použijte příkaz /clear a poté zadejte upravený příkaz, který zahrnuje to, co jste se naučili. Vymazání konverzace nezruší změny v souborech.

Stisknutím klávesy Esc přerušíte probíhající odpověď. Pokud je pole pro zadání příkazu prázdné, stiskněte dvakrát klávesu Esc, čímž otevřete nabídku vrácení zpět a vyberte, co chcete obnovit. Funkce vrácení zpět nezruší všechny externí účinky, proto pro změny v databázích nebo vzdálených službách používejte kontrolní body Git a samostatné postupy obnovy.

Uložte pokyny pro celý projekt do souboru CLAUDE.md, opakovatelné postupy do dovedností a pokyny pro konkrétní soubory do pravidel s rozsahem na úrovni cesty. Používejte háčky pro akce vázané na konkrétní události, jako je spuštění formátovače po úpravě.

Vyberte si podle toho, kdy by se pokyn měl uplatnit:

Požadavek na jednu funkci obvykle patří do zadání úkolu nebo specifikace, nikoli do souboru CLAUDE.md. Přidávání dočasných pokynů do souboru platného pro celý projekt ztěžuje jejich odlišení od konvencí, které by měly platit v celém repozitáři.

Například uložte testovací příkaz projektu do souboru CLAUDE.md, umístěte konvence specifické pro jednotlivé komponenty do pravidla s rozsahem na cestě a uložte opakující se postup revize jako dovednost. Tyto soubory zkontrolujte, když dojde ke změně příkazů nebo konvencí, stejně jako byste to udělali u jiné projektové dokumentace.

Pokyny, soubor CLAUDE.md a průvodce dovednostmi určují chování Claude; nezaručují však, že bude daný pokyn splněn. Hooky mohou provádět kontroly při nakonfigurovaných událostech, ale jejich spolehlivost závisí na typu hooku a jeho implementaci.

Hook příkazu spouští skript. Hook výzvy nebo agenta se spoléhá na úsudek modelu. Jak vysvětluje průvodce osvědčenými postupy společnosti Anthropic: „Hook výzvy nebo agenta žádá jiný model o rozhodnutí, takže ani on není deterministický.“ U pravidla, které musí být vynuceno, použijte příslušné ovládací prvky oprávnění a otestujte příslušný hook příkazu nebo HTTP, včetně toho, jak zpracovává selhání.

Vlastní subagenti představují další způsob, jak organizovat opakující se úkoly. Pokud potřebujete specifickou revizní roli nebo rozsah nástrojů, definujte specialistu v adresáři in. claude/agents/, místo abyste každou instrukci pro specialistu přidávali do hlavní relace. Další informace najdete v těchto průvodcích věnovaných nejvhodnějšímu modelu Claude pro práci a typům agentů AI.

Pokud váš tým spravuje podněty napříč několika produkty umělé inteligence, podívejte se na tyto nástroje pro tvorbu podnětů, které umožňují správu knihoven i mimo Claude Code.

Pokud relace vygeneruje neúplný nebo nevhodný výsledek, zkontrolujte, zda požadavek nezanechal nevyřešená důležitá rozhodnutí. Těchto pět chyb může zkomplikovat diagnostiku a revizi práce.

Pokyn „Prozkoumat repozitář“ dává Claudovi jen málo informací o tom, které soubory jsou důležité nebo kdy má přestat. Může se stát, že obdržíte obecné shrnutí bez odpovědi na problém, který vedl k zadání dotazu.

Pojmenujte chování nebo rozhodnutí, které potřebujete pochopit, určete výchozí místo a definujte očekávaný výstup. Například: „Sledujte, jak tento koncový bod kontroluje oprávnění, a uveďte příslušné funkce.“ Pokud používáte podagenty, zadejte každému z nich ohraničenou otázku, místo abyste jim delegovali stejné neomezené vyhledávání.

Při přepínání mezi funkcí, nesouvisející chybou a požadavkem na dokumentaci zůstává v konverzaci kontext, který se nemusí vztahovat k aktuálnímu úkolu. Odkazy jako „ten soubor“ nebo „předchozí přístup“ se stávají nejednoznačnými.

Pro nesouvisející práci používejte samostatné relace. Pokud bude repozitář upravovat více relací, použijte samostatné pracovní stromy Git, aby neupravovaly stejný pracovní adresář. Krátká poznámka na okraj: příkaz /btw v Claude Code udržuje tuto výměnu mimo hlavní historii konverzace.

Sestavení může projít, i když se funkce chová nesprávně. Sada testů může projít, protože nikdy neprověřila vstup, který by způsobil selhání. Požádání Clauda o „spuštění testů“ nezjišťuje, který požadavek tyto testy ověřují.

Přiřaďte akceptační kritéria ke konkrétním kontrolám. Při opravě chyby požadujte důkaz, že test reprodukovatelnosti selhal před provedením změny a po ní prošel. Nechat na očích netestovaná kritéria, místo toho, abyste jeden úspěšný příkaz považovali za ověření celé změny.

Rozšiřující se soubor CLAUDE.md může obsahovat zastaralé příkazy, duplicitní pravidla a pokyny, které jsou v rozporu s požadavky konkrétních úkolů. Použití důraznější formulace tyto konflikty nevyřeší.

Porovnejte soubor s aktuálním repozitářem. Odstraňte zastaralé pokyny, vyjasněte si navzájem si odporující pravidla a přesuňte úzce použitelná pokyny do pravidel nebo dovedností s rozsahem platnosti na úrovni cesty. Pokud je třeba požadavek vynutit, nakonfigurujte a otestujte příslušné kontrolní mechanismy, místo abyste se spoléhali na opakovaná upozornění.

Revize může odhalit skutečné chyby, nejisté problémy i volitelné návrhy na refaktoring. Aplikace všech návrhů může změnu rozšířit, aniž by došlo ke zlepšení požadovaného chování.

Žádejte důkazy a informace o dopadu každého zjištění. Upřednostňujte problémy se správností a nesplněné požadavky, prověřujte nejisté tvrzení a vyřazujte nesouvisející vylepšení z aktuálního rozdílu. Recenzent by měl být schopen nahlásit, že neexistují žádná zjištění vyžadující opatření, pokud důkazy tento závěr podporují.

Chcete-li šablonu přizpůsobit, nahraďte v ní zástupné symboly údaji z vašeho projektu a před provedením změn se rozhodněte, co má Claude udělat. Pomocí těchto kroků připravte požadavek a zkontrolujte výsledek.

V případě malé, jasně definované změny můžete požádat Clauda, aby ji přímo implementoval. U neznámého kódu, změn zasahujících do několika souborů nebo nevyřešených požadavků začněte s plánem.

Stiskněte klávesy Shift+Tab, dokud se nezobrazí režim plánování, nebo spusťte Claude Code příkazem claude --permission-mode plan. V tomto režimu může Claude prohlížet soubory a spouštět příkazy pouze pro čtení, aniž by upravoval váš zdrojový kód. Před schválením implementace zkontrolujte navrhované soubory, závislosti a testy. Stisknutím kláves Ctrl+G otevřete navrhovaný plán ve svém editoru.

Poskytněte Claudovi podklady potřebné k pochopení úkolu: odkaz na soubor, očištěný protokol chyb, snímek obrazovky nebo dokument s požadavky. Chcete-li vložit obsah daného souboru, použijte znak @ následovaný cestou k souboru.

Vyberte nejmenší užitečnou sadu zdrojů. Zahrnutí celého protokolu nebo adresáře může přidat irelevantní materiál a zabírat kontext. Před sdílením protokolů odstraňte přihlašovací údaje a citlivá data a zkontrolujte, zda má Claude k dispozici nástroje potřebné k načtení všech URL adres dokumentace, které poskytnete.

Například příkaz `cat error.log | claude -p "Explain this error"` odešle protokol v rámci neinteraktivního požadavku. Používejte jej až po zkontrolování obsahu souboru. V tom spočívá praktická hodnota kontextové AI: poskytnutí relevantních informací modelu pro daný úkol.

Při přidávání nové funkce vyhledejte v repozitáři podobnou komponentu nebo funkci. Sdělte Claudovi, jaké konvence má dodržovat, například ohledně API klienta, validační logiky, zpracování chyb nebo struktury testů.

„Sledujte, jak soubor @src/widgets/Weather.tsx načítá a ukládá data do mezipaměti“ poskytuje Claudovi konkrétní vodítko. Uveďte také případné rozdíly, které nová funkce vyžaduje, aby se nekopírovalo chování, které již není vhodné. Tyto konvence by měly odrážet pracovní postupy vašeho týmu při vývoji softwaru.

V případě změn v kódu uveďte příslušný příkaz pro testování, sestavení nebo kontrolu kódu a chování, které by měl ověřit. Pro výzkumné účely požádejte o odkazy na soubory nebo ID commitů. Pro práci s uživatelským rozhraním poskytněte referenční obrázek a nakonfigurovaný způsob, jak zachytit implementaci ve stejném zobrazení.

Požádejte Clauda, aby vám nahlásil, co skutečně zkontroloval, včetně selhání a přeskočených kontrol. Zkontrolujte, zda důkazy pokrývají daný požadavek; úspěšná kompilace ještě neznamená, že funguje každé požadované chování.

Pro delší úkoly nabízí Claude Code také podmínku /goal a háčky Stop. Vyhodnocovač cílů posuzuje důkazy, které se objevily v konverzaci, namísto samostatné kontroly souborů nebo spouštění testů. Nakonfigurovaný háček Stop může zablokovat dokončení, má však omezení ohledně opakovaného blokování. Ani jedno z nich nenahrazuje odpovídající testy a lidskou kontrolu.

Pokud opakované opravy problém nevyřeší, zastavte se a zjistěte, co v původním požadavku nebylo jasné. Před vymazáním konverzace si uložte užitečné poznatky, aktuální stav v Git a zbývající práci.

Průvodce osvědčenými postupy společnosti Anthropic doporučuje začít od začátku po dvou neúspěšných opravách stejného problému. Použijte příkaz /clear a poté zadejte upravený příkaz, který zahrnuje to, co jste se naučili. Vymazání konverzace nezruší změny v souborech.

Stisknutím klávesy Esc přerušíte probíhající odpověď. Pokud je pole pro zadání příkazu prázdné, stiskněte dvakrát klávesu Esc, otevřete nabídku převinutí zpět a vyberte, co chcete obnovit. Převinutí zpět nezruší všechny externí účinky, proto pro změny v databázích nebo vzdálených službách používejte kontrolní body Git a samostatné postupy obnovy.

Uložte pokyny pro celý projekt do souboru CLAUDE.md, opakovatelné postupy do dovedností a pokyny pro konkrétní soubory do pravidel s rozsahem na úrovni cesty. Používejte háčky pro akce vázané na konkrétní události, jako je spuštění formátovače po úpravě.

Vyberte si podle toho, kdy by se pokyn měl uplatnit:

Požadavek na jednu funkci obvykle patří do zadání úkolu nebo specifikace, nikoli do souboru CLAUDE.md. Přidávání dočasných pokynů do souboru platného pro celý projekt ztěžuje jejich odlišení od konvencí, které by měly platit v celém repozitáři.

Například uložte testovací příkaz projektu do souboru CLAUDE.md, umístěte konvence specifické pro jednotlivé komponenty do pravidla s rozsahem na cestu a uložte opakující se postup revize jako dovednost. Tyto soubory zkontrolujte, když dojde ke změně příkazů nebo konvencí, stejně jako byste to udělali u jiné projektové dokumentace.

Pokyny, soubor CLAUDE.md a průvodce dovednostmi určují chování Claude; nezaručují však, že bude daný pokyn splněn. Hooky mohou provádět kontroly při nakonfigurovaných událostech, ale jejich spolehlivost závisí na typu hooku a jeho implementaci.

Hook příkazu spouští skript. Hook výzvy nebo agenta se spoléhá na úsudek modelu. Jak vysvětluje průvodce osvědčenými postupy společnosti Anthropic: „Hook výzvy nebo agenta žádá jiný model o rozhodnutí, takže ani on není deterministický.“ U pravidla, které musí být vynuceno, použijte příslušné ovládací prvky oprávnění a otestujte příslušný hook příkazu nebo HTTP, včetně toho, jak zpracovává selhání.

Vlastní subagenti představují další způsob, jak organizovat opakující se úkoly. Pokud potřebujete specifickou revizní roli nebo rozsah nástrojů, definujte specialistu v adresáři in.claude/agents/, místo abyste každou instrukci pro specialistu přidávali do hlavní relace. Další informace najdete v těchto průvodcích věnovaných nejvhodnějšímu modelu Claude pro práci a typům agentů AI.

Pokud váš tým spravuje podněty napříč několika produkty umělé inteligence, podívejte se na tyto nástroje pro tvorbu podnětů, které umožňují správu knihoven i mimo Claude Code.

Pokud relace vygeneruje neúplný nebo nevhodný výsledek, zkontrolujte, zda požadavek nezanechal nevyřešená důležitá rozhodnutí. Těchto pět chyb může zkomplikovat diagnostiku a revizi práce.

Pokyn „Prozkoumat repozitář“ dává Claudovi jen málo informací o tom, které soubory jsou důležité nebo kdy má přestat. Může se stát, že obdržíte obecné shrnutí bez odpovědi na problém, který vedl k zadání dotazu.

Pojmenujte chování nebo rozhodnutí, které potřebujete pochopit, určete výchozí místo a definujte očekávaný výstup. Například: „Sledujte, jak tento koncový bod kontroluje oprávnění, a uveďte příslušné funkce.“ Pokud používáte podagenty, zadejte každému z nich ohraničenou otázku, místo abyste jim delegovali stejné neomezené vyhledávání.

Při přepínání mezi funkcí, nesouvisející chybou a požadavkem na dokumentaci zůstává v konverzaci kontext, který se nemusí vztahovat k aktuálnímu úkolu. Odkazy jako „ten soubor“ nebo „předchozí přístup“ se stávají nejednoznačnými.

Pro nesouvisející práci používejte samostatné relace. Pokud bude repozitář upravovat více relací, použijte samostatné pracovní stromy Git, aby neupravovaly stejný pracovní adresář. Krátká poznámka na okraj: příkaz /btw v Claude Code udržuje tuto výměnu mimo hlavní historii konverzace.

Sestavení může projít, i když se funkce chová nesprávně. Sada testů může projít, protože nikdy neprověřila vstup, který by způsobil selhání. Požádání Clauda o „spuštění testů“ nezjišťuje, který požadavek tyto testy ověřují.

Přiřaďte akceptační kritéria ke konkrétním kontrolám. Při opravě chyby požadujte důkaz, že test reprodukovatelnosti selhal před provedením změny a po ní prošel. Nechat na očích netestovaná kritéria, místo toho, abyste jeden úspěšný příkaz považovali za ověření celé změny.

Rozšiřující se soubor CLAUDE.md může obsahovat zastaralé příkazy, duplicitní pravidla a pokyny, které jsou v rozporu s požadavky konkrétních úkolů. Použití důraznějšího znění tyto konflikty nevyřeší.

Porovnejte soubor s aktuálním repozitářem. Odstraňte zastaralé pokyny, vyjasněte si navzájem si odporující pravidla a přesuňte úzce použitelná pokyny do pravidel nebo dovedností s rozsahem platnosti na úrovni cesty. Pokud je třeba požadavek vynutit, nakonfigurujte a otestujte příslušné kontrolní mechanismy, místo abyste se spoléhali na opakovaná upozornění.

Revize může odhalit skutečné chyby, nejisté problémy i volitelné návrhy na refaktoring. Aplikace všech návrhů může změnu rozšířit, aniž by došlo ke zlepšení požadovaného chování.

Žádejte důkazy a informace o dopadu každého zjištění. Upřednostňujte problémy se správností a nesplněné požadavky, prověřujte nejisté tvrzení a vyřazujte nesouvisející vylepšení z aktuálního rozdílu. Recenzent by měl být schopen nahlásit, že neexistují žádná zjištění vyžadující opatření, pokud důkazy tento závěr podporují.

Chcete-li šablonu přizpůsobit, nahraďte v ní zástupné symboly údaji z vašeho projektu a před provedením změn se rozhodněte, co má Claude udělat. Pomocí těchto kroků připravte požadavek a zkontrolujte výsledek.

V případě malé, jasně definované změny můžete požádat Clauda, aby ji přímo implementoval. U neznámého kódu, změn zasahujících do několika souborů nebo nevyřešených požadavků začněte s plánem.

Stiskněte klávesy Shift+Tab, dokud se nezobrazí režim plánování, nebo spusťte Claude Code příkazem claude --permission-mode plan. V tomto režimu může Claude prohlížet soubory a spouštět příkazy pouze pro čtení, aniž by upravoval váš zdrojový kód. Před schválením implementace zkontrolujte navrhované soubory, závislosti a testy. Stisknutím kláves Ctrl+G otevřete navrhovaný plán ve svém editoru.

Poskytněte Claudovi podklady potřebné k pochopení úkolu: odkaz na soubor, očištěný protokol chyb, snímek obrazovky nebo dokument s požadavky. Chcete-li vložit obsah daného souboru, použijte znak @ následovaný cestou k souboru.

Vyberte nejmenší užitečnou sadu zdrojů. Zahrnutí celého protokolu nebo adresáře může přidat irelevantní materiál a zabírat kontext. Před sdílením protokolů odstraňte přihlašovací údaje a citlivá data a zkontrolujte, zda má Claude k dispozici nástroje potřebné k načtení všech URL adres dokumentace, které poskytnete.

Například příkaz `cat error.log | claude -p "Explain this error"` odešle protokol s neinteraktivním požadavkem. Použijte jej až po zkontrolování obsahu souboru. V tom spočívá praktická hodnota kontextové AI: poskytnutí relevantních informací modelu pro daný úkol.

Při přidávání nové funkce vyhledejte v repozitáři podobnou komponentu nebo funkci. Sdělte Claudovi, jaké konvence má dodržovat, například ohledně API klienta, validační logiky, zpracování chyb nebo struktury testů.

„Sledujte, jak soubor @src/widgets/Weather.tsx načítá a ukládá data do mezipaměti“ poskytuje Claudovi konkrétní vodítko. Uveďte také případné rozdíly, které nová funkce vyžaduje, aby se nekopírovalo chování, které již není vhodné. Tyto konvence by měly odrážet pracovní postupy vašeho týmu při vývoji softwaru.

V případě změn v kódu uveďte příslušný příkaz pro testování, sestavení nebo kontrolu kódu a chování, které by měl ověřit. Pro výzkumné účely požádejte o odkazy na soubory nebo ID commitů. Pro práci s uživatelským rozhraním poskytněte referenční obrázek a nakonfigurovaný způsob, jak zachytit implementaci ve stejném zobrazení.

Požádejte Clauda, aby vám nahlásil, co skutečně zkontroloval, včetně selhání a přeskočených kontrol. Zkontrolujte, zda důkazy pokrývají daný požadavek; úspěšná kompilace ještě neznamená, že funguje každé požadované chování.

Pro delší úkoly nabízí Claude Code také podmínku /goal a háčky Stop. Vyhodnocovač cílů posuzuje důkazy, které se objevily v konverzaci, namísto samostatné kontroly souborů nebo spouštění testů. Nakonfigurovaný háček Stop může zablokovat dokončení, má však omezení ohledně opakovaného blokování. Ani jedno z nich nenahrazuje odpovídající testy a lidskou kontrolu.

Pokud opakované opravy problém nevyřeší, zastavte se a zjistěte, co v původním požadavku nebylo jasné. Před vymazáním konverzace si uložte užitečné poznatky, aktuální stav v Git a zbývající práci.

Průvodce osvědčenými postupy společnosti Anthropic doporučuje začít od začátku po dvou neúspěšných opravách stejného problému. Použijte příkaz /clear a poté zadejte upravený příkaz, který zahrnuje to, co jste se naučili. Vymazání konverzace nezruší změny v souborech.

Stisknutím klávesy Esc přerušíte probíhající odpověď. Pokud je pole pro zadání příkazu prázdné, stiskněte dvakrát klávesu Esc, otevřete nabídku převinutí zpět a vyberte, co chcete obnovit. Převinutí zpět nezruší všechny externí účinky, proto pro změny v databázích nebo vzdálených službách používejte kontrolní body Git a samostatné postupy obnovy.

Ukládejte pokyny pro celý projekt do souboru CLAUDE.md, opakovatelné postupy do dovedností a pokyny pro konkrétní soubory do pravidel s rozsahem na úrovni cesty. Používejte háčky pro akce vázané na konkrétní události, jako je spuštění formátovače po úpravě.

Vyberte si podle toho, kdy by se pokyn měl uplatnit:

Požadavek na jednu funkci obvykle patří do zadání úkolu nebo specifikace, nikoli do souboru CLAUDE.md. Přidávání dočasných pokynů do souboru platného pro celý projekt ztěžuje jejich odlišení od konvencí, které by měly platit v celém repozitáři.

Například uložte testovací příkaz projektu do souboru CLAUDE.md, umístěte konvence specifické pro jednotlivé komponenty do pravidla s rozsahem na cestě a uložte opakující se postup revize jako dovednost. Tyto soubory zkontrolujte, když dojde ke změně příkazů nebo konvencí, stejně jako byste to udělali u jiné projektové dokumentace.

Pokyny, soubor CLAUDE.md a průvodce dovednostmi určují chování Claude; nezaručují však, že bude daný pokyn splněn. Hooky mohou provádět kontroly při nakonfigurovaných událostech, ale jejich spolehlivost závisí na typu hooku a jeho implementaci.

Hook příkazu spouští skript. Hook výzvy nebo agenta se spoléhá na úsudek modelu. Jak vysvětluje průvodce osvědčenými postupy společnosti Anthropic: „Hook výzvy nebo agenta žádá jiný model o rozhodnutí, takže ani on není deterministický.“ U pravidla, které musí být vynuceno, použijte příslušné ovládací prvky oprávnění a otestujte příslušný hook příkazu nebo HTTP, včetně toho, jak zpracovává selhání.

Vlastní subagenti představují další způsob, jak organizovat opakující se úkoly. Pokud potřebujete specifickou revizní roli nebo rozsah nástrojů, definujte specialistu v adresáři in. claude/agents/, místo abyste každou instrukci pro specialistu přidávali do hlavní relace. Další informace najdete v těchto průvodcích věnovaných nejvhodnějšímu modelu Claude pro práci a typům agentů AI.

Pokud váš tým spravuje podněty napříč několika produkty umělé inteligence, podívejte se na tyto nástroje pro tvorbu podnětů, které umožňují správu knihoven i mimo Claude Code.

Pokud relace vygeneruje neúplný nebo nevhodný výsledek, zkontrolujte, zda požadavek nezanechal nevyřešená důležitá rozhodnutí. Těchto pět chyb může zkomplikovat diagnostiku a revizi práce.

Pokyn „Prozkoumat repozitář“ dává Claudovi jen málo informací o tom, které soubory jsou důležité nebo kdy má přestat. Může se stát, že obdržíte obecný souhrn bez odpovědi na problém, který vedl k zadání dotazu.

Pojmenujte chování nebo rozhodnutí, které potřebujete pochopit, určete výchozí místo a definujte očekávaný výstup. Například: „Sledujte, jak tento koncový bod kontroluje oprávnění, a uveďte příslušné funkce.“ Pokud používáte podagenty, zadejte každému z nich ohraničenou otázku, místo abyste jim delegovali stejné neomezené vyhledávání.

Při přepínání mezi funkcí, nesouvisející chybou a požadavkem na dokumentaci zůstává v konverzaci kontext, který se nemusí vztahovat k aktuálnímu úkolu. Odkazy jako „ten soubor“ nebo „předchozí přístup“ se stávají nejednoznačnými.

Pro nesouvisející práci používejte samostatné relace. Pokud bude repozitář upravovat více relací, použijte samostatné pracovní stromy Git, aby neupravovaly stejný pracovní adresář. Krátká poznámka na okraj: příkaz /btw v Claude Code udržuje tuto výměnu mimo hlavní historii konverzace.

Sestavení může projít, i když se funkce chová nesprávně. Sada testů může projít, protože nikdy neprověřila vstup, který by způsobil selhání. Požádání Clauda o „spuštění testů“ nezjišťuje, který požadavek tyto testy ověřují.

Přiřaďte akceptační kritéria ke konkrétním kontrolám. Při opravě chyby požadujte důkaz, že test reprodukovatelnosti selhal před provedením změny a po ní prošel. Nechat na očích netestovaná kritéria, místo toho, abyste jeden úspěšný příkaz považovali za ověření celé změny.

Rozšiřující se soubor CLAUDE.md může obsahovat zastaralé příkazy, duplicitní pravidla a pokyny, které jsou v rozporu s požadavky konkrétních úkolů. Použití důraznější formulace tyto konflikty nevyřeší.

Porovnejte soubor s aktuálním repozitářem. Odstraňte zastaralé pokyny, vyjasněte si navzájem si odporující pravidla a přesuňte úzce použitelná pokyny do pravidel nebo dovedností s rozsahem platnosti na úrovni cesty. Pokud je třeba požadavek vynutit, nakonfigurujte a otestujte příslušné kontrolní mechanismy, místo abyste se spoléhali na opakovaná upozornění.

Revize může odhalit skutečné chyby, nejisté problémy i volitelné návrhy na refaktoring. Aplikace všech návrhů může změnu rozšířit, aniž by došlo ke zlepšení požadovaného chování.

Žádejte důkazy a informace o dopadu každého zjištění. Upřednostňujte problémy se správností a nesplněné požadavky, prověřujte nejisté tvrzení a vyřazujte nesouvisející vylepšení z aktuálního rozdílu. Recenzent by měl být schopen nahlásit, že neexistují žádná zjištění vyžadující opatření, pokud důkazy tento závěr podporují.

Chcete-li šablonu přizpůsobit, nahraďte v ní zástupné symboly údaji z vašeho projektu a před provedením změn se rozhodněte, co má Claude udělat. Pomocí těchto kroků připravte požadavek a zkontrolujte výsledek.

V případě malé, jasně definované změny můžete požádat Clauda, aby ji přímo implementoval. U neznámého kódu, změn zasahujících do několika souborů nebo nevyřešených požadavků začněte s plánem.

Stiskněte klávesy Shift+Tab, dokud se nezobrazí režim plánování, nebo spusťte Claude Code příkazem claude --permission-mode plan. V tomto režimu může Claude prohlížet soubory a spouštět příkazy pouze pro čtení, aniž by upravoval váš zdrojový kód. Před schválením implementace zkontrolujte navrhované soubory, závislosti a testy. Stisknutím kláves Ctrl+G otevřete navrhovaný plán ve svém editoru.

Poskytněte Claudovi podklady potřebné k pochopení úkolu: odkaz na soubor, očištěný protokol chyb, snímek obrazovky nebo dokument s požadavky. Chcete-li vložit obsah daného souboru, použijte znak @ následovaný cestou k souboru.

Vyberte nejmenší užitečnou sadu zdrojů. Zahrnutí celého protokolu nebo adresáře může přidat irelevantní materiál a zabírat kontext. Před sdílením protokolů odstraňte přihlašovací údaje a citlivá data a zkontrolujte, zda má Claude k dispozici nástroje potřebné k načtení všech URL adres dokumentace, které poskytnete.

Například příkaz `cat error.log | claude -p "Explain this error"` odešle protokol v rámci neinteraktivního požadavku. Používejte jej až po zkontrolování obsahu souboru. V tom spočívá praktická hodnota kontextové AI: poskytnutí relevantních informací modelu pro daný úkol.

Při přidávání nové funkce vyhledejte v repozitáři podobnou komponentu nebo funkci. Sdělte Claudovi, jaké konvence má dodržovat, například ohledně API klienta, validační logiky, zpracování chyb nebo struktury testů.

„Sledujte, jak soubor @src/widgets/Weather.tsx načítá a ukládá data do mezipaměti“ poskytuje Claudovi konkrétní vodítko. Uveďte také případné rozdíly, které nová funkce vyžaduje, aby se nekopírovalo chování, které již není vhodné. Tyto konvence by měly odrážet pracovní postupy vašeho týmu při vývoji softwaru.

V případě změn v kódu uveďte příslušný příkaz pro testování, sestavení nebo kontrolu kódu a chování, které by měl ověřit. Pro výzkumné účely požádejte o odkazy na soubory nebo ID commitů. Pro práci s uživatelským rozhraním poskytněte referenční obrázek a nakonfigurovaný způsob, jak zachytit implementaci ve stejném zobrazení.

Požádejte Clauda, aby vám nahlásil, co skutečně zkontroloval, včetně selhání a přeskočených kontrol. Zkontrolujte, zda důkazy pokrývají daný požadavek; úspěšná kompilace ještě neznamená, že funguje každé požadované chování.

Pro delší úkoly nabízí Claude Code také podmínku /goal a háčky Stop. Vyhodnocovač cílů posuzuje důkazy, které se objevily v konverzaci, namísto samostatné kontroly souborů nebo spouštění testů. Nakonfigurovaný háček Stop může zablokovat dokončení, má však omezení ohledně opakovaného blokování. Ani jedno z nich nenahrazuje odpovídající testy a lidskou kontrolu.

Pokud opakované opravy problém nevyřeší, zastavte se a zjistěte, co v původním požadavku nebylo jasné. Před vymazáním konverzace si uložte užitečné poznatky, aktuální stav v Git a zbývající práci.

Průvodce osvědčenými postupy společnosti Anthropic doporučuje začít od začátku po dvou neúspěšných opravách stejného problému. Použijte příkaz /clear a poté zadejte upravený příkaz, který zahrnuje to, co jste se naučili. Vymazání konverzace nezruší změny v souborech.

Stisknutím klávesy Esc přerušíte probíhající odpověď. Pokud je pole pro zadání příkazu prázdné, stiskněte dvakrát klávesu Esc, otevřete nabídku převinutí zpět a vyberte, co chcete obnovit. Převinutí zpět nezruší všechny externí účinky, proto pro změny v databázích nebo vzdálených službách používejte kontrolní body Git a samostatné postupy obnovy.

Uložte si pokyny pro celý projekt do souboru CLAUDE.md, opakovatelné postupy do dovedností a pokyny pro konkrétní soubory do pravidel s rozsahem na úrovni cesty. Používejte háčky pro akce vázané na konkrétní události, jako je spuštění formátovače po úpravě.

Vyberte si podle toho, kdy by se pokyn měl uplatnit:

Požadavek na jednu funkci obvykle patří do zadání úkolu nebo specifikace, nikoli do souboru CLAUDE.md. Přidávání dočasných pokynů do souboru platného pro celý projekt ztěžuje jejich odlišení od konvencí, které by měly platit v celém repozitáři.

Například uložte testovací příkaz projektu do souboru CLAUDE.md, umístěte konvence specifické pro jednotlivé komponenty do pravidla s rozsahem na cestu a uložte opakující se postup revize jako dovednost. Tyto soubory zkontrolujte, když dojde ke změně příkazů nebo konvencí, stejně jako byste to udělali u jiné projektové dokumentace.

Pokyny, soubor CLAUDE.md a průvodce dovednostmi určují chování Claude; nezaručují však, že bude daný pokyn splněn. Hooky mohou provádět kontroly při nakonfigurovaných událostech, ale jejich spolehlivost závisí na typu hooku a jeho implementaci.

Hook příkazu spouští skript. Hook výzvy nebo agenta se spoléhá na úsudek modelu. Jak vysvětluje průvodce osvědčenými postupy společnosti Anthropic: „Hook výzvy nebo agenta žádá jiný model o rozhodnutí, takže ani on není deterministický.“ U pravidla, které musí být vynuceno, použijte příslušné ovládací prvky oprávnění a otestujte příslušný hook příkazu nebo HTTP, včetně toho, jak zpracovává selhání.

Vlastní subagenti představují další způsob, jak organizovat opakující se úkoly. Pokud potřebujete specifickou revizní roli nebo rozsah nástrojů, definujte specialistu v adresáři in. claude/agents/, místo abyste každou instrukci pro specialistu přidávali do hlavní relace. Další kontext poskytují tyto průvodce nejvhodnějším modelem Claude pro práci a typy agentů AI.

Pokud váš tým spravuje podněty napříč několika produkty umělé inteligence, podívejte se na tyto nástroje pro tvorbu podnětů, které umožňují správu knihoven i mimo Claude Code.

Pokud relace vygeneruje neúplný nebo nevhodný výsledek, zkontrolujte, zda požadavek nezanechal nevyřešená důležitá rozhodnutí. Těchto pět chyb může zkomplikovat diagnostiku a revizi práce.

Pokyn „Prozkoumat repozitář“ dává Claudovi jen málo informací o tom, které soubory jsou důležité nebo kdy má přestat. Může se stát, že obdržíte obecné shrnutí bez odpovědi na problém, který vedl k zadání dotazu.

Pojmenujte chování nebo rozhodnutí, které potřebujete pochopit, určete výchozí bod a definujte očekávaný výstup. Například: „Sledujte, jak tento koncový bod kontroluje oprávnění, a uveďte příslušné funkce.“ Pokud používáte podagenty, zadejte každému z nich ohraničenou otázku, místo abyste jim delegovali stejné neomezené vyhledávání.

Při přepínání mezi funkcí, nesouvisející chybou a požadavkem na dokumentaci zůstává v konverzaci kontext, který se nemusí vztahovat k aktuálnímu úkolu. Odkazy jako „ten soubor“ nebo „předchozí přístup“ se stávají nejednoznačnými.

Pro nesouvisející práci používejte samostatné relace. Pokud bude repozitář upravovat více relací, použijte samostatné pracovní stromy Git, aby neupravovaly stejný pracovní adresář. Malá poznámka na okraj: příkaz /btw v Claude Code udržuje tuto výměnu mimo hlavní historii konverzace.

Sestavení může projít, i když se funkce chová nesprávně. Sada testů může projít, protože nikdy neprověřila vstup, který by způsobil selhání. Požádání Clauda o „spuštění testů“ nezjišťuje, který požadavek tyto testy ověřují.

Přiřaďte akceptační kritéria ke konkrétním kontrolám. Při opravě chyby požadujte důkaz, že test reprodukovatelnosti selhal před provedením změny a po ní prošel. Nechat na očích netestovaná kritéria, místo toho, abyste jeden úspěšný příkaz považovali za ověření celé změny.

Rozšiřující se soubor CLAUDE.md může obsahovat zastaralé příkazy, duplicitní pravidla a pokyny, které jsou v rozporu s požadavky konkrétních úkolů. Použití důraznější formulace tyto konflikty nevyřeší.

Porovnejte soubor s aktuálním repozitářem. Odstraňte zastaralé pokyny, vyjasněte si navzájem si odporující pravidla a přesuňte úzce použitelná pokyny do pravidel nebo dovedností s rozsahem platnosti na úrovni cesty. Pokud je třeba požadavek vynutit, nakonfigurujte a otestujte příslušné kontrolní mechanismy, místo abyste se spoléhali na opakovaná upozornění.

Revize může odhalit skutečné chyby, nejisté problémy i volitelné návrhy na refaktoring. Aplikace všech návrhů může změnu rozšířit, aniž by došlo ke zlepšení požadovaného chování.

Žádejte důkazy a informace o dopadu každého zjištění. Upřednostňujte problémy se správností a nesplněné požadavky, prověřujte nejisté tvrzení a vyřazujte nesouvisející vylepšení z aktuálního rozdílu. Recenzent by měl být schopen nahlásit, že neexistují žádná zjištění vyžadující opatření, pokud důkazy tento závěr podporují.

Chcete-li šablonu přizpůsobit, nahraďte v ní zástupné symboly údaji z vašeho projektu a před provedením změn se rozhodněte, co má Claude udělat. Pomocí těchto kroků připravte požadavek a zkontrolujte výsledek.

V případě malé, jasně definované změny můžete požádat Clauda, aby ji přímo implementoval. U neznámého kódu, změn zasahujících do několika souborů nebo nevyřešených požadavků začněte s plánem.

Stiskněte klávesy Shift+Tab, dokud se nezobrazí režim plánování, nebo spusťte Claude Code příkazem claude --permission-mode plan. V tomto režimu může Claude prohlížet soubory a spouštět příkazy pouze pro čtení, aniž by upravoval váš zdrojový kód. Před schválením implementace zkontrolujte navrhované soubory, závislosti a testy. Stisknutím kláves Ctrl+G otevřete navrhovaný plán ve svém editoru.

Poskytněte Claudovi podklady potřebné k pochopení úkolu: odkaz na soubor, očištěný protokol chyb, snímek obrazovky nebo dokument s požadavky. Chcete-li vložit obsah daného souboru, použijte znak @ následovaný cestou k souboru.

Vyberte nejmenší užitečnou sadu zdrojů. Zahrnutí celého protokolu nebo adresáře může přidat irelevantní materiál a zabírat kontext. Před sdílením protokolů odstraňte přihlašovací údaje a citlivá data a zkontrolujte, zda má Claude k dispozici nástroje potřebné k načtení všech URL adres dokumentace, které poskytnete.

Například příkaz `cat error.log | claude -p "Explain this error"` odešle protokol s neinteraktivním požadavkem. Použijte jej až po zkontrolování obsahu souboru. V tom spočívá praktická hodnota kontextové AI: poskytnutí modelu relevantních informací pro daný úkol.

Při přidávání nové funkce vyhledejte v repozitáři podobnou komponentu nebo funkci. Sdělte Claudovi, jaké konvence má dodržovat, například ohledně API klienta, validační logiky, zpracování chyb nebo struktury testů.

„Sledujte, jak soubor @src/widgets/Weather.tsx načítá a ukládá data do mezipaměti“ poskytuje Claudovi konkrétní vodítko. Uveďte také případné rozdíly, které nová funkce vyžaduje, aby se nekopírovalo chování, které již není vhodné. Tyto konvence by měly odrážet pracovní postupy vašeho týmu při vývoji softwaru.

V případě změn v kódu uveďte příslušný příkaz pro testování, sestavení nebo kontrolu kódu a chování, které by měl ověřit. Pro výzkumné účely požádejte o odkazy na soubory nebo ID commitů. Pro práci s uživatelským rozhraním poskytněte referenční obrázek a nakonfigurovaný způsob, jak zachytit implementaci ve stejném zobrazení.

Požádejte Clauda, aby vám nahlásil, co skutečně zkontroloval, včetně selhání a přeskočených kontrol. Zkontrolujte, zda důkazy pokrývají daný požadavek; úspěšná kompilace ještě neznamená, že funguje každé požadované chování.

Pro delší úkoly nabízí Claude Code také podmínku /goal a háčky Stop. Vyhodnocovač cílů posuzuje důkazy, které se objevily v konverzaci, namísto samostatné kontroly souborů nebo spouštění testů. Nakonfigurovaný háček Stop může zablokovat dokončení, má však omezení ohledně opakovaného blokování. Ani jedno z nich nenahrazuje odpovídající testy a lidskou kontrolu.

Pokud opakované opravy problém nevyřeší, zastavte se a zjistěte, co v původním požadavku nebylo jasné. Před vymazáním konverzace si uložte užitečné poznatky, aktuální stav v Git a zbývající práci.

Průvodce osvědčenými postupy společnosti Anthropic doporučuje začít od začátku po dvou neúspěšných opravách stejného problému. Použijte příkaz /clear a poté zadejte upravený příkaz, který zahrnuje to, co jste se naučili. Vymazání konverzace nezruší změny v souborech.

Stisknutím klávesy Esc přerušíte probíhající odpověď. Pokud je pole pro zadání příkazu prázdné, stiskněte dvakrát klávesu Esc, otevřete nabídku převinutí zpět a vyberte, co chcete obnovit. Převinutí zpět nezruší všechny externí účinky, proto pro změny v databázích nebo vzdálených službách používejte kontrolní body Git a samostatné postupy obnovy.

Ukládejte pokyny pro celý projekt do souboru CLAUDE.md, opakovatelné postupy do dovedností a pokyny pro konkrétní soubory do pravidel s rozsahem na úrovni cesty. Používejte háčky pro akce vázané na konkrétní události, jako je spuštění formátovače po úpravě.

Vyberte si podle toho, kdy by se pokyn měl uplatnit:

Požadavek na jednu funkci obvykle patří do zadání úkolu nebo specifikace, nikoli do souboru CLAUDE.md. Přidávání dočasných pokynů do souboru platného pro celý projekt ztěžuje jejich odlišení od konvencí, které by měly platit v celém repozitáři.

Například uložte testovací příkaz projektu do souboru CLAUDE.md, umístěte konvence specifické pro jednotlivé komponenty do pravidla s rozsahem platnosti v cestě a uložte opakující se postup revize jako dovednost. Tyto soubory zkontrolujte, když dojde ke změně příkazů nebo konvencí, stejně jako byste to udělali u jiné projektové dokumentace.

Pokyny, soubor CLAUDE.md a průvodce dovednostmi určují chování Claude; nezaručují však, že bude daný pokyn splněn. Hooky mohou provádět kontroly při nakonfigurovaných událostech, ale jejich spolehlivost závisí na typu hooku a jeho implementaci.

Hook příkazu spouští skript. Hook výzvy nebo agenta se spoléhá na úsudek modelu. Jak vysvětluje průvodce osvědčenými postupy společnosti Anthropic: „Hook výzvy nebo agenta žádá jiný model o rozhodnutí, takže ani on není deterministický.“ U pravidla, které musí být vynuceno, použijte příslušné ovládací prvky oprávnění a otestujte příslušný hook příkazu nebo HTTP, včetně toho, jak zpracovává selhání.

Vlastní subagenti představují další způsob, jak organizovat opakující se úkoly. Pokud potřebujete specifickou revizní roli nebo rozsah nástrojů, definujte specialistu v adresáři in. claude/agents/, místo abyste každou instrukci pro specialistu přidávali do hlavní relace. Další kontext poskytují tyto průvodce nejvhodnějším modelem Claude pro práci a typy agentů AI.

Pokud váš tým spravuje podněty napříč několika produkty umělé inteligence, podívejte se na tyto nástroje pro tvorbu podnětů, které umožňují správu knihoven i mimo Claude Code.

Pokud relace vygeneruje neúplný nebo nevhodný výsledek, zkontrolujte, zda požadavek nezanechal nevyřešená důležitá rozhodnutí. Těchto pět chyb může zkomplikovat diagnostiku a revizi práce.

Pokyn „Prozkoumat repozitář“ dává Claudovi jen málo informací o tom, které soubory jsou důležité nebo kdy má přestat. Může se stát, že obdržíte obecné shrnutí bez odpovědi na problém, který vedl k zadání dotazu.

Pojmenujte chování nebo rozhodnutí, které potřebujete pochopit, určete výchozí bod a definujte očekávaný výstup. Například: „Sledujte, jak tento koncový bod kontroluje oprávnění, a uveďte příslušné funkce.“ Pokud používáte podagenty, zadejte každému z nich ohraničenou otázku, místo abyste jim delegovali stejné neomezené vyhledávání.

Při přepínání mezi funkcí, nesouvisející chybou a požadavkem na dokumentaci zůstává v konverzaci kontext, který se nemusí vztahovat k aktuálnímu úkolu. Odkazy jako „ten soubor“ nebo „předchozí přístup“ se stávají nejednoznačnými.

Pro nesouvisející práci používejte samostatné relace. Pokud bude repozitář upravovat více relací, použijte samostatné pracovní stromy Git, aby neupravovaly stejný pracovní adresář. Krátká poznámka na okraj: příkaz /btw v Claude Code udržuje tuto výměnu mimo hlavní historii konverzace.

Sestavení může projít, i když se funkce chová nesprávně. Sada testů může projít, protože nikdy neprověřila vstup, který by způsobil selhání. Požádání Clauda o „spuštění testů“ nezjišťuje, který požadavek tyto testy ověřují.

Přiřaďte akceptační kritéria ke konkrétním kontrolám. Při opravě chyby požadujte důkaz, že test reprodukovatelnosti selhal před provedením změny a po ní prošel. Nechat na očích netestovaná kritéria, místo toho, abyste jeden úspěšný příkaz považovali za ověření celé změny.

Rozšiřující se soubor CLAUDE.md může obsahovat zastaralé příkazy, duplicitní pravidla a pokyny, které jsou v rozporu s požadavky konkrétních úkolů. Použití důraznějšího znění tyto konflikty nevyřeší.

Porovnejte soubor s aktuálním repozitářem. Odstraňte zastaralé pokyny, vyjasněte si navzájem si odporující pravidla a přesuňte úzce použitelná pokyny do pravidel nebo dovedností s rozsahem platnosti na úrovni cesty. Pokud je třeba požadavek vynutit, nakonfigurujte a otestujte příslušné kontrolní mechanismy, místo abyste se spoléhali na opakovaná upozornění.

Revize může odhalit skutečné chyby, nejisté problémy i volitelné návrhy na refaktoring. Aplikace všech návrhů může změnu rozšířit, aniž by došlo ke zlepšení požadovaného chování.

Žádejte důkazy a informace o dopadu každého zjištění. Upřednostňujte problémy se správností a nesplněné požadavky, prověřujte nejisté tvrzení a vyřazujte nesouvisející vylepšení z aktuálního rozdílu. Recenzent by měl být schopen nahlásit, že neexistují žádná zjištění vyžadující opatření, pokud důkazy tento závěr podporují.