Claude Code-utasítások: 25 másolásra kész utasítás és útmutató a saját utasítások írásához

A lejárt kupont használó ügyfelek 500-as hibakódot kapnak a fizetés során. Vizsgálja meg az @src/checkout/coupons.ts fájlt és a hozzá tartozó teszteket. A várt viselkedés egy „érvénytelen kupon” üzenet megjelenése a megrendelés létrehozása nélkül. Írjon egy sikertelen tesztet, amely reprodukálja a hibát, majd javítsa ki anélkül, hogy megváltoztatná az érvényes kuponok viselkedését. Futtassa a [checkout test parancsot], és mutassa be az eredményeket a javítás előtt és után. Ha nem tudja reprodukálni a hibát, jelentse, mit ellenőrizte, mielőtt módosította volna az implementációt.

Adjon hozzá egy dátumválasztót a [foglalási űrlap elérési útjához]. Kövesse a @src/components/TimeSelect.tsx fájlban található komponens- és érvényesítési konvenciókat. A felhasználóknak lehetőségük kell legyen a [megengedett dátumok] kiválasztására, míg a [nem elérhető dátumok] továbbra is letiltva maradnak. Ne adjon hozzá könyvtárakat. Futtassa a [komponens teszt parancsot] és a [típusellenőrző parancsot], és jelentsen minden olyan kritériumot, amelyet ezek az ellenőrzések nem fednek le.

Oszd fel az @src/reports/export.py fájlt kisebb függvényekre úgy, hogy megőrizd a bemeneteit, a kimeneti formátumot és a hiba kezelését. A szerkesztés előtt futtasd le az [export test command] parancsot, és jelentsd be az esetleges hibákat. Az átalakítás után futtasd le újra a teszteket, és mutasd be mindkét eredményt. Ne módosítsd a nyilvános felületet vagy a nem kapcsolódó fájlokat.

„A Claude a Claude Chrome-bővítmény segítségével minden egyes változtatást tesztel, amit az claude.ai/code oldalra feltöltök. Megnyit egy böngészőt, teszteli a felhasználói felületet, és addig ismételgeti a folyamatot, amíg a kód működik és a felhasználói élmény kellemesnek tűnik. ”

Vizsgálja meg a README fájlt, a projektkonfigurációt és a tárház legfelső szintű könyvtárszerkezetét. Csak annyira hivatkozzon a forrásokra, amennyire az a következőket magyarázni szükséges: mit csinál az alkalmazás; melyek a fő belépési pontjai és főbb összetevői; hol találhatók a tesztek, és mely parancsokat határozza meg a tárház azok futtatásához. Hivatkozzon a magyarázatát alátámasztó fájlútvonalakra. Különítse el a dokumentált viselkedést a saját következtetéseitől, és jelölje meg mindazt, amit nem tud megállapítani. Ne olvassa el a titkos vagy környezeti fájlokat, ne vizsgálja meg a telepített függőségeket, és ne módosítson semmilyen fájlt. Zárásként sorolja fel azt a három fájlt, amelyet először el kellene olvasnom, és indokolja meg, miért.

Tekintse át a [fájl, függvény vagy osztály] Git-előzményeit, különös figyelmet fordítva a [viselkedésre vagy tervezési kérdésre]. Azonosítsa azokat a commitokat, amelyek bevezették vagy jelentősen megváltoztatták ezt a viselkedést. Minden releváns commit esetében adja meg annak hash-értékét, foglalja össze a változást, és magyarázza el a commit üzenetben vagy a hozzáférhető kapcsolódó beszélgetésben dokumentált indokokat. A következtetett okokat jelölje meg „következtetésként”. Ha az előzmények nem magyarázzák a döntést, jelezze ezt. Ne módosítsa a fájlokat vagy a Git-előzményeket.

Kövesse nyomon, mi történik, amikor [felhasználói művelet vagy rendszeresemény] bekövetkezik, [ismert útvonal, kezelő vagy mappa] kiindulási ponttól kezdve. Kövesse nyomon a releváns hívásokat az érvényesítésen, az üzleti logikán, valamint az esetleges adatbázis-írásokon és külső kéréseken keresztül. Sorolja fel a fájlokat és függvényeket végrehajtási sorrendben, amennyiben lehetséges, sorhivatkozásokkal együtt. Magyarázza el a főbb hibaútvonalakat, és azonosítsa a folyamatot lefedő meglévő teszteket. Jelölje meg azokat a kapcsolatokat, amelyeket a kódból nem tud megerősíteni. Ne hajtsa végre a folyamatot, ne hívjon meg külső szolgáltatásokat, és ne szerkesszen fájlokat.

Tervezd meg, hogyan valósítsd meg a [funkciót] a [repozitórium területén]. A várt viselkedés a következő: [követelmények], és ezek a területek változatlanok maradnak: [korlátozások]. Vizsgáld át a vonatkozó kódot és a meglévő teszteket. Határozd meg a módosítandó fájlokat, a megvalósítás sorrendjét, valamint az esetleges kompatibilitási vagy adatmigrációs kockázatokat. Rendeld hozzá az egyes követelményeket egy javasolt teszthez vagy más ellenőrzési lépéshez. A megoldatlan kérdéseket és feltételezéseket külön sorold fel. Még ne valósítsa meg a funkciót. Küldje vissza a tervet, hogy átnézzem.

[Felhasználók és felhasználási eset] számára szeretnék létrehozni egy [rövid leírás] alkalmazást. Először olvassa el a [vonatkozó fájlokat vagy követelményeket], majd az AskUserQuestion segítségével tisztázza azokat a döntéseket, amelyek lényegesen befolyásolhatják a megvalósítást. Fókuszáljon a szélsőséges esetekre, az adatkezelésre, a jogosultságokra, a várt felhasználói felületi viselkedésre és a kompromisszumokra. Ne tegyen fel olyan kérdéseket, amelyekre a megadott kontextus már választ ad. Miután a legfontosabb döntések megszülettek, készítsen egy specifikációt, amely tartalmazza a követelményeket, az átvételi kritériumokat, a korlátozásokat és azt, hogy mi nem tartozik a hatály alá. Jelölje meg az esetleges fennmaradó feltételezéseket. Mutassa meg nekem a specifikációt, mielőtt elmenti a [specifikáció elérési útja] helyre, és ne írja felül a meglévő fájlt jóváhagyás nélkül.

Mérje fel, milyen hatással jár, ha a [függvényt, komponenst vagy interfészt] a [jelenlegi viselkedésről] a [javasolt viselkedésre] változtatja. Keresse meg a [repozitórium vagy könyvtár hatókörében] annak definícióját, közvetlen hívóit, importjait és a kapcsolódó teszteket. Sorolja fel azokat a fájlokat, amelyeknél valószínűleg módosításokra lesz szükség, és magyarázza el, hogy azok hogyan érinthetők, amennyiben lehetséges, fájl- és sorhivatkozásokkal. Jelölje meg a dinamikusan feloldott hívásokat, a külső felhasználókat vagy más olyan függőségeket, amelyeket nem tud ellenőrizni. Azonosítsa azokat a kompatibilitási kérdéseket, amelyekre a megvalósítás előtt választ kell adni. Ne módosítsa a fájlokat; küldje el a hatáselemzést, és várja meg az én áttekintésemet.

Adja hozzá a [funkciót] a [fájlhoz vagy oldalhoz] a következő viselkedéssel: [elfogadási kritériumok]. Vizsgálja meg a [meglévő megvalósítást], és kövesse annak konvencióit az adatok lekérésére, a hibakezelésre és a komponensek szervezésére vonatkozóan. Csak a projektbe már telepített könyvtárakat használja. Tartsa a változtatásokat a [határon] belül, és őrizze meg a [meglévő viselkedést vagy nyilvános felületet]. Adjon hozzá vagy frissítsen teszteket az elfogadási kritériumokhoz. Futtassa a [tesztparancsot] és a [típusellenőrző vagy lint parancsot], majd jelentse a megváltozott fájlokat, az eredményeket és az összes olyan ellenőrzést, amelyet nem tudott végrehajtani. Ha a meglévő minta ütközik egy követelménnyel, magyarázza el az ütközést, mielőtt továbbhaladna.

Végrehajtja a [függvény neve] függvényt a [fájl] fájlban a [követelmények] teljesítése érdekében. Foglalja le a [normál eset], a [határ eset] és az [érvénytelen bemeneti viselkedés] eseteket. Először futtassa le a [vonatkozó tesztparancsot], és jelentse az esetleges hibákat. Írjon teszteket a kért viselkedéshez, majd futtassa le őket a megvalósítás előtt. Győződjön meg arról, hogy az új tesztek a várt okból buknak meg. Végrehajtja a függvényt, majd futtassa le újra a teszteket. Ne gyengítse az állításokat, ne hagyjon ki teszteket, és ne módosítsa a várt viselkedést csak azért, hogy a tesztek sikeresek legyenek. Ha a követelmények ütköznek a meglévő tesztekkel, álljon meg, és magyarázza el az ütközést. Mutassa be az „előtte” és „utána” eredményeket.

Végrehajtja a mellékelt tervet a [komponensben vagy oldalon], a projekt meglévő komponenseinek és stílusainak felhasználásával. Megőrzi a [szükséges viselkedést], és elkerüli a [határon] kívüli változtatásokat. Használja a [beállított böngészőt vagy képernyőkép-készítő eszközt] a [helyi útvonal] rögzítéséhez a [nézőtér méreteinél], a [tesztadatokkal és a felhasználói felület állapotával] együtt. Ha az eszköz vagy az alkalmazás nem áll rendelkezésre, jelentse be, mire van szükség, ahelyett, hogy vizuális ellenőrzést igényelne. Hasonlítsa össze a rögzített képet a referenciaképpel, különös figyelmet fordítva az [elrendezésre, térközökre, tipográfiára vagy egyéb elfogadási kritériumokra]. Végezzen legfeljebb [szám] javítási köröket, majd jelentse a fennmaradó eltéréseket. Ne módosítsa a referenciaképet. Futtassa a [vonatkozó komponens teszteket] és a [típusellenőrzést vagy a build parancsot]. Foglalja bele az összefoglalójába a rögzített képernyőképet és a tényleges ellenőrzési eredményeket.

A felhasználók [tünetet] tapasztalnak, amikor [kiváltó ok vagy bemenet] történik. A várt viselkedés [várt eredmény]. Kezdje azzal, hogy megvizsgálja a [mappát, függvényt vagy folyamatot] és a kapcsolódó teszteket. Hozzon létre egy sikertelen tesztet, amely reprodukálja a jelentett viselkedést. Ha nem tudja reprodukálni, magyarázza el, mit ellenőrizte és milyen információk hiányoznak, mielőtt módosítaná a megvalósítást. A reprodukálás után javítsa ki az okot anélkül, hogy megváltoztatná a [megmaradnia kellő viselkedést]. Futtassa az új tesztet és a [kapcsolódó tesztparancsot]. Mutassa be a javítás előtti hibát, az azt követő eredményeket és az esetleges fennmaradó hibákat.

A [Build parancs] hibaüzenettel bukik meg a [helyi vagy CI környezetben], a következő kimenettel: [tisztított hibanapló]. Vizsgálja meg a vonatkozó kódot és konfigurációt az ok azonosítása érdekében. Ha a hiba helyileg nem reprodukálható, ellenőrizze a környezeti vagy függőségi eltéréseket. Végezze el a legkisebb változtatást, amely megoldja a problémát. Ne tiltsa le az ellenőrzéseket, ne szűrje ki a hibákat, ne hagyjon ki teszteket, és ne lazítsa meg a fordító beállításait pusztán azért, hogy a build sikeres legyen. A módosítás után futtassa újra a buildet. Ha [szám] javítási kísérlet után is sikertelen marad, álljon le, és jelentse be, mit próbált ki, mi a jelenlegi hiba, és mi a következő diagnosztikai lépés. Foglalja össze az okot, és csatolja a tényleges build eredményét.

Segítsen leszűkíteni a hiba körét, mielőtt javítást javasolna. Megfigyelt viselkedés: [mi történik] Várt viselkedés: [mi kellene történnie] Mikor fordul elő: [feltételek vagy gyakoriság] Mit próbáltam már: [lépések és eredmények] Egyszerre csak egy kérdést tegyen fel, és válassza ki azt a kérdést, amely a legjobban megkülönbözteti a lehetséges okokat. Ne ismételje meg azokat a kérdéseket, amelyekre a megadott információk már választ adnak. Ha elegendő bizonyíték áll rendelkezésre, foglalja össze a legvalószínűbb magyarázatot, a még bizonytalan elemeket, valamint azt a legkisebb tesztet, amely megerősítheti vagy kizárhatja azt. Egyelőre ne szerkesszen fájlokat.

Használjon alügynököt a [bázishoz viszonyított diff vagy ág] és a [jóváhagyott terv vagy követelményfájl] összehasonlításához. Ha a követelmények hiányoznak vagy nem egyértelműek, jelentsen erről még a teljesség értékelése előtt. Ellenőrizze, hogy minden követelmény megvalósult-e, a releváns szélsőséges esetek rendelkeznek-e tesztekkel, és hogy a változtatások nem esnek-e a megállapodott határon kívül. Szükség esetén vizsgálja meg a környező kódot a diff megértése érdekében. Jelentse a helyességi problémákat és a nem teljesített követelményeket fájl- és sorhivatkozásokkal, azok hatásával és az egyes megállapításokat alátámasztó bizonyítékokkal együtt. Válassza szét a megerősített problémákat a megoldatlan kérdésektől. Ne találjon ki megállapításokat a kvóta kitöltése érdekében, és ne vegyen fel nem kapcsolódó stílusbeli preferenciákat. Ne szerkessze a fájlokat.

Ellenőrizze a [fájlokat vagy diff-eket] behatolási kockázatok, hiányzó jogosultsági ellenőrzések, nyilvánosságra került titkos adatok és a felhasználói bevitel nem biztonságos kezelése szempontjából. Mielőtt jelentést készítene egy észlelésről, vizsgálja meg a vonatkozó hívókat és az érvényesítési logikát. Minden egyes probléma esetében azonosítsa az érintett fájlt és sorokat, a probléma kiváltásához szükséges feltételeket, a várható hatást és a javasolt javítást. Különbséget kell tenni a megerősített sebezhető útvonal és a további tesztelést igénylő aggály között. Ne tüntesse fel a titkos értékeket a jelentésben, ne módosítsa a fájlokat, és ne végezzen tesztelést éles szolgáltatásokon. Adja meg, mely területeket vizsgálta át, és mi maradt a vizsgálat hatókörén kívül.

Összegezze, hogyan ellenőrizte a végrehajtott változtatást az [elfogadási kritériumok] alapján. Minden kritériumhoz sorolja fel az elvégzett ellenőrzést, adott esetben a pontos parancsot és a megfigyelt eredményt. Mellékelje a releváns kimenetet, a titkos és érzékeny adatok elrejtésével. A már korábban fennálló hibákat külön jelölje meg. Világosan különböztesse meg a sikeres, a sikertelen és a le nem futtatott ellenőrzéseket. Magyarázza el az esetleges kihagyott ellenőrzéseket vagy a lefedettség korlátait. Ne írja le a teljes változtatást ellenőrzöttként, ha egyes kritériumok ellenőrzése elmaradt.

Átírja a [fájlt vagy modult] egy [konkrét cél, például egy nagy függvény felosztása vagy a beágyazott visszahívások eltávolítása] érdekében. Megőrzi annak nyilvános felületét, visszatérési értékeit, hiba kezelését és mellékhatásait. A szerkesztés előtt futtassa le a [vonatkozó tesztparancsot] az alapállapot rögzítése érdekében. Ha a teszt sikertelen, jelentse a hibákat, mielőtt továbbhaladna. Azonosítsa azokat a viselkedéseket, amelyeket a meglévő tesztek nem fednek le, és szükség szerint adjon hozzá célzott teszteket. Végezze el az átírást úgy, hogy ne legyenek benne nem kapcsolódó változtatások vagy új függőségek. Ne gyengítse a meglévő állításokat az implementációhoz való igazodás érdekében. Futtassa újra a teszteket és a [típusellenőrző vagy lint parancsot]. Mutassa be az átalakítás előtti és utáni eredményeket, foglalja össze a szerkezeti változásokat, és jelölje meg azokat a viselkedéseket, amelyeket nem tudott ellenőrizni.

Keresse meg az [régi API vagy könyvtár] használatait a [könyvtár hatókörén] belül, a generált és a beszállítói fájlok kizárásával. Sorolja fel az érintett fájlokat, valamint az összes olyan megosztott konfigurációt vagy függőséget, amelyet az áttérés érinthet. Javasoljon három reprezentatív fájlt egy kísérleti áttéréshez az [új API-ra vagy verzióra], az [áttérési útmutató vagy meglévő példa] felhasználásával. Magyarázza el, miért választotta ki őket, és jelölje meg az esetleges szükséges viselkedésbeli változásokat. A szerkesztés előtt várja meg a jóváhagyásomat. A jóváhagyás után csak a kísérleti fájlokat és a kifejezetten jóváhagyott megosztott függőségeket migrálja. Futtassa a [vonatkozó teszteket] és a [build vagy típusellenőrző parancsot]. Ne terjessze ki a migrációt más fájlokra. Jelentse a különbségeket, a teszt eredményeket, a kompatibilitási problémákat és a migrációs megközelítésben szükséges változtatásokat. A többi fájl feldolgozása előtt álljon meg felülvizsgálatra.

Vizsgáld meg az aktuális ágat, a Git állapotát és a [funkció vagy javítás] diffjét. Azonosítsd a változáshoz tartozó fájlokat, és külön sorold fel a nem kapcsolódó vagy nyomon nem követett fájlokat. Írj egy commit üzenetet az utolsó 10 commit formátumát követve. Készíts egy pull request leírást, amely tartalmazza, mi változott, miért, milyen teszteket futtattál le, és milyen korlátozások maradtak fenn. Mielőtt bármit is staging-be helyeznél vagy közzétennél, mutasd meg a javasolt fájllistát, a commit üzenetet és a PR leírást. Várd meg a jóváhagyásomat. A jóváhagyás után csak a megegyezés szerinti fájlokat helyezd staging-be, hajts végre commit-ot a [feature branch]-en, push-old a [remote]-ra, és nyiss pull request-et a [base branch]-re. Ne módosíts meglévő commit-okat, ne hajts végre force-push-t és ne végez összevonást. Küldd vissza a commit hash-t és a PR linket.

Írjon egy README-szakaszt a [modul]hoz, amelynek célközönsége [olvasó, például a projekthez csatlakozó háttérfejlesztő]. Foglalja össze az előfeltételeket, a beállítást, a három leggyakrabban használt parancsot, valamint a kód vagy a meglévő dokumentáció által támogatott gyakori hibákat. Ellenőrizze a parancsneveket és az opciókat a [csomag szkriptek, a Makefile, a CLI súgó vagy a CI konfiguráció] alapján. Jelölje meg mindazt, amit nem tud megerősíteni. Tesztelje a biztonságos helyi parancsokat a [tesztkörnyezetben], amennyiben rendelkezésre áll. Mielőtt olyan parancsokat futtatna, amelyek függőségeket telepítenek, fájlokat törölnek, adatokat migrálnak, telepítenek vagy külső szolgáltatásokhoz férnek hozzá, magyarázza el azok hatásait, és kérjen jóváhagyást. Világosan különböztesse meg a sikeresen futtatott parancsokat azoktól, amelyeket csak a konfiguráció vagy a dokumentáció alapján ellenőrzött. Mutassa meg a javasolt README-szakaszt a [dokumentáció elérési útja] szerkesztése előtt, és őrizze meg a nem kapcsolódó tartalmakat.

Vizsgálja át a [CLAUDE.md elérési útja] fájlt a repository jelenlegi felépítése, szkriptjei és konvenciói alapján. Egyelőre ne szerkessze a fájlt! Azonosítsa az elavult utasításokat, az ismétlődéseket, az ellentmondásokat, valamint azokat a szabályokat, amelyek megbízhatóan levezethetők a kódból. Indokolja meg az egyes törlési javaslatokat, ne csak azért távolítson el utasításokat, hogy lerövidítse a fájlt. Hiányzó build- vagy tesztparancsokat csak akkor javasoljon, ha azokat a projekt szkriptjeiben, egy Makefile-ban, a CI-konfigurációban vagy a meglévő dokumentációban ellenőrizni tudja. Minden hozzáadásnál hivatkozz a forrásra. Küldj be egy olyan diff-javaslatot, amely megőrzi a fontos projektkorlátozásokat. Jelöld meg azokat a feladatspecifikus utasításokat, amelyek jobban illeszkednének egy skillbe vagy path-hatókörű szabályba, és várd meg a jóváhagyást, mielőtt alkalmaznád a változtatásokat.

Javasoljon egy Claude Code parancs-hookot, amely az [fájlminta] szerkesztése vagy írása utáni változások esetén futtatja a [meglévő formázóparancsot]. Először vizsgálja meg a claude/settings.json fájlban található meglévő konfigurációt és a formázó beállításait. Használja a telepített Claude Code verzióhoz megfelelő PostToolUse konfigurációt. Csak az érintett fájlt formázza, kezelje biztonságosan az elérési utakat, és zárja ki a [generált fájlokat vagy más kizárt elérési utakat]. Ne telepítsen függőségeket, és ne cserélje ki a meglévő hookokat. Mutassa be a javasolt beállítások közötti különbségeket, és magyarázza el, hogyan kerülnek jelentésre a formázó hibái. Várja meg a jóváhagyást, mielőtt alkalmazná. A jóváhagyás után tesztelje egy ideiglenes fájllal a projektben, és jelentse az eredményt. Adja meg, mely szerkesztési útvonalakat fedi le, és melyeket nem, beleértve a shell-parancsokkal végzett módosításokat is.

Nézze át a [szerszám] –help parancsot és a [feladat] szempontjából releváns alparancsok súgóját. Ne telepítse a szerszámot, ha hiányzik; ehelyett jelentsen be az előfeltételt. Javasolja a feladat elvégzéséhez szükséges pontos parancsokat. Magyarázza el azok bemeneteit, kimeneteit, valamint azt, hogy írnak-e fájlokat, módosítanak-e távoli erőforrásokat, vagy használnak-e hitelesítő adatokat. Ha az eszköz dokumentációja tartalmaz ilyen opciót, vegye fel a próbafutás opciót is. Jelölje meg a hiányzó konfigurációkat vagy jogosultságokat, és kérjen pontosítást, ahelyett, hogy találgatna az erőforrásnevekről vagy a célhelyekről. Várja meg a jóváhagyást, mielőtt futtatná a feladatparancsokat. A jóváhagyás után csak a megegyezés szerinti parancsokat futtassa, és jelentse azok tényleges eredményeit, beleértve az esetleges hibákat vagy a befejezetlen lépéseket is.

Hasonlítsa össze a [invoices.csv] és a [payments.csv] fájlokat a [számlaazonosító vagy egyező kulcs] segítségével. Ne módosítsa a forrásfájlokat. Alkalmazza a következő szabályokat: [pénznem és kerekítési tűrés], [részleges befizetések elosztása] és [visszatérítések, jóváírások és túlfizetések kezelése]. Ha hiányzik egy szabály, vagy az egyezés nem egyértelmű, jelölje meg, ahelyett, hogy automatikusan hozzárendelné a befizetést. Tartsa meg a forrás sorok azonosítóit. Minden számla esetében mutassa meg a számlázott összeget, a jóváírt befizetéseket és a fennmaradó egyenleget. Jelentsd az ismétlődő azonosítókat, az egyezés nélküli számlákat, az egyezés nélküli befizetéseket és a tűréshatáron kívüli egyenlegeket. A számla- és befizetési összegeket külön egyeztesd. Minden forrássorral számolj el anélkül, hogy kétszer számolnád; ha egy befizetés több számlára oszlik, mutasd be az egyes allokációkat, és ellenőrizd, hogy azok összege nem haladja-e meg a befizetés összegét. Írd az eredményeket az [új kimeneti útvonalakra], és foglald össze a felülvizsgálatot igénylő kivételeket.

Írjon egy szkriptet, amely összefoglalja az [export.csv] fájlt a [kezdő dátum és idő (beleértve)] és a [záró dátum és idő (kizárva)] közötti időszakra, a [időzóna] és a [dátum oszlop] felhasználásával. Csoportosítsa a rekordokat a [kategória szabályok] szerint, és számítsa ki a [szükséges mutatókat]. Kezelje az ismétlődő azonosítókat és a hiányzó értékeket a [szabályok] szerint. Ne módosítsa a bemeneti fájlt! Futtassa a szkriptet a [pontos bemeneti fájlon]! Jelentse a felvett és kizárt sorok számát, a kategóriák összegét, valamint azokat a rekordokat, amelyeket nem lehetett besorolni! Hasonlítsa össze a [három kategória] eredményeit a [referenciafájlban] található, függetlenül ellenőrzött számadatokkal! Ha ezek a számadatok nem állnak rendelkezésre, jelezze, hogy a független érvényesítés még nem történt meg! Mutassa be az eltéréseket, és mentse a jelentést az [új kimeneti útvonalra]!

Olvassa el a [megadott fájlokat vagy mappát], és készítsen [dokumentumtípus és hossz] tervezetet a [célközönség] számára, amely kitér a [kérdésekre vagy témákra]. Minden ténybeli állítást támasztaljon alá fájlnévvel, valamint oldal-, szakasz- vagy sorhivatkozással, amennyiben rendelkezésre áll. Különböztesse meg a közvetlen idézeteket a parafrázisoktól, és ne kezelje a javaslatokat vagy elavult dokumentumokat megerősített, aktuális döntésként. Jelölje meg az egymásnak ellentmondó forrásokat, a hiányzó információkat és azokat az állításokat, amelyeket nem tud ellenőrizni. Ne pótolja a hiányzó információkat feltételezésekkel, és ne szerkessze a forrásfájlokat. Adja vissza a vázlatot a hivatkozásokkal és a lektor számára egy rövid listával a megoldatlan kérdésekről.

A sablon testreszabásához cserélje ki a helyőrzőket a projekt adataival, és döntse el, mit kell tennie a Claude-nak, mielőtt módosításokat hajtana végre. Kövesse ezeket a lépéseket a kérés előkészítéséhez és az eredmény ellenőrzéséhez.

Egy kis, jól meghatározott változtatás esetén megkérheted Claude-ot, hogy közvetlenül hajtsa végre azt. Ismeretlen kód, több fájlt érintő változtatások vagy tisztázatlan követelmények esetén kezdj egy tervvel!

Nyomja meg a Shift+Tab billentyűkombinációt, amíg meg nem jelenik a Tervezési mód, vagy indítsa el a Claude Code-ot a claude --permission-mode plan paranccsal. Ebben a módban a Claude átvizsgálhatja a fájlokat és olvasási joggal rendelkező parancsokat futtathat anélkül, hogy szerkesztené a forráskódot. Tekintse át a javasolt fájlokat, függőségeket és teszteket, mielőtt jóváhagyná a megvalósítást. Nyomja meg a Ctrl+G billentyűkombinációt a javasolt terv megnyitásához a szerkesztőjében.

Adja meg Claude-nak a feladat megértéséhez szükséges információkat: fájlhivatkozást, megtisztított hibajelentést, képernyőképet vagy követelménydokumentumot. A @ jel után írja be a fájl elérési útját, hogy beilleszthesse a fájl tartalmát.

Válassza ki a források legkisebb hasznos halmazát. Egy teljes napló vagy könyvtár bevonása irreleváns anyagot eredményezhet, és elvonhatja a figyelmet a kontextusról. A naplók megosztása előtt távolítsa el a hitelesítő adatokat és az érzékeny információkat, és ellenőrizze, hogy a Claude rendelkezik-e a szükséges eszközökkel az Ön által megadott dokumentációs URL-ek lekéréséhez.

Például a cat error.log | claude -p "Explain this error" parancs egy nem interaktív kéréssel küldi el a naplófájlt. Csak a fájl tartalmának ellenőrzése után használja! Ez a kontextusfüggő mesterséges intelligencia gyakorlati értéke: releváns információkat ad a modellnek a feladat elvégzéséhez.

Funkció hozzáadásakor keressen meg egy hasonló komponenst vagy függvényt a kódtárban. Adja meg Claude-nak, hogy mely konvenciókat kövesse, például az API-kliens, az érvényesítési logika, a hiba kezelése vagy a tesztelési struktúra tekintetében.

A „Kövesse nyomon, hogyan tölti be és tárolja az adatokat az @src/widgets/Weather.tsx” konkrét iránymutatást ad a Claude-nak. Nevezze meg továbbá az új funkció által megkövetelt eltéréseket is, hogy ne másolja át a már nem megfelelő viselkedést. Ezeknek a konvencióknak tükrözniük kell a csapata szoftverfejlesztési munkafolyamatát.

Kódmódosítások esetén adja meg a vonatkozó teszt-, build- vagy lint-parancsot, valamint azt a viselkedést, amelyet ellenőriznie kell. Kutatás céljából kérjen fájlhivatkozásokat vagy commit-azonosítókat. Felhasználói felületi munkákhoz adjon meg egy referencia képet és egy konfigurált módszert az implementáció rögzítésére ugyanazon a nézőtéren.

Kérd meg a Claude-ot, hogy jelentse, mit ellenőrzött valójában, beleértve a hibákat és az elhagyott ellenőrzéseket is. Ellenőrizd, hogy a bizonyítékok kielégítik-e a követelményeket; egy sikeres összeállítás még nem bizonyítja, hogy minden kért viselkedés működik.

Hosszabb feladatok esetén a Claude Code /goal feltételt és Stop hookokat is kínál. A célértékelő a beszélgetés során felszínre került bizonyítékokat értékeli, ahelyett, hogy önállóan vizsgálná a fájlokat vagy futtatná a teszteket. A beállított Stop hook megakadályozhatja a feladat befejezését, de a ismételt blokkolásnak vannak korlátai. Egyik sem helyettesíti a megfelelő teszteket és az emberi felülvizsgálatot.

Ha az ismételt javítások sem oldják meg a problémát, állj meg, és derítsd ki, mi maradt tisztázatlan az eredeti kérésben. Mielőtt törölnéd a beszélgetést, mentsd el a hasznos megállapításokat, a Git aktuális állapotát és a hátralévő feladatokat.

Az Anthropic legjobb gyakorlatokról szóló útmutatója azt javasolja, hogy ha ugyanazon probléma megoldására tett két kísérlet sikertelen volt, kezdje elölről. Használja a /clear parancsot, majd adjon meg egy módosított utasítást, amely tartalmazza a tanulságokat. A beszélgetés törlése nem vonja vissza a fájlokban végzett módosításokat.

Nyomja meg az Esc billentyűt a futó válasz megszakításához. Ha a parancssor üres, nyomja meg kétszer az Esc billentyűt a visszatekerés menü megnyitásához, majd válassza ki, mit szeretne visszaállítani. A visszatekerés nem vonja vissza minden külső hatást, ezért használjon Git ellenőrzőpontokat és külön helyreállítási eljárásokat az adatbázisokban vagy távoli szolgáltatásokban végzett módosítások esetén.

Mentse el a projekt egészére vonatkozó útmutatásokat a CLAUDE.md fájlba, az ismétlődő eljárásokat a skills fájlokba, az egyes fájlokra vonatkozó utasításokat pedig az elérési út hatókörű szabályokba. Használjon hookokat az egyes eseményekhez kötött műveletekhez, például egy formázó futtatásához szerkesztés után.

Válasszon aszerint, hogy mikor kell az utasítást alkalmazni:

Egy funkcióra vonatkozó követelmény általában a hozzá tartozó feladatleírásban vagy specifikációban szerepel, nem pedig a CLAUDE.md fájlban. Ha ideiglenes utasításokat adunk hozzá egy projekt-szintű fájlhoz, azok nehezebben különböztethetők meg a teljes kódtárra érvényes konvencióktól.

Például tárold a projekt tesztparancsát a CLAUDE.md fájlban, helyezd el a komponensspecifikus konvenciókat egy elérési út hatályú szabályba, és mentsd el az ismétlődő felülvizsgálati eljárást készségként. Ha a parancsok vagy a konvenciók megváltoznak, ellenőrizd ezeket a fájlokat, ahogyan azt a projekt egyéb dokumentációja esetében is tennéd.

A promptok, a CLAUDE.md fájl és a készségek irányítják a Claude viselkedését; ezek azonban nem garantálják, hogy egy utasítást biztosan végrehajt. A hookok konfigurált eseményekkor ellenőrzéseket futtathatnak, de megbízhatóságuk a hook típusától és megvalósításától függ.

A parancs-hook egy szkriptet futtat. A prompt- vagy ügynök-hook egy modell ítéletére támaszkodik. Ahogyan az Anthropic legjobb gyakorlatokról szóló útmutatója kifejti: „A prompt- vagy ügynök-hook egy másik modellt kér fel a döntésre, így ez sem determinisztikus.” Egy olyan szabály esetében, amelyet be kell tartani, használjon megfelelő jogosultsági ellenőrzéseket, és tesztelje a vonatkozó parancs- vagy HTTP-hookot, beleértve azt is, hogyan kezeli a hibákat.

Az egyéni alügynökök egy másik módja az ismétlődő feladatok szervezésének. Ha különálló felülvizsgálati szerepkörre vagy eszközhatárokra van szükség, határozzon meg egy szakértőt a `.claude/agents/` könyvtárban, ahelyett, hogy minden szakértői utasítást a fő munkamenethez adna hozzá. Ezek az útmutatók a munkához legalkalmasabb Claude-modellről és az AI-ügynökök típusairól további háttérinformációkat nyújtanak.

Ha a csapata több AI-termékben is kezel promptokat, tekintse meg ezeket a prompt-tervező eszközöket a Claude Code-on túli könyvtárak kezeléséhez.

Ha egy munkamenet hiányos vagy nem megfelelő eredményt hoz, ellenőrizze, hogy a kérés nem hagyott-e megoldatlanul fontos döntéseket. Ez az öt hiba megnehezítheti a munka diagnosztizálását és felülvizsgálatát.

A „Vizsgáld meg a lerakatot” utasítás nem ad elég iránymutatást a Claude-nak arról, hogy mely fájlok fontosak, illetve mikor kell abbahagynia a vizsgálatot. Előfordulhat, hogy egy általános összefoglalót kapsz, anélkül, hogy választ kapnál a kérés alapjául szolgáló problémára.

Nevezze meg azt a viselkedést vagy döntést, amelyet meg kell értenie, határozza meg a kiindulási pontot, és határozza meg a várt kimenetet. Például: „Kövesse nyomon, hogyan ellenőrzi ez az végpont a jogosultságokat, és sorolja fel a vonatkozó függvényeket.” Ha alügynököket használ, adjon mindegyiknek egy határolt kérdést, ahelyett, hogy ugyanazt a korlátlan keresést delegálná rájuk.

Ha egy funkció, egy ahhoz nem kapcsolódó hiba és egy dokumentációs kérés között váltunk, a beszélgetés olyan kontextust hordoz, amely nem feltétlenül vonatkozik az aktuális feladatra. Az olyan hivatkozások, mint „az a fájl” vagy „a korábbi megközelítés”, kétértelművé válnak.

Használj külön munkameneteket az egymástól független feladatokhoz. Ha több munkamenet is szerkeszti a repositoryt, használj külön Git munkakönyvtárakat, hogy ne módosítsák ugyanazt a munkakönyvtárat. Egy rövid mellékes kérdés: a Claude Code /btw parancsa a fő beszélgetési előzményekből kizárja a cserét.

Előfordulhat, hogy egy build sikeresen lefut, miközben egy funkció helytelenül viselkedik. Előfordulhat, hogy egy tesztcsomag sikeresen lefut, mert soha nem futtatta le a hibás bemenetet. Ha megkérjük Claude-ot, hogy „futtassa le a teszteket”, az nem jelenti azt, hogy kiderül, melyik követelményt ellenőrzik azok a tesztek.

Rendelje hozzá az elfogadási kritériumokat a konkrét ellenőrzésekhez. Hiba kijavítása esetén kérjen bizonyítékot arra, hogy a reprodukciós teszt a módosítás előtt sikertelen volt, utána pedig sikeres lett. Tartsa szem előtt a még nem tesztelt kritériumokat, ahelyett, hogy egyetlen sikeres parancsot venné az egész módosítás igazolásának.

Egy folyamatosan bővülő CLAUDE.md fájl elavult parancsokat, ismétlődő szabályokat és a feladatspecifikus követelményekkel ellentmondó utasításokat tartalmazhat. Ezeket az ellentmondásokat nem oldja meg a szöveg szigorúbb megfogalmazása.

Hasonlítsa össze a fájlt az aktuális kódtárral. Távolítsa el az elavult útmutatásokat, tisztázza az egymással ütköző szabályokat, és helyezze át a szűk körben alkalmazható utasításokat útvonal-hatályú szabályokba vagy készségekbe. Ha egy követelmény betartatására van szükség, konfigurálja és tesztelje a megfelelő ellenőrző mechanizmusokat, ahelyett, hogy ismételt emlékeztetőkre támaszkodna.

Egy kódáttekintés során egyszerre derülhetnek ki valódi hibák, bizonytalan problémák és opcionális refaktorálási javaslatok. Az összes javaslat alkalmazása megnövelheti a változtatások mértékét anélkül, hogy javítaná a kívánt viselkedést.

Kérdezze meg az egyes megállapítások mögött álló bizonyítékokat és hatásokat. Rangsorolja a helyességi problémákat és a nem teljesített követelményeket, vizsgálja meg a bizonytalan állításokat, és tartsa távol a jelenlegi diff-től a nem kapcsolódó fejlesztéseket. A felülvizsgálónak képesnek kell lennie arra, hogy ne jelentsen cselekvésre okot adó megállapításokat, ha a bizonyítékok alátámasztják ezt a következtetést.

A sablon testreszabásához cserélje ki a helyőrzőket a projekt adataival, és döntse el, mit kell tennie a Claude-nak, mielőtt módosításokat hajtana végre. Kövesse ezeket a lépéseket a kérés előkészítéséhez és az eredmény ellenőrzéséhez.

Egy kis, jól meghatározott változtatás esetén megkérheted Claude-ot, hogy közvetlenül hajtsa végre azt. Ismeretlen kód, több fájlt érintő változtatások vagy tisztázatlan követelmények esetén kezdj egy tervvel!

Nyomja meg a Shift+Tab billentyűkombinációt, amíg meg nem jelenik a Tervezési mód, vagy indítsa el a Claude Code-ot a claude --permission-mode plan paranccsal. Ebben a módban a Claude átvizsgálhatja a fájlokat és olvasási joggal rendelkező parancsokat futtathat anélkül, hogy szerkesztené a forráskódot. Tekintse át a javasolt fájlokat, függőségeket és teszteket, mielőtt jóváhagyná a megvalósítást. Nyomja meg a Ctrl+G billentyűkombinációt a javasolt terv megnyitásához a szerkesztőjében.

Adja meg Claude-nak a feladat megértéséhez szükséges információkat: fájlhivatkozást, tisztított hibajelentést, képernyőképet vagy követelménydokumentumot. A @ jel után írja be a fájl elérési útját, hogy beilleszthesse a fájl tartalmát.

Válassza ki a források legkisebb hasznos halmazát. Egy teljes napló vagy könyvtár bevonása irreleváns anyagot eredményezhet, és elvonhatja a figyelmet a kontextusról. A naplók megosztása előtt távolítsa el a hitelesítő adatokat és az érzékeny információkat, és ellenőrizze, hogy a Claude rendelkezik-e a szükséges eszközökkel az Ön által megadott dokumentációs URL-ek lekéréséhez.

Például a cat error.log | claude -p "Explain this error" parancs egy nem interaktív kéréssel küldi el a naplófájlt. Csak a fájl tartalmának ellenőrzése után használja! Ez a kontextusfüggő mesterséges intelligencia gyakorlati értéke: releváns információkat ad a modellnek a feladat elvégzéséhez.

Funkció hozzáadásakor keressen meg egy hasonló komponenst vagy függvényt a kódtárban. Adja meg Claude-nak, hogy mely konvenciókat kövesse, például az API-kliens, az érvényesítési logika, a hiba kezelése vagy a tesztelési struktúra tekintetében.

A „Kövesse nyomon, hogyan tölti be és tárolja az adatokat a @src/widgets/Weather.tsx” konkrét támpontot ad a Claude-nak. Nevezze meg továbbá az új funkció által megkövetelt eltéréseket is, hogy ne másolja át a már nem megfelelő viselkedést. Ezeknek a konvencióknak tükrözniük kell a csapata szoftverfejlesztési munkafolyamatát.

Kódmódosítások esetén adja meg a vonatkozó teszt-, build- vagy lint-parancsot, valamint azt a viselkedést, amelyet ellenőriznie kell. Kutatás céljából kérjen fájlhivatkozásokat vagy commit-azonosítókat. Felhasználói felületi munkákhoz adjon meg egy referencia képet és egy konfigurált módszert az implementáció rögzítésére ugyanazon a nézőtéren.

Kérd meg a Claude-ot, hogy jelentse, mit ellenőrzött valójában, beleértve a hibákat és az elhagyott ellenőrzéseket is. Ellenőrizd, hogy a bizonyítékok kielégítik-e a követelményeket; egy sikeres összeállítás még nem bizonyítja, hogy minden kért viselkedés működik.

Hosszabb feladatok esetén a Claude Code /goal feltételt és Stop hookokat is kínál. A célértékelő a beszélgetés során felszínre került bizonyítékokat értékeli, ahelyett, hogy önállóan vizsgálná a fájlokat vagy futtatná a teszteket. A beállított Stop hook megakadályozhatja a feladat befejezését, de a ismételt blokkolásnak vannak korlátai. Egyik sem helyettesíti a megfelelő teszteket és az emberi felülvizsgálatot.

Ha az ismételt javítások sem oldják meg a problémát, állj meg, és derítsd ki, mi maradt tisztázatlan az eredeti kérésben. Mielőtt törölnéd a beszélgetést, mentsd el a hasznos megállapításokat, a Git aktuális állapotát és a hátralévő feladatokat.

Az Anthropic legjobb gyakorlatokról szóló útmutatója azt javasolja, hogy ha ugyanazon probléma megoldására tett két kísérlet sikertelen volt, kezdje elölről. Használja a /clear parancsot, majd adjon meg egy módosított utasítást, amely tartalmazza a tanulságokat. A beszélgetés törlése nem vonja vissza a fájlokban végzett módosításokat.

Nyomja meg az Esc billentyűt a futó válasz megszakításához. Ha a parancssor üres, nyomja meg kétszer az Esc billentyűt a visszatekerés menü megnyitásához, majd válassza ki, mit szeretne visszaállítani. A visszatekerés nem vonja vissza minden külső hatást, ezért használjon Git ellenőrzőpontokat és külön helyreállítási eljárásokat az adatbázisokban vagy távoli szolgáltatásokban végzett módosítások esetén.

Mentse el a projekt egészére vonatkozó útmutatásokat a CLAUDE.md fájlba, az ismétlődő eljárásokat a skills fájlokba, az egyes fájlokra vonatkozó utasításokat pedig az elérési út hatókörű szabályokba. Használjon hookokat az egyes eseményekhez kötött műveletekhez, például egy formázó futtatásához szerkesztés után.

Válasszon aszerint, hogy mikor kell az utasítást alkalmazni:

Egy funkcióra vonatkozó követelmény általában a hozzá tartozó feladatleírásban vagy specifikációban szerepel, nem pedig a CLAUDE.md fájlban. Ha ideiglenes utasításokat adunk hozzá egy projekt-szintű fájlhoz, azok nehezebben különböztethetők meg a teljes kódtárra érvényes konvencióktól.

Például tárold a projekt tesztparancsát a CLAUDE.md fájlban, helyezd el a komponensekre vonatkozó konvenciókat egy elérési út hatályú szabályba, és mentsd el az ismétlődő felülvizsgálati eljárást készségként. Ha a parancsok vagy a konvenciók megváltoznak, ellenőrizd ezeket a fájlokat, ahogyan azt a projekt egyéb dokumentációja esetében is tennéd.

A promptok, a CLAUDE.md fájl és a készségek irányítják a Claude viselkedését; ezek azonban nem garantálják, hogy egy utasítást biztosan végrehajt. A hookok konfigurált eseményekkor ellenőrzéseket futtathatnak, de megbízhatóságuk a hook típusától és megvalósításától függ.

A parancs-hook egy szkriptet futtat. A prompt- vagy ügynök-hook egy modell ítéletére támaszkodik. Ahogyan az Anthropic legjobb gyakorlatokról szóló útmutatója kifejti: „A prompt- vagy ügynök-hook egy másik modellt kér meg a döntés meghozatalára, így ez sem determinisztikus.” Egy olyan szabály esetében, amelyet be kell tartani, használjon megfelelő jogosultsági ellenőrzéseket, és tesztelje a vonatkozó parancs- vagy HTTP-hookot, beleértve azt is, hogyan kezeli a hibákat.

Az egyéni alügynökök egy másik módja az ismétlődő feladatok szervezésének. Ha különálló felülvizsgálati szerepkörre vagy eszközhatárokra van szükség, határozzon meg egy szakértőt a `.claude/agents/` könyvtárban, ahelyett, hogy minden szakértői utasítást a fő munkamenethez adna hozzá. Ezek az útmutatók a munkához legalkalmasabb Claude-modellről és az AI-ügynökök típusairól további háttérinformációkat nyújtanak.

Ha a csapata több AI-termékben is kezel promptokat, tekintse meg ezeket a prompt-tervező eszközöket a Claude Code-on túli könyvtárak kezeléséhez.

Ha egy munkamenet hiányos vagy nem megfelelő eredményt hoz, ellenőrizze, hogy a kérés nem hagyott-e megoldatlanul fontos döntéseket. Ez az öt hiba megnehezítheti a munka diagnosztizálását és felülvizsgálatát.

A „Vizsgáld meg a lerakatot” utasítás nem ad elég iránymutatást a Claude-nak arról, hogy mely fájlok fontosak, illetve mikor kell abbahagynia a vizsgálatot. Előfordulhat, hogy egy általános összefoglalót kapsz, anélkül, hogy választ kapnál a kérés alapjául szolgáló problémára.

Nevezze meg azt a viselkedést vagy döntést, amelyet meg kell értenie, határozza meg a kiindulási pontot, és határozza meg a várt kimenetet. Például: „Kövesse nyomon, hogyan ellenőrzi ez az végpont a jogosultságokat, és sorolja fel a vonatkozó függvényeket.” Ha alügynököket használ, mindegyiknek adjon egy határolt kérdést, ahelyett, hogy ugyanazt a korlátlan keresést delegálná rájuk.

Ha egy funkció, egy ahhoz nem kapcsolódó hiba és egy dokumentációs kérés között váltunk, a beszélgetés olyan kontextust hordoz, amely nem feltétlenül vonatkozik az aktuális feladatra. Az olyan hivatkozások, mint „az a fájl” vagy „a korábbi megközelítés”, kétértelművé válnak.

Használj külön munkameneteket az egymástól független feladatokhoz. Ha több munkamenet is szerkeszti a repositoryt, használj külön Git munkakönyvtárakat, hogy ne módosítsák ugyanazt a munkakönyvtárat. Egy rövid mellékes kérdés: a Claude Code /btw parancsa a fő beszélgetési előzményekből kizárja a cserét.

Előfordulhat, hogy egy build sikeresen lefut, miközben egy funkció helytelenül viselkedik. Előfordulhat, hogy egy tesztcsomag sikeresen lefut, mert soha nem futtatta le a hibás bemenetet. Ha megkérjük Claude-ot, hogy „futtassa le a teszteket”, az nem jelenti azt, hogy kiderül, melyik követelményt ellenőrzik azok a tesztek.

Rendeld hozzá az elfogadási kritériumokat a konkrét ellenőrzésekhez. Hiba kijavítása esetén kérj bizonyítékot arra, hogy a reprodukciós teszt a módosítás előtt sikertelen volt, utána pedig sikeres lett. Tartsd szem előtt a még nem tesztelt kritériumokat, ahelyett, hogy egyetlen sikeres parancsot vennél alapul a teljes módosítás ellenőrzéséhez.

Egy folyamatosan bővülő CLAUDE.md fájl elavult parancsokat, ismétlődő szabályokat és a feladatspecifikus követelményekkel ellentmondó utasításokat tartalmazhat. Ezeket az ellentmondásokat nem oldja meg a szöveg szigorúbb megfogalmazása.

Hasonlítsa össze a fájlt az aktuális kódtárral. Távolítsa el az elavult útmutatásokat, tisztázza az egymással ütköző szabályokat, és helyezze át a szűk körben alkalmazható utasításokat útvonal-hatályú szabályokba vagy készségekbe. Ha egy követelmény betartatására van szükség, konfigurálja és tesztelje a megfelelő ellenőrző mechanizmusokat, ahelyett, hogy ismételt emlékeztetőkre támaszkodna.

Egy kódáttekintés során egyszerre derülhetnek ki valódi hibák, bizonytalan problémák és opcionális refaktorálási javaslatok. Az összes javaslat alkalmazása megnövelheti a változtatások mértékét anélkül, hogy javítaná a kívánt viselkedést.

Kérdezze meg az egyes megállapítások mögött álló bizonyítékokat és hatásokat. Rangsorolja a helyességi problémákat és a nem teljesített követelményeket, vizsgálja meg a bizonytalan állításokat, és tartsa távol a jelenlegi diff-től a nem kapcsolódó fejlesztéseket. A felülvizsgálónak képesnek kell lennie arra, hogy ne jelentsen cselekvésre okot adó megállapításokat, ha a bizonyítékok alátámasztják ezt a következtetést.

A sablon testreszabásához cserélje ki a helyőrzőket a projekt adataival, és döntse el, mit kell tennie a Claude-nak, mielőtt módosításokat hajtana végre. Kövesse ezeket a lépéseket a kérés előkészítéséhez és az eredmény ellenőrzéséhez.

Egy kis, jól meghatározott változtatás esetén megkérheted Claude-ot, hogy közvetlenül hajtsa végre azt. Ismeretlen kód, több fájlt érintő változtatások vagy tisztázatlan követelmények esetén kezdj egy tervvel!

Nyomja meg a Shift+Tab billentyűkombinációt, amíg meg nem jelenik a Tervezési mód, vagy indítsa el a Claude Code-ot a claude --permission-mode plan paranccsal. Ebben a módban a Claude átvizsgálhatja a fájlokat és olvasási joggal rendelkező parancsokat futtathat anélkül, hogy szerkesztené a forráskódot. Tekintse át a javasolt fájlokat, függőségeket és teszteket, mielőtt jóváhagyná a megvalósítást. Nyomja meg a Ctrl+G billentyűkombinációt a javasolt terv megnyitásához a szerkesztőjében.

Adja meg Claude-nak a feladat megértéséhez szükséges információkat: fájlhivatkozást, tisztított hibajelentést, képernyőképet vagy követelménydokumentumot. A @ jel után írja be a fájl elérési útját, hogy beilleszthesse a fájl tartalmát.

Válassza ki a források legkisebb hasznos halmazát. Egy teljes napló vagy könyvtár bevonása irreleváns anyagot eredményezhet, és elvonhatja a figyelmet a kontextusról. A naplók megosztása előtt távolítsa el a hitelesítő adatokat és az érzékeny információkat, és ellenőrizze, hogy a Claude rendelkezik-e a szükséges eszközökkel az Ön által megadott dokumentációs URL-ek lekéréséhez.

Például a cat error.log | claude -p "Explain this error" parancs egy nem interaktív kéréssel küldi el a naplófájlt. Csak a fájl tartalmának ellenőrzése után használja! Ez a kontextusfüggő mesterséges intelligencia gyakorlati értéke: releváns információkat ad a modellnek a feladat elvégzéséhez.

Funkció hozzáadásakor keressen meg egy hasonló komponenst vagy függvényt a kódtárban. Adja meg Claude-nak, hogy mely konvenciókat kövesse, például az API-kliens, az érvényesítési logika, a hiba kezelése vagy a tesztelési struktúra tekintetében.

A „Kövesse nyomon, hogyan tölti be és tárolja az adatokat a @src/widgets/Weather.tsx” konkrét támpontot ad a Claude-nak. Nevezze meg továbbá az új funkció által megkövetelt eltéréseket is, hogy ne másolja át a már nem megfelelő viselkedést. Ezeknek a konvencióknak tükrözniük kell a csapata szoftverfejlesztési munkafolyamatát.

Kódmódosítások esetén adja meg a vonatkozó teszt-, build- vagy lint-parancsot, valamint azt a viselkedést, amelyet ellenőriznie kell. Kutatás céljából kérjen fájlhivatkozásokat vagy commit-azonosítókat. Felhasználói felületi munkákhoz adjon meg egy referencia képet és egy konfigurált módszert az implementáció rögzítésére ugyanazon a nézőtéren.

Kérd meg a Claude-ot, hogy jelentse, mit ellenőrzött valójában, beleértve a hibákat és az elhagyott ellenőrzéseket is. Ellenőrizd, hogy a bizonyítékok kielégítik-e a követelményeket; egy sikeres összeállítás még nem bizonyítja, hogy minden kért viselkedés működik.

Hosszabb feladatok esetén a Claude Code /goal feltételt és Stop hookokat is kínál. A célértékelő a beszélgetés során felszínre került bizonyítékokat értékeli, ahelyett, hogy önállóan vizsgálná a fájlokat vagy futtatná a teszteket. A beállított Stop hook megakadályozhatja a feladat befejezését, de a ismételt blokkolásnak vannak korlátai. Egyik sem helyettesíti a megfelelő teszteket és az emberi felülvizsgálatot.

Ha az ismételt javítások sem oldják meg a problémát, állj meg, és derítsd ki, mi maradt tisztázatlan az eredeti kérésben. Mielőtt törölnéd a beszélgetést, mentsd el a hasznos megállapításokat, a Git aktuális állapotát és a hátralévő feladatokat.

Az Anthropic legjobb gyakorlatokról szóló útmutatója azt javasolja, hogy ha ugyanazon probléma megoldására tett két kísérlet sikertelen volt, kezdje elölről. Használja a /clear parancsot, majd adjon meg egy módosított utasítást, amely tartalmazza a tanulságokat. A beszélgetés törlése nem vonja vissza a fájlokban végzett módosításokat.

Nyomd meg az Esc gombot a futó válasz megszakításához. Ha a parancssor üres, nyomd meg kétszer az Esc gombot a visszatekerés menü megnyitásához, és válaszd ki, mit szeretnél visszaállítani. A visszatekerés nem vonja vissza minden külső hatást, ezért használd a Git ellenőrzőpontjait és külön helyreállítási eljárásokat az adatbázisokban vagy távoli szolgáltatásokban végzett módosítások esetén.

Mentse el a projekt egészére vonatkozó útmutatásokat a CLAUDE.md fájlba, az ismétlődő eljárásokat a skills fájlokba, az egyes fájlokra vonatkozó utasításokat pedig az elérési útvonalra vonatkozó szabályokba. Használjon hookokat az egyes eseményekhez kapcsolódó műveletekhez, például egy formázó futtatásához szerkesztés után.

Válasszon aszerint, hogy mikor kell az utasítást alkalmazni:

Egy funkcióra vonatkozó követelmény általában a hozzá tartozó feladatleírásban vagy specifikációban szerepel, nem pedig a CLAUDE.md fájlban. Ha ideiglenes utasításokat adunk hozzá egy projekt-szintű fájlhoz, azok nehezebben különböztethetők meg a teljes kódtárra érvényes konvencióktól.

Például tárold a projekt tesztparancsát a CLAUDE.md fájlban, helyezd el a komponensspecifikus konvenciókat egy elérési út hatályú szabályba, és mentsd el az ismétlődő felülvizsgálati eljárást készségként. Ha a parancsok vagy a konvenciók megváltoznak, ellenőrizd ezeket a fájlokat, ahogyan azt a projekt egyéb dokumentációja esetében is tennéd.

A promptok, a CLAUDE.md fájl és a készségek irányítják a Claude viselkedését; ezek azonban nem garantálják, hogy egy utasítást biztosan végrehajt. A hookok konfigurált eseményekkor ellenőrzéseket futtathatnak, de megbízhatóságuk a hook típusától és megvalósításától függ.

A parancs-hook egy szkriptet futtat. A prompt- vagy ügynök-hook egy modell ítéletére támaszkodik. Ahogyan az Anthropic legjobb gyakorlatokról szóló útmutatója kifejti: „A prompt- vagy ügynök-hook egy másik modellt kér fel a döntésre, így ez sem determinisztikus.” Egy olyan szabály esetében, amelyet be kell tartani, használjon megfelelő jogosultsági ellenőrzéseket, és tesztelje a vonatkozó parancs- vagy HTTP-hookot, beleértve azt is, hogyan kezeli a hibákat.

Az egyéni alügynökök egy másik módja az ismétlődő feladatok szervezésének. Ha különálló felülvizsgálati szerepkörre vagy eszközhatárokra van szükség, határozzon meg egy szakértőt a `claude/agents/` könyvtárban, ahelyett, hogy minden szakértői utasítást a fő munkamenethez adna hozzá. Ezek az útmutatók a munkához legalkalmasabb Claude-modellről és az AI-ügynökök típusairól további háttérinformációkat nyújtanak.

Ha a csapata több AI-termékben is kezel promptokat, tekintse meg ezeket a prompt-tervező eszközöket a Claude Code-on túli könyvtárak kezeléséhez.

Ha egy munkamenet hiányos vagy nem megfelelő eredményt hoz, ellenőrizze, hogy a kérés nem hagyott-e megoldatlanul fontos döntéseket. Ez az öt hiba megnehezítheti a munka diagnosztizálását és felülvizsgálatát.

A „Vizsgáld meg a lerakatot” utasítás nem ad elég iránymutatást a Claude-nak arról, hogy mely fájlok fontosak, illetve mikor kell abbahagynia a vizsgálatot. Előfordulhat, hogy egy általános összefoglalót kapsz, anélkül, hogy választ kapnál a kérés alapjául szolgáló problémára.

Nevezze meg azt a viselkedést vagy döntést, amelyet meg kell értenie, határozza meg a kiindulási pontot, és határozza meg a várt kimenetet. Például: „Kövesse nyomon, hogyan ellenőrzi ez az végpont a jogosultságokat, és sorolja fel a vonatkozó függvényeket.” Ha alügynököket használ, adjon mindegyiknek egy határolt kérdést, ahelyett, hogy ugyanazt a korlátlan keresést delegálná rájuk.

Ha egy funkció, egy ahhoz nem kapcsolódó hiba és egy dokumentációs kérés között váltunk, a beszélgetés olyan kontextust hordoz, amely nem feltétlenül vonatkozik az aktuális feladatra. Az olyan hivatkozások, mint „az a fájl” vagy „a korábbi megközelítés”, kétértelművé válnak.

Használj külön munkameneteket az egymástól független feladatokhoz. Ha több munkamenet is szerkeszti a repositoryt, használj külön Git munkakönyvtárakat, hogy ne módosítsák ugyanazt a munkakönyvtárat. Egy rövid mellékes kérdés: a Claude Code /btw parancsa a fő beszélgetési előzményekből kizárja a cserét.

Előfordulhat, hogy egy build sikeresen lefut, miközben egy funkció helytelenül viselkedik. Előfordulhat, hogy egy tesztcsomag sikeresen lefut, mert soha nem futtatta le a hibás bemenetet. Ha megkérjük Claude-ot, hogy „futtassa le a teszteket”, az nem jelenti azt, hogy kiderül, melyik követelményt ellenőrzik azok a tesztek.

Rendeld hozzá az elfogadási kritériumokat a konkrét ellenőrzésekhez. Hiba kijavítása esetén kérj bizonyítékot arra, hogy a reprodukciós teszt a módosítás előtt sikertelen volt, utána pedig sikeres lett. Tartsd szem előtt a még nem tesztelt kritériumokat, ahelyett, hogy egyetlen sikeres parancsot vennél alapul a teljes módosítás ellenőrzéséhez.

Egy folyamatosan bővülő CLAUDE.md fájl elavult parancsokat, ismétlődő szabályokat és a feladatspecifikus követelményekkel ellentmondó utasításokat tartalmazhat. Ezeket az ellentmondásokat nem oldja meg a szöveg szigorúbb megfogalmazása.

Hasonlítsa össze a fájlt az aktuális kódtárral. Távolítsa el az elavult útmutatásokat, tisztázza az egymással ütköző szabályokat, és helyezze át a szűk körben alkalmazható utasításokat útvonal-hatályú szabályokba vagy készségekbe. Ha egy követelmény betartatására van szükség, konfigurálja és tesztelje a megfelelő ellenőrző mechanizmusokat, ahelyett, hogy ismételt emlékeztetőkre támaszkodna.

Egy kódáttekintés során egyszerre derülhetnek ki valódi hibák, bizonytalan problémák és opcionális refaktorálási javaslatok. Az összes javaslat alkalmazása megnövelheti a változtatások mértékét anélkül, hogy javítaná a kívánt viselkedést.

Kérdezze meg az egyes megállapítások mögött álló bizonyítékokat és hatásokat. Rangsorolja a helyességi problémákat és a nem teljesített követelményeket, vizsgálja meg a bizonytalan állításokat, és tartsa távol a jelenlegi diff-től a nem kapcsolódó fejlesztéseket. A felülvizsgálónak képesnek kell lennie arra, hogy ne jelentsen cselekvésre okot adó megállapításokat, ha a bizonyítékok alátámasztják ezt a következtetést.

A sablon testreszabásához cserélje ki a helyőrzőket a projekt adataival, és döntse el, mit kell tennie a Claude-nak, mielőtt módosításokat hajtana végre. Kövesse ezeket a lépéseket a kérés előkészítéséhez és az eredmény ellenőrzéséhez.

Egy kis, jól meghatározott változtatás esetén megkérheted Claude-ot, hogy közvetlenül hajtsa végre azt. Ismeretlen kód, több fájlt érintő változtatások vagy tisztázatlan követelmények esetén kezdj egy tervvel!

Nyomja meg a Shift+Tab billentyűkombinációt, amíg meg nem jelenik a Tervezési mód, vagy indítsa el a Claude Code-ot a claude --permission-mode plan paranccsal. Ebben a módban a Claude átvizsgálhatja a fájlokat és olvasási joggal rendelkező parancsokat futtathat anélkül, hogy szerkesztené a forráskódot. Tekintse át a javasolt fájlokat, függőségeket és teszteket, mielőtt jóváhagyná a megvalósítást. Nyomja meg a Ctrl+G billentyűkombinációt a javasolt terv megnyitásához a szerkesztőjében.

Adja meg Claude-nak a feladat megértéséhez szükséges információkat: fájlhivatkozást, tisztított hibajelentést, képernyőképet vagy követelménydokumentumot. A @ jel után írja be a fájl elérési útját, hogy beilleszthesse a fájl tartalmát.

Válassza ki a források legkisebb hasznos halmazát. Egy teljes napló vagy könyvtár bevonása irreleváns anyagot eredményezhet, és elvonhatja a figyelmet a kontextusról. A naplók megosztása előtt távolítsa el a hitelesítő adatokat és az érzékeny információkat, és ellenőrizze, hogy a Claude rendelkezik-e a szükséges eszközökkel az Ön által megadott dokumentációs URL-ek lekéréséhez.

Például a cat error.log | claude -p "Explain this error" parancs egy nem interaktív kéréssel küldi el a naplófájlt. Csak a fájl tartalmának ellenőrzése után használja! Ez a kontextusfüggő mesterséges intelligencia gyakorlati értéke: releváns információkat ad a modellnek a feladat elvégzéséhez.

Funkció hozzáadásakor keressen meg egy hasonló komponenst vagy függvényt a kódtárban. Adja meg Claude-nak, hogy mely konvenciókat kövesse, például az API-kliens, az érvényesítési logika, a hiba kezelése vagy a tesztelési struktúra tekintetében.

A „Kövesse nyomon, hogyan tölti be és tárolja az adatokat a @src/widgets/Weather.tsx” konkrét támpontot ad a Claude-nak. Nevezze meg továbbá az új funkció által megkövetelt eltéréseket is, hogy ne másolja át a már nem megfelelő viselkedést. Ezeknek a konvencióknak tükrözniük kell a csapata szoftverfejlesztési munkafolyamatát.

Kódmódosítások esetén adja meg a vonatkozó teszt-, build- vagy lint-parancsot, valamint azt a viselkedést, amelyet ellenőriznie kell. Kutatás céljából kérjen fájlhivatkozásokat vagy commit-azonosítókat. Felhasználói felületi munkákhoz adjon meg egy referencia képet és egy konfigurált módszert az implementáció ugyanazon a nézőtéren történő rögzítéséhez.

Kérd meg a Claude-ot, hogy jelentse, mit ellenőrzött valójában, beleértve a hibákat és az elhagyott ellenőrzéseket is. Ellenőrizd, hogy a bizonyítékok kielégítik-e a követelményeket; egy sikeres összeállítás még nem jelenti azt, hogy minden kért viselkedés működik.

Hosszabb feladatok esetén a Claude Code /goal feltételt és Stop hookokat is kínál. A célértékelő a beszélgetés során felszínre került bizonyítékokat értékeli, ahelyett, hogy önállóan vizsgálná a fájlokat vagy futtatná a teszteket. A beállított Stop hook megakadályozhatja a feladat befejezését, de a ismételt blokkolásnak vannak korlátai. Egyik sem helyettesíti a megfelelő teszteket és az emberi felülvizsgálatot.

Ha az ismételt javítások sem oldják meg a problémát, állj meg, és derítsd ki, mi maradt tisztázatlan az eredeti kérésben. Mielőtt törölnéd a beszélgetést, mentsd el a hasznos megállapításokat, a Git aktuális állapotát és a hátralévő feladatokat.

Az Anthropic legjobb gyakorlatokról szóló útmutatója azt javasolja, hogy ha ugyanazon probléma megoldására tett két kísérlet sikertelen volt, kezdje elölről. Használja a /clear parancsot, majd adjon meg egy módosított utasítást, amely tartalmazza a tanulságokat. A beszélgetés törlése nem vonja vissza a fájlokban végzett módosításokat.

Nyomja meg az Esc billentyűt a futó válasz megszakításához. Ha a parancssor üres, nyomja meg kétszer az Esc billentyűt a visszatekerés menü megnyitásához, majd válassza ki, mit szeretne visszaállítani. A visszatekerés nem vonja vissza minden külső hatást, ezért használjon Git ellenőrzőpontokat és külön helyreállítási eljárásokat az adatbázisokban vagy távoli szolgáltatásokban végzett módosítások esetén.

Mentse el a projekt egészére vonatkozó útmutatásokat a CLAUDE.md fájlba, az ismétlődő eljárásokat a skills fájlokba, az egyes fájlokra vonatkozó utasításokat pedig az elérési út hatókörű szabályokba. Használjon hookokat az egyes eseményekhez kötött műveletekhez, például egy formázó futtatásához szerkesztés után.

Válasszon aszerint, hogy mikor kell az utasítást alkalmazni:

Egy funkcióra vonatkozó követelmény általában a hozzá tartozó feladatleírásban vagy specifikációban szerepel, nem pedig a CLAUDE.md fájlban. Ha ideiglenes utasításokat adunk hozzá egy projekt-szintű fájlhoz, azok nehezebben különböztethetők meg a teljes kódtárra érvényes konvencióktól.

Például tárold a projekt tesztparancsát a CLAUDE.md fájlban, helyezd el a komponensspecifikus konvenciókat egy elérési út hatályú szabályba, és mentsd el az ismétlődő felülvizsgálati eljárást készségként. Ha a parancsok vagy a konvenciók megváltoznak, ellenőrizd ezeket a fájlokat, ahogyan azt a projekt egyéb dokumentációja esetében is tennéd.

A promptok, a CLAUDE.md fájl és a készségek irányítják a Claude viselkedését; ezek azonban nem garantálják, hogy egy utasítást biztosan végrehajt. A hookok konfigurált eseményekkor ellenőrzéseket futtathatnak, de megbízhatóságuk a hook típusától és megvalósításától függ.

A parancs-hook egy szkriptet futtat. A prompt- vagy ügynök-hook egy modell ítéletére támaszkodik. Ahogyan az Anthropic legjobb gyakorlatokról szóló útmutatója kifejti: „A prompt- vagy ügynök-hook egy másik modellt kér fel a döntésre, így ez sem determinisztikus.” Egy olyan szabály esetében, amelyet be kell tartani, használjon megfelelő jogosultsági ellenőrzéseket, és tesztelje a vonatkozó parancs- vagy HTTP-hookot, beleértve azt is, hogyan kezeli a hibákat.

Az egyéni alügynökök egy másik módja az ismétlődő feladatok szervezésének. Ha különálló felülvizsgálati szerepkörre vagy eszközhatárokra van szükség, határozzon meg egy szakértőt a `.claude/agents/` könyvtárban, ahelyett, hogy minden szakértői utasítást a fő munkamenethez adna hozzá. Ezek az útmutatók a munkához legalkalmasabb Claude-modellről és az AI-ügynökök típusairól további háttérinformációkat nyújtanak.

Ha a csapata több AI-termékben is kezel promptokat, tekintse meg ezeket a prompt-tervező eszközöket a Claude Code-on túli könyvtárak kezeléséhez.

Ha egy munkamenet hiányos vagy nem megfelelő eredményt hoz, ellenőrizze, hogy a kérés nem hagyott-e megoldatlanul fontos döntéseket. Ez az öt hiba megnehezítheti a munka diagnosztizálását és felülvizsgálatát.

A „Vizsgáld meg a lerakatot” utasítás nem ad elég iránymutatást a Claude-nak arról, hogy mely fájlok fontosak, illetve mikor kell abbahagynia a vizsgálatot. Előfordulhat, hogy egy általános összefoglalót kapsz, anélkül, hogy választ kapnál a kérés alapjául szolgáló problémára.

Nevezze meg azt a viselkedést vagy döntést, amelyet meg kell értenie, határozza meg a kiindulási pontot, és határozza meg a várt kimenetet. Például: „Kövesse nyomon, hogyan ellenőrzi ez az végpont a jogosultságokat, és sorolja fel a vonatkozó függvényeket.” Ha alügynököket használ, mindegyiknek adjon egy határolt kérdést, ahelyett, hogy ugyanazt a korlátlan keresést delegálná rájuk.

Ha egy funkció, egy ahhoz nem kapcsolódó hiba és egy dokumentációs kérés között váltunk, a beszélgetés olyan kontextust hordoz, amely nem feltétlenül vonatkozik az aktuális feladatra. Az olyan hivatkozások, mint „az a fájl” vagy „a korábbi megközelítés”, kétértelművé válnak.

Használj külön munkameneteket az egymástól független feladatokhoz. Ha több munkamenet is szerkeszti a repositoryt, használj külön Git munkakönyvtárakat, hogy ne módosítsák ugyanazt a munkakönyvtárat. Egy rövid mellékes kérdés: a Claude Code /btw parancsa a fő beszélgetési előzményekből kizárja a cserét.

Előfordulhat, hogy egy build sikeresen lefut, miközben egy funkció helytelenül viselkedik. Előfordulhat, hogy egy tesztcsomag sikeresen lefut, mert soha nem futtatta le a hibás bemenetet. Ha megkérjük Claude-ot, hogy „futtassa le a teszteket”, az nem jelenti azt, hogy kiderül, melyik követelményt ellenőrzik azok a tesztek.

Rendeld hozzá az elfogadási kritériumokat a konkrét ellenőrzésekhez. Hiba kijavítása esetén kérj bizonyítékot arra, hogy a reprodukciós teszt a módosítás előtt sikertelen volt, utána pedig sikeres lett. Tartsd szem előtt a még nem tesztelt kritériumokat, ahelyett, hogy egyetlen sikeres parancsot vennél a teljes módosítás igazolásának.

Egy folyamatosan bővülő CLAUDE.md fájl elavult parancsokat, ismétlődő szabályokat és a feladatspecifikus követelményekkel ellentmondó utasításokat tartalmazhat. Ezeket az ellentmondásokat nem oldja meg a szöveg szigorúbb megfogalmazása.

Hasonlítsa össze a fájlt az aktuális kódtárral. Távolítsa el az elavult útmutatásokat, tisztázza az egymással ütköző szabályokat, és helyezze át a szűk körben alkalmazható utasításokat útvonal-hatályú szabályokba vagy készségekbe. Ha egy követelmény betartatására van szükség, konfigurálja és tesztelje a megfelelő ellenőrző mechanizmusokat, ahelyett, hogy ismételt emlékeztetőkre támaszkodna.

Egy kódáttekintés során egyszerre derülhetnek ki valódi hibák, bizonytalan problémák és opcionális refaktorálási javaslatok. Az összes javaslat alkalmazása megnövelheti a változtatások mértékét anélkül, hogy javítaná a kívánt viselkedést.

Kérdezze meg az egyes megállapítások mögött álló bizonyítékokat és hatásokat. Rangsorolja a helyességi problémákat és a nem teljesített követelményeket, vizsgálja meg a bizonytalan állításokat, és tartsa távol a jelenlegi diff-től a nem kapcsolódó fejlesztéseket. A felülvizsgálónak képesnek kell lennie arra, hogy ne jelentsen cselekvésre okot adó megállapításokat, ha a bizonyítékok alátámasztják ezt a következtetést.

A sablon testreszabásához cserélje ki a helyőrzőket a projekt adataival, és döntse el, mit kell tennie a Claude-nak, mielőtt módosításokat hajtana végre. Kövesse ezeket a lépéseket a kérés előkészítéséhez és az eredmény ellenőrzéséhez.

Egy kis, jól meghatározott változtatás esetén megkérheted Claude-ot, hogy közvetlenül hajtsa végre azt. Ismeretlen kód, több fájlt érintő változtatások vagy tisztázatlan követelmények esetén kezdj egy tervvel!

Nyomja meg a Shift+Tab billentyűkombinációt, amíg meg nem jelenik a Tervezési mód, vagy indítsa el a Claude Code-ot a claude --permission-mode plan paranccsal. Ebben a módban a Claude átvizsgálhatja a fájlokat és olvasási joggal rendelkező parancsokat futtathat anélkül, hogy szerkesztené a forráskódot. Tekintse át a javasolt fájlokat, függőségeket és teszteket, mielőtt jóváhagyná a megvalósítást. Nyomja meg a Ctrl+G billentyűkombinációt a javasolt terv megnyitásához a szerkesztőjében.

Adja meg Claude-nak a feladat megértéséhez szükséges információkat: fájlhivatkozást, tisztított hibajelentést, képernyőképet vagy követelménydokumentumot. A @ jel után írja be a fájl elérési útját, hogy beilleszthesse a fájl tartalmát.

Válassza ki a források legkisebb hasznos halmazát. Egy teljes napló vagy könyvtár bevonása irreleváns anyagot eredményezhet, és elvonhatja a figyelmet a kontextusról. A naplók megosztása előtt távolítsa el a hitelesítő adatokat és az érzékeny információkat, és ellenőrizze, hogy a Claude rendelkezik-e a szükséges eszközökkel az Ön által megadott dokumentációs URL-ek lekéréséhez.

Például a cat error.log | claude -p "Explain this error" parancs egy nem interaktív kéréssel küldi el a naplófájlt. Csak a fájl tartalmának ellenőrzése után használja! Ez a kontextusfüggő mesterséges intelligencia gyakorlati értéke: releváns információkat ad a modellnek a feladat elvégzéséhez.

Funkció hozzáadásakor keressen meg egy hasonló komponenst vagy függvényt a kódtárban. Adja meg Claude-nak, hogy mely konvenciókat kövesse, például az API-kliens, az érvényesítési logika, a hiba kezelése vagy a tesztelési struktúra tekintetében.

A „Kövesse nyomon, hogyan tölti be és tárolja az adatokat az @src/widgets/Weather.tsx” konkrét iránymutatást ad a Claude-nak. Nevezze meg továbbá az új funkció által megkövetelt eltéréseket is, hogy ne másolja át a már nem megfelelő viselkedést. Ezeknek a konvencióknak tükrözniük kell a csapata szoftverfejlesztési munkafolyamatát.

Kódmódosítások esetén adja meg a vonatkozó teszt-, build- vagy lint-parancsot, valamint azt a viselkedést, amelyet ellenőriznie kell. Kutatás céljából kérjen fájlhivatkozásokat vagy commit-azonosítókat. Felhasználói felületi munkákhoz adjon meg egy referencia képet és egy konfigurált módszert az implementáció ugyanazon a nézőtéren történő rögzítéséhez.

Kérje meg a Claude-ot, hogy jelentse, mit ellenőrzött valójában, beleértve a hibákat és az elhagyott ellenőrzéseket is. Ellenőrizze, hogy a bizonyítékok kielégítik-e a követelményeket; egy sikeres összeállítás még nem bizonyítja, hogy minden kért viselkedés működik.

Hosszabb feladatok esetén a Claude Code /goal feltételt és Stop hookokat is kínál. A célértékelő a beszélgetés során felszínre került bizonyítékokat értékeli, ahelyett, hogy önállóan vizsgálná a fájlokat vagy futtatná a teszteket. A beállított Stop hook megakadályozhatja a feladat befejezését, de a ismételt blokkolásnak vannak korlátai. Egyik sem helyettesíti a megfelelő teszteket és az emberi felülvizsgálatot.

Ha az ismételt javítások sem oldják meg a problémát, állj meg, és derítsd ki, mi maradt tisztázatlan az eredeti kérésben. Mielőtt törölnéd a beszélgetést, mentsd el a hasznos megállapításokat, a Git aktuális állapotát és a hátralévő feladatokat.

Az Anthropic legjobb gyakorlatokról szóló útmutatója azt javasolja, hogy ha ugyanazon probléma megoldására tett két kísérlet sikertelen volt, kezdje elölről. Használja a /clear parancsot, majd adjon meg egy módosított utasítást, amely tartalmazza a tanulságokat. A beszélgetés törlése nem vonja vissza a fájlokban végzett módosításokat.

Nyomd meg az Esc gombot a futó válasz megszakításához. Ha a parancssor üres, nyomd meg kétszer az Esc gombot a visszatekerés menü megnyitásához, és válaszd ki, mit szeretnél visszaállítani. A visszatekerés nem vonja vissza minden külső hatást, ezért használj Git ellenőrzőpontokat és külön helyreállítási eljárásokat az adatbázisokban vagy távoli szolgáltatásokban végzett módosítások esetén.

Mentse el a projekt egészére vonatkozó útmutatásokat a CLAUDE.md fájlba, az ismétlődő eljárásokat a skills fájlokba, az egyes fájlokra vonatkozó utasításokat pedig az elérési út hatókörű szabályokba. Használjon hookokat az egyes eseményekhez kötött műveletekhez, például egy formázó futtatásához szerkesztés után.

Válasszon aszerint, hogy mikor kell az utasítást alkalmazni:

Egy funkcióra vonatkozó követelmény általában a hozzá tartozó feladatleírásba vagy specifikációba tartozik, nem pedig a CLAUDE.md fájlba. Ha ideiglenes utasításokat adunk hozzá egy projekt-szintű fájlhoz, azok nehezebben különböztethetők meg a teljes kódtárra érvényes konvencióktól.

Például tárold a projekt tesztparancsát a CLAUDE.md fájlban, helyezd el a komponensekre vonatkozó konvenciókat egy elérési út hatályú szabályba, és mentsd el az ismétlődő felülvizsgálati eljárást készségként. Ha a parancsok vagy a konvenciók megváltoznak, nézd át ezeket a fájlokat, ahogyan azt a projekt egyéb dokumentációja esetében is tennéd.

A promptok, a CLAUDE.md fájl és a készségek irányítják a Claude viselkedését; ezek azonban nem garantálják, hogy egy utasítást biztosan végrehajt. A hookok konfigurált eseményekkor ellenőrzéseket futtathatnak, de megbízhatóságuk a hook típusától és megvalósításától függ.

A parancs-hook egy szkriptet futtat. A prompt- vagy ügynök-hook egy modell ítéletére támaszkodik. Ahogyan az Anthropic legjobb gyakorlatokról szóló útmutatója kifejti: „A prompt- vagy ügynök-hook egy másik modellt kér meg a döntés meghozatalára, így ez sem determinisztikus.” Egy olyan szabály esetében, amelyet be kell tartani, használjon megfelelő jogosultsági ellenőrzéseket, és tesztelje a vonatkozó parancs- vagy HTTP-hookot, beleértve azt is, hogyan kezeli a hibákat.

Az egyéni alügynökök egy másik módja az ismétlődő feladatok szervezésének. Ha különálló felülvizsgálati szerepkörre vagy eszközhatárokra van szükség, határozzon meg egy szakértőt a `.claude/agents/` könyvtárban, ahelyett, hogy minden szakértői utasítást a fő munkamenethez adna hozzá. Ezek az útmutatók a munkához legalkalmasabb Claude-modellről és az AI-ügynökök típusairól további háttérinformációkat nyújtanak.

Ha a csapata több AI-termékben is kezel promptokat, tekintse meg ezeket a prompt-tervező eszközöket a Claude Code-on túli könyvtárak kezeléséhez.

Ha egy munkamenet hiányos vagy nem megfelelő eredményt hoz, ellenőrizze, hogy a kérés során maradtak-e megoldatlan fontos döntések. Ez az öt hiba megnehezítheti a munka diagnosztizálását és felülvizsgálatát.

A „Vizsgáld meg a lerakatot” utasítás nem ad elég iránymutatást a Claude-nak arról, hogy mely fájlok fontosak, illetve mikor kell abbahagynia a vizsgálatot. Előfordulhat, hogy egy általános összefoglalót kapsz, anélkül, hogy választ kapnál a kérés alapjául szolgáló problémára.

Nevezze meg azt a viselkedést vagy döntést, amelyet meg kell értenie, határozza meg a kiindulási pontot, és határozza meg a várt kimenetet. Például: „Kövesse nyomon, hogyan ellenőrzi ez az végpont a jogosultságokat, és sorolja fel a vonatkozó függvényeket.” Ha alügynököket használ, mindegyiknek adjon egy határolt kérdést, ahelyett, hogy ugyanazt a korlátlan keresést delegálná rájuk.

Ha egy funkció, egy ahhoz nem kapcsolódó hiba és egy dokumentációs kérés között váltunk, a beszélgetés olyan kontextust hordoz, amely nem feltétlenül vonatkozik az aktuális feladatra. Az olyan hivatkozások, mint „az a fájl” vagy „a korábbi megközelítés”, kétértelművé válnak.

Használj külön munkameneteket az egymástól független feladatokhoz. Ha több munkamenet is szerkeszti a repositoryt, használj külön Git munkakönyvtárakat, hogy ne módosítsák ugyanazt a munkakönyvtárat. Egy rövid mellékes kérdés: a Claude Code /btw parancsa a fő beszélgetési előzményekből kizárja a cserét.

Előfordulhat, hogy egy build sikeresen lefut, miközben egy funkció helytelenül viselkedik. Előfordulhat, hogy egy tesztcsomag sikeresen lefut, mert soha nem futtatta le a hibás bemenetet. Ha megkérjük Claude-ot, hogy „futtassa le a teszteket”, az nem jelenti azt, hogy kiderül, melyik követelményt ellenőrzik azok a tesztek.

Rendelje hozzá az elfogadási kritériumokat a konkrét ellenőrzésekhez. Hiba kijavítása esetén kérjen bizonyítékot arra, hogy a reprodukciós teszt a módosítás előtt sikertelen volt, utána pedig sikeres lett. Tartsa szem előtt a még nem tesztelt kritériumokat, ahelyett, hogy egyetlen sikeres parancsot venné a teljes módosítás igazolásának.

Egy folyamatosan bővülő CLAUDE.md fájl elavult parancsokat, ismétlődő szabályokat és a feladatspecifikus követelményekkel ellentmondó utasításokat tartalmazhat. Ezeket az ellentmondásokat nem oldja meg a szöveg szigorúbb megfogalmazása.

Hasonlítsa össze a fájlt az aktuális kódtárral. Távolítsa el az elavult útmutatásokat, tisztázza az egymással ütköző szabályokat, és helyezze át a szűk körben alkalmazható utasításokat útvonal-hatályú szabályokba vagy készségekbe. Ha egy követelmény betartatására van szükség, konfigurálja és tesztelje a megfelelő ellenőrző mechanizmusokat, ahelyett, hogy ismételt emlékeztetőkre támaszkodna.

Egy kódáttekintés során egyszerre derülhetnek ki valódi hibák, bizonytalan problémák és opcionális refaktorálási javaslatok. Az összes javaslat alkalmazása megnövelheti a változtatások mértékét anélkül, hogy javítaná a kívánt viselkedést.

Kérdezze meg az egyes megállapítások mögött álló bizonyítékokat és hatásokat. Rangsorolja a helyességi problémákat és a nem teljesített követelményeket, vizsgálja meg a bizonytalan állításokat, és tartsa távol a jelenlegi diff-től a nem kapcsolódó fejlesztéseket. A felülvizsgálónak képesnek kell lennie arra, hogy ne jelentsen cselekvésre okot adó megállapításokat, ha a bizonyítékok alátámasztják ezt a következtetést.

A sablon testreszabásához cserélje ki a helyőrzőket a projekt adataival, és döntse el, mit kell tennie a Claude-nak, mielőtt módosításokat hajtana végre. Kövesse ezeket a lépéseket a kérés előkészítéséhez és az eredmény ellenőrzéséhez.

Egy kis, jól meghatározott változtatás esetén megkérheted Claude-ot, hogy közvetlenül hajtsa végre azt. Ismeretlen kód, több fájlt érintő változtatások vagy tisztázatlan követelmények esetén kezdj egy tervvel!

Nyomja meg a Shift+Tab billentyűkombinációt, amíg meg nem jelenik a Tervezési mód, vagy indítsa el a Claude Code-ot a claude --permission-mode plan paranccsal. Ebben a módban a Claude átvizsgálhatja a fájlokat és olvasási joggal rendelkező parancsokat futtathat anélkül, hogy szerkesztené a forráskódot. Tekintse át a javasolt fájlokat, függőségeket és teszteket, mielőtt jóváhagyná a megvalósítást. Nyomja meg a Ctrl+G billentyűkombinációt a javasolt terv megnyitásához a szerkesztőjében.

Adja meg Claude-nak a feladat megértéséhez szükséges információkat: fájlhivatkozást, megtisztított hibajelentést, képernyőképet vagy követelménydokumentumot. A @ jel után írja be a fájl elérési útját, hogy beilleszthesse a fájl tartalmát.

Válassza ki a források legkisebb hasznos halmazát. Egy teljes napló vagy könyvtár bevonása irreleváns anyagot eredményezhet, és elvonhatja a figyelmet a kontextusról. A naplók megosztása előtt távolítsa el a hitelesítő adatokat és az érzékeny információkat, és ellenőrizze, hogy a Claude rendelkezik-e a szükséges eszközökkel az Ön által megadott dokumentációs URL-ek lekéréséhez.

Például a cat error.log | claude -p "Explain this error" parancs egy nem interaktív kéréssel küldi el a naplófájlt. Csak a fájl tartalmának ellenőrzése után használja! Ez a kontextusfüggő mesterséges intelligencia gyakorlati értéke: releváns információkat ad a modellnek a feladat elvégzéséhez.

Funkció hozzáadásakor keressen meg egy hasonló komponenst vagy függvényt a kódtárban. Adja meg Claude-nak, hogy mely konvenciókat kövesse, például az API-kliens, az érvényesítési logika, a hiba kezelése vagy a tesztelési struktúra tekintetében.

A „Kövesse nyomon, hogyan tölti be és tárolja az adatokat a @src/widgets/Weather.tsx” konkrét támpontot ad a Claude-nak. Nevezze meg továbbá az új funkció által megkövetelt eltéréseket is, hogy ne másolja át a már nem megfelelő viselkedést. Ezeknek a konvencióknak tükrözniük kell a csapata szoftverfejlesztési munkafolyamatát.

Kódmódosítások esetén adja meg a vonatkozó teszt-, build- vagy lint-parancsot, valamint azt a viselkedést, amelyet ellenőriznie kell. Kutatás céljából kérjen fájlhivatkozásokat vagy commit-azonosítókat. Felhasználói felületi munkákhoz adjon meg egy referencia képet és egy konfigurált módszert az implementáció rögzítésére ugyanazon a nézőtéren.

Kérd meg a Claude-ot, hogy jelentse, mit ellenőrzött valójában, beleértve a hibákat és az elhagyott ellenőrzéseket is. Ellenőrizd, hogy a bizonyítékok kielégítik-e a követelményeket; egy sikeres összeállítás még nem bizonyítja, hogy minden kért viselkedés működik.

Hosszabb feladatok esetén a Claude Code /goal feltételt és Stop hookokat is kínál. A célértékelő a beszélgetés során felszínre került bizonyítékokat értékeli, ahelyett, hogy önállóan vizsgálná a fájlokat vagy futtatná a teszteket. A beállított Stop hook megakadályozhatja a feladat befejezését, de a ismételt blokkolásnak vannak korlátai. Egyik sem helyettesíti a megfelelő teszteket és az emberi felülvizsgálatot.

Ha az ismételt javítások sem oldják meg a problémát, állj meg, és derítsd ki, mi maradt tisztázatlan az eredeti kérésben. Mielőtt törölnéd a beszélgetést, mentsd el a hasznos megállapításokat, a Git aktuális állapotát és a hátralévő feladatokat.

Az Anthropic legjobb gyakorlatokról szóló útmutatója azt javasolja, hogy ha ugyanazon probléma megoldására tett két kísérlet sikertelen volt, kezdje elölről. Használja a /clear parancsot, majd adjon meg egy módosított utasítást, amely tartalmazza a tanulságokat. A beszélgetés törlése nem vonja vissza a fájlokban végzett módosításokat.

Nyomja meg az Esc billentyűt a futó válasz megszakításához. Ha a parancssor üres, nyomja meg kétszer az Esc billentyűt a visszatekerés menü megnyitásához, majd válassza ki, mit szeretne visszaállítani. A visszatekerés nem vonja vissza minden külső hatást, ezért használjon Git ellenőrzőpontokat és külön helyreállítási eljárásokat az adatbázisokban vagy távoli szolgáltatásokban végzett módosítások esetén.

Mentse el a projekt egészére vonatkozó útmutatásokat a CLAUDE.md fájlba, az ismétlődő eljárásokat a skills fájlokba, az egyes fájlokra vonatkozó utasításokat pedig az elérési út hatókörű szabályokba. Használjon hookokat az egyes eseményekhez kötött műveletekhez, például egy formázó futtatásához szerkesztés után.

Válasszon aszerint, hogy mikor kell az utasítást alkalmazni:

Egy funkcióra vonatkozó követelmény általában a hozzá tartozó feladatleírásban vagy specifikációban szerepel, nem pedig a CLAUDE.md fájlban. Ha ideiglenes utasításokat adunk hozzá egy projekt-szintű fájlhoz, azok nehezebben különböztethetők meg a teljes kódtárra érvényes konvencióktól.

Például tárold a projekt tesztparancsát a CLAUDE.md fájlban, helyezd el a komponensspecifikus konvenciókat egy elérési út hatályú szabályba, és mentsd el az ismétlődő felülvizsgálati eljárást készségként. Ha a parancsok vagy a konvenciók megváltoznak, ellenőrizd ezeket a fájlokat, ahogyan azt a projekt egyéb dokumentációja esetében is tennéd.

A promptok, a CLAUDE.md fájl és a készségek irányítják a Claude viselkedését; ezek azonban nem garantálják, hogy egy utasítást biztosan végrehajt. A hookok konfigurált eseményekkor ellenőrzéseket futtathatnak, de megbízhatóságuk a hook típusától és megvalósításától függ.

A parancs-hook egy szkriptet futtat. A prompt- vagy ügynök-hook egy modell ítéletére támaszkodik. Ahogyan az Anthropic legjobb gyakorlatokról szóló útmutatója kifejti: „A prompt- vagy ügynök-hook egy másik modellt kér meg a döntés meghozatalára, így ez sem determinisztikus.” Egy olyan szabály esetében, amelyet be kell tartani, használjon megfelelő jogosultsági ellenőrzéseket, és tesztelje a vonatkozó parancs- vagy HTTP-hookot, beleértve azt is, hogyan kezeli a hibákat.

Az egyéni alügynökök egy másik módja az ismétlődő feladatok szervezésének. Ha különálló felülvizsgálati szerepkörre vagy eszközhatárokra van szükség, határozzon meg egy szakértőt a `.claude/agents/` könyvtárban, ahelyett, hogy minden szakértői utasítást a fő munkamenethez adna hozzá. Ezek az útmutatók a munkához legalkalmasabb Claude-modellről és az AI-ügynökök típusairól további háttérinformációkat nyújtanak.

Ha a csapata több AI-termékben is kezel promptokat, tekintse meg ezeket a prompt-tervező eszközöket a Claude Code-on túli könyvtárak kezeléséhez.

Ha egy munkamenet hiányos vagy nem megfelelő eredményt hoz, ellenőrizze, hogy a kérés során maradtak-e megoldatlan fontos döntések. Ez az öt hiba megnehezítheti a munka diagnosztizálását és felülvizsgálatát.

A „Vizsgáld meg a lerakatot” utasítás nem ad elég iránymutatást a Claude-nak arról, hogy mely fájlok fontosak, illetve mikor kell abbahagynia a vizsgálatot. Előfordulhat, hogy egy általános összefoglalót kapsz, anélkül, hogy választ kapnál a kérés alapjául szolgáló problémára.

Nevezze meg azt a viselkedést vagy döntést, amelyet meg kell értenie, határozza meg a kiindulási pontot, és határozza meg a várt kimenetet. Például: „Kövesse nyomon, hogyan ellenőrzi ez az végpont a jogosultságokat, és sorolja fel a vonatkozó függvényeket.” Ha alügynököket használ, adjon mindegyiknek egy határolt kérdést, ahelyett, hogy ugyanazt a korlátlan keresést delegálná rájuk.

Ha egy funkció, egy ahhoz nem kapcsolódó hiba és egy dokumentációs kérés között váltunk, a beszélgetés olyan kontextust hordoz, amely nem feltétlenül vonatkozik az aktuális feladatra. Az olyan hivatkozások, mint „az a fájl” vagy „a korábbi megközelítés”, kétértelművé válnak.

Használj külön munkameneteket az egymástól független feladatokhoz. Ha több munkamenet is szerkeszti a repositoryt, használj külön Git munkakönyvtárakat, hogy ne módosítsák ugyanazt a munkakönyvtárat. Egy rövid mellékes kérdés: a Claude Code /btw parancsa a fő beszélgetési előzményekből kizárja a cserét.

Előfordulhat, hogy egy build sikeresen lefut, miközben egy funkció helytelenül viselkedik. Előfordulhat, hogy egy tesztcsomag sikeresen lefut, mert soha nem futtatta le a hibás bemenetet. Ha megkérjük Claude-ot, hogy „futtassa le a teszteket”, az nem jelenti azt, hogy kiderül, melyik követelményt ellenőrzik azok a tesztek.

Rendeld hozzá az elfogadási kritériumokat a konkrét ellenőrzésekhez. Hiba kijavítása esetén kérj bizonyítékot arra, hogy a reprodukciós teszt a módosítás előtt sikertelen volt, utána pedig sikeres lett. Tartsd szem előtt a még nem tesztelt kritériumokat, ahelyett, hogy egyetlen sikeres parancsot vennél a teljes módosítás igazolásának.

Egy folyamatosan bővülő CLAUDE.md fájl elavult parancsokat, ismétlődő szabályokat és a feladatspecifikus követelményekkel ellentmondó utasításokat tartalmazhat. Ezeket az ellentmondásokat nem oldja meg a szöveg szigorúbb megfogalmazása.

Hasonlítsa össze a fájlt az aktuális kódtárral. Távolítsa el az elavult útmutatásokat, tisztázza az egymással ütköző szabályokat, és helyezze át a szűk körben alkalmazható utasításokat útvonal-hatályú szabályokba vagy készségekbe. Ha egy követelmény betartatására van szükség, konfigurálja és tesztelje a megfelelő ellenőrző mechanizmusokat, ahelyett, hogy ismételt emlékeztetőkre támaszkodna.

Egy kódáttekintés során egyszerre derülhetnek ki valódi hibák, bizonytalan problémák és opcionális refaktorálási javaslatok. Az összes javaslat alkalmazása megnövelheti a változtatások mértékét anélkül, hogy javítaná a kívánt viselkedést.

Kérdezze meg az egyes megállapítások mögött álló bizonyítékokat és hatásokat. Rangsorolja a helyességi problémákat és a nem teljesített követelményeket, vizsgálja meg a bizonytalan állításokat, és tartsa távol a jelenlegi diff-től a nem kapcsolódó fejlesztéseket. A felülvizsgálónak képesnek kell lennie arra, hogy ne jelentsen cselekvésre okot adó megállapításokat, ha a bizonyítékok alátámasztják ezt a következtetést.