Claude Code-prompter: 25 färdiga prompter och hur du skriver dina egna

Kunder som använder en utgången kupong får ett 500-fel vid utcheckningen. Granska @src/checkout/coupons.ts och dess tester. Det förväntade beteendet är ett meddelande om ogiltig kupong utan att en beställning skapas. Skriv ett test som misslyckas och som återger felet, och åtgärda sedan felet utan att ändra beteendet för giltiga kuponger. Kör [checkout test command] och visa resultaten före och efter. Om du inte kan återge felet, rapportera vad du har kontrollerat innan du ändrar implementeringen.

Lägg till en datumväljare till [bokningsformulärets sökväg]. Följ komponent- och valideringskonventionerna i @src/components/TimeSelect.tsx. Användare måste kunna välja [tillåtna datum], medan [otillgängliga datum] förblir inaktiverade. Lägg inte till några bibliotek. Kör [komponenttestkommandot] och [typkontrollkommandot] och rapportera eventuella kriterier som dessa kontroller inte täcker.

Dela upp @src/reports/export.py i mindre funktioner samtidigt som du bevarar dess indata, utdataformat och felhantering. Kör [export test command] innan du redigerar och rapportera eventuella befintliga fel. Efter omstruktureringen, kör testerna igen och visa båda resultaten. Ändra inte det offentliga gränssnittet eller filer som inte är relaterade.

”Claude testar varje enskild ändring jag lägger in på claude.ai/code med hjälp av Claude-tillägget för Chrome. Det öppnar en webbläsare, testar användargränssnittet och upprepar processen tills koden fungerar och användarupplevelsen känns bra. ”

Granska README-filen, projektkonfigurationen och den översta katalogstrukturen i detta arkiv. Följ referenser endast i den utsträckning som behövs för att förklara: Vad applikationen gör, dess huvudsakliga ingångspunkter och viktigaste komponenter, var testerna finns och vilka kommandon arkivet definierar för att köra dem. Ange de filvägar som stöder din förklaring. Skilj mellan dokumenterat beteende och dina egna slutsatser, och markera allt du inte kan avgöra. Läs inte hemliga filer eller miljöfiler, granska inte installerade beroenden och ändra inga filer. Avsluta med de tre filer jag bör läsa först och varför.

Granska Git-historiken för [fil, funktion eller klass] med fokus på [beteende eller designfråga]. Identifiera de commit som införde eller väsentligt ändrade detta beteende. För varje relevant commit ska du ange dess hash, sammanfatta ändringen och förklara eventuella motiveringar som dokumenterats i commit-meddelandet eller i en länkad diskussion som du har tillgång till. Märk antagna orsaker som antaganden. Om historiken inte förklarar ett beslut, ange detta. Ändra inte filer eller Git-historiken.

Spåra vad som händer när [användaråtgärd eller systemhändelse] inträffar, med start i [känd rutt, hanterare eller mapp]. Följ de relevanta anropen genom validering, affärslogik och eventuella databasskrivningar eller externa förfrågningar. Lista filerna och funktionerna i exekveringsordning, med radreferenser där sådana finns tillgängliga. Förklara de viktigaste felvägarna och identifiera befintliga tester som täcker flödet. Markera alla anslutningar som du inte kan bekräfta utifrån koden. Kör inte flödet, anropa inte externa tjänster och redigera inte filer.

Planera hur [funktionen] ska implementeras i [repositoryområdet]. Det förväntade beteendet är [krav], och följande områden måste förbli oförändrade: [begränsningar]. Granska relevant kod och befintliga tester. Identifiera vilka filer som behöver ändras, implementeringsordningen samt eventuella risker gällande kompatibilitet eller datamigrering. Koppla varje krav till ett föreslaget test eller annat verifieringssteg. Lista olösta frågor och antaganden separat. Implementera inte funktionen ännu. Skicka tillbaka planen så att jag kan granska den.

Jag vill bygga [kort beskrivning] för [användare och användningsfall]. Läs först [relevanta filer eller krav], använd sedan AskUserQuestion för att klargöra beslut som väsentligt skulle påverka implementeringen. Fokusera på gränsfall, datahantering, behörigheter, förväntat beteende i användargränssnittet och avvägningar. Ställ inga frågor som redan besvaras av det angivna sammanhanget. När de viktigaste besluten är fattade, utarbeta en specifikation som täcker krav, acceptanskriterier, begränsningar och vad som ligger utanför omfattningen. Markera eventuella kvarvarande antaganden. Visa mig specifikationen innan du sparar den i [specifikationssökväg], och skriv inte över en befintlig fil utan godkännande.

Utvärdera konsekvenserna av att ändra [funktion, komponent eller gränssnitt] från [nuvarande beteende] till [föreslaget beteende]. Sök i [repository eller katalog] efter dess definition, direkta anropare, importer och relaterade tester. Lista de filer som sannolikt behöver ändras och förklara hur var och en kan påverkas, med fil- och radreferenser där sådana finns tillgängliga. Markera dynamiskt upplösta anrop, externa användare eller andra beroenden som du inte kan verifiera. Identifiera eventuella kompatibilitetsfrågor som behöver besvaras före implementeringen. Ändra inte filerna; skicka in konsekvensbedömningen och vänta på min granskning.

Lägg till [funktion] i [fil eller sida] med följande beteende: [acceptanskriterier]. Granska [befintlig implementering] och följ dess konventioner för att hämta data, hantera fel och organisera komponenter. Använd endast bibliotek som redan är installerade i projektet. Håll ändringarna inom [omfattningen] och bevara [befintligt beteende eller offentligt gränssnitt]. Lägg till eller uppdatera tester för acceptanskriterierna. Kör [testkommando] och [typkontroll- eller lint-kommando], och rapportera sedan de ändrade filerna, resultaten och eventuella kontroller som du inte kunde slutföra. Om det befintliga mönstret står i konflikt med ett krav, förklara konflikten innan du fortsätter.

Implementera [funktionsnamn] i [fil] för att uppfylla [krav]. Täck [normala fall], [gränsfall] och [beteende vid ogiltig indata]. Kör [relevant testkommando] först och rapportera eventuella befintliga fel. Skriv tester för det önskade beteendet och kör dem sedan före implementeringen. Bekräfta att de nya testerna misslyckas av den förväntade anledningen. Implementera funktionen och kör testerna på nytt. Försvaga inte påståenden, hoppa inte över tester och ändra inte det förväntade beteendet för att få dem att godkännas. Om kraven står i konflikt med befintliga tester, avbryt och förklara konflikten. Visa resultaten före och efter.

Implementera den bifogade designen i [komponent eller sida] med hjälp av projektets befintliga komponenter och stilar. Bevara [krävt beteende] och undvik ändringar utanför [omfattningen]. Använd [konfigurerad webbläsare eller skärmdumpsverktyg] för att fånga [lokal rutt] vid [visningsområdets dimensioner] med [testdata och UI-tillstånd]. Om verktyget eller applikationen inte är tillgänglig, rapportera vad som behövs istället för att ange att en visuell kontroll har gjorts. Jämför skärmdumpen med referensen och fokusera på [layout, avstånd, typografi eller andra godkännandekriterier]. Gör upp till [antal] korrigeringsomgångar och rapportera sedan de återstående skillnaderna. Ändra inte referensbilden. Kör [relevanta komponenttester] och [typkontroll eller byggkommando]. Inkludera den tagna skärmdumpen och de faktiska kontrollresultaten i din sammanfattning.

Användare upplever [symptom] när [utlösare eller indata]. Det förväntade beteendet är [förväntat resultat]. Börja med att granska [mapp, funktion eller flöde] och de relaterade testerna. Skapa ett test som misslyckas och som återger det rapporterade beteendet. Om du inte kan återge det, förklara vad du har kontrollerat och vilken information som saknas innan du ändrar implementeringen. När du väl har återgivit det, åtgärda orsaken utan att ändra [beteende som måste förbli oförändrat]. Kör det nya testet och [relaterat testkommando]. Visa felet före åtgärden, resultaten efteråt och eventuella kvarvarande fel.

[Byggkommando] misslyckas i [lokal eller CI-miljö] med följande utdata: [redigerad fellogg]. Granska relevant kod och konfiguration för att identifiera orsaken. Kontrollera om det finns skillnader i miljö eller beroenden om felet inte går att återskapa lokalt. Gör den minsta ändringen som åtgärdar orsaken. Inaktivera inte kontroller, dölj inte fel, hoppa inte över tester och lätta inte på kompilatorinställningarna enbart för att få en godkänd kompilering. Kör kompileringen igen efter ändringen. Om den fortfarande misslyckas efter [antal] försök att åtgärda felet, avbryt och rapportera vad du har försökt, det aktuella felet och nästa diagnostiska steg. Sammanfatta orsaken och inkludera det faktiska kompileringsresultatet.

Hjälp mig att avgränsa ett fel innan jag föreslår en lösning. Observerat beteende: [vad som händer]Förväntat beteende: [vad som borde hända]När det inträffar: [förhållanden eller frekvens]Vad jag har provat: [steg och resultat]Ställ en fråga i taget och välj den fråga som bäst kan skilja mellan de troliga orsakerna. Upprepa inte frågor som redan besvaras av den information som lämnats. När det finns tillräckligt med bevis, sammanfatta den mest troliga förklaringen, vad som fortfarande är osäkert och det minsta testet som skulle kunna bekräfta eller utesluta den. Redigera inte filer ännu.

Använd en underagent för att granska [diff eller gren jämfört med basen] mot [godkänd plan eller kravspecifikation]. Om kraven saknas eller är tvetydiga, rapportera detta innan du bedömer fullständigheten. Kontrollera om varje krav är implementerat, om relevanta gränsfall har tester och om eventuella ändringar faller utanför den överenskomna omfattningen. Granska omgivande kod där det behövs för att förstå skillnaden. Rapportera felaktigheter och ouppfyllda krav med fil- och radreferenser, deras inverkan samt bevis som stöder varje iakttagelse. Separera bekräftade problem från olösta frågor. Hitta inte på iakttagelser för att fylla en kvot eller inkludera ovidkommande stilpreferenser. Redigera inte filer.

Granska [filer eller diff] med avseende på risker för injektion, saknade behörighetskontroller, exponerade hemligheter och osäker hantering av användarinmatning. Granska relevanta anropare och valideringslogik innan du rapporterar ett fynd. För varje problem ska du identifiera den berörda filen och raderna, de villkor som krävs för att utlösa det, den troliga påverkan samt ett förslag på åtgärd. Skilj mellan en bekräftad sårbarhet och ett problem som kräver ytterligare testning. Återge inte hemliga värden i rapporten, ändra inte filer och testa inte mot live-tjänster. Ange vilka områden du har granskat och vad som ligger utanför omfattningen.

Sammanfatta hur du verifierade den genomförda ändringen mot [acceptanskriterierna]. För varje kriterium ska du ange vilken kontroll som utfördes, det exakta kommandot där så är tillämpligt och det observerade resultatet. Inkludera relevant utdata, med hemlig information och känsliga uppgifter bortredigerade. Identifiera eventuella redan befintliga fel separat. Gör en tydlig åtskillnad mellan kontroller som godkändes, kontroller som misslyckades och kontroller som inte kördes. Förklara eventuella utelämnade kontroller eller begränsningar i täckningen. Beskriv inte hela ändringen som verifierad om vissa kriterier fortfarande inte har kontrollerats.

Omstrukturera [fil eller modul] för att uppnå [ett specifikt mål, till exempel att dela upp en stor funktion eller ta bort kapslade återanrop]. Bevara dess publika gränssnitt, returvärden, felbeteende och bieffekter. Kör [relevant testkommando] innan du redigerar för att fastställa en baslinje. Om det misslyckas, rapportera felen innan du fortsätter. Identifiera eventuellt beteende som de befintliga testerna inte täcker och lägg till riktade tester där det behövs. Genomför omstruktureringen utan ovidkommande ändringar eller nya beroenden. Försvaga inte befintliga påståenden för att anpassa dem till implementeringen. Kör testerna igen och [typkontroll eller lint-kommando]. Visa resultaten före och efter, sammanfatta de strukturella förändringarna och markera eventuellt beteende som du inte kunde verifiera.

Hitta användningar av [gammal API eller bibliotek] inom [katalogens omfattning], exklusive genererade filer och leverantörsfiler. Lista de berörda filerna samt eventuella delade konfigurationer eller beroenden som migreringen kan påverka. Föreslå tre representativa filer för en pilotmigrering till [ny API eller version] med hjälp av [migreringsguide eller befintligt exempel]. Förklara varför du valde just dessa och markera eventuella nödvändiga beteendeförändringar. Vänta på mitt godkännande innan du redigerar. Efter godkännande ska du endast migrera pilotfilerna och eventuella uttryckligen godkända delade beroenden. Kör [relevanta tester] och [kommandot för att bygga eller typkontrollera]. Utvidga inte migreringen till andra filer. Rapportera skillnaderna, testresultaten, kompatibilitetsproblem och eventuella ändringar som behövs i migreringsmetoden. Avbryt för granskning innan du fortsätter med de återstående filerna.

Granska den aktuella grenen, Git-statusen och diff för [funktion eller korrigering]. Identifiera de filer som hör till denna ändring och lista icke-relaterade eller icke-spårade filer separat. Skriv ett utkast till commit-meddelande enligt formatet för de senaste 10 commit-arna. Förbered en beskrivning av pull-förfrågan som täcker vad som har ändrats, varför, vilka tester som faktiskt har körts samt eventuella kvarstående begränsningar. Visa den föreslagna fillistan, commit-meddelandet och PR-beskrivningen innan du lägger något i staging eller publicerar något. Vänta på mitt godkännande. Efter godkännande ska du endast lägga de överenskomna filerna i staging, göra en commit på [funktionsgren], pusha till [remote] och öppna en pull request mot [basgren]. Ändra inte befintliga commits, gör inga force-pushar och gör inga sammanfogningar. Skicka tillbaka commit-hash och PR-länken.

Utarbeta ett README-avsnitt för [modul] riktat till [läsare, till exempel en backend-ingenjör som ansluter sig till projektet]. Ta upp förutsättningar, installation, de tre kommandon som de kommer att använda mest samt vanliga fel som behandlas i koden eller befintlig dokumentation. Kontrollera kommandonamn och alternativ mot [paketskript, Makefile, CLI-hjälp eller CI-konfiguration]. Markera allt du inte kan bekräfta. Testa säkra lokala kommandon i [testmiljö] där sådan finns tillgänglig. Innan du kör kommandon som installerar beroenden, raderar filer, migrerar data, distribuerar eller använder externa tjänster, förklara deras effekter och be om godkännande. Gör tydlig skillnad mellan kommandon som du har kört framgångsrikt och kommandon som endast har kontrollerats mot konfigurationen eller dokumentationen. Visa det föreslagna README-avsnittet innan du redigerar [dokumentationssökväg] och behåll innehåll som inte är relaterat.

Granska [sökväg till CLAUDE.md] mot repositoriets nuvarande struktur, skript och konventioner. Redigera inte filen ännu. Identifiera föråldrade instruktioner, dubbletter, motsägelser och regler som på ett tillförlitligt sätt kan härledas från koden. Förklara varje föreslagen borttagning istället för att stryka instruktioner enbart för att förkorta filen. Föreslå saknade bygg- eller testkommandon endast när du kan verifiera dem i projektskript, en Makefile, CI-konfiguration eller befintlig dokumentation. Ange källan för varje tillägg. Skicka in ett förslag på diff som bevarar viktiga projektbegränsningar. Markera uppgiftsspecifika instruktioner som skulle passa bättre i en regel med omfattning på en färdighet eller en väg, och vänta på godkännande innan du tillämpar ändringarna.

Föreslå en Claude Code-kommandohook som kör [befintligt formateringskommando] efter att ändringar gjorts med Edit eller Write på [filmönster]. Granska först den befintliga konfigurationen i claude/settings.json och formaterarens konfiguration. Använd lämplig PostToolUse-konfiguration för den installerade versionen av Claude Code. Formatera endast den berörda filen, hantera sökvägar på ett säkert sätt och exkludera [genererade filer eller andra exkluderade sökvägar]. Installera inga beroenden och ersätt inte befintliga hooks. Visa skillnaden mellan de föreslagna inställningarna och förklara hur fel i formateraren kommer att rapporteras. Vänta på godkännande innan du tillämpar det. Efter godkännande, testa det med en tillfällig fil i projektet och rapportera resultatet. Ange vilka redigeringsvägar det täcker och vilka det inte täcker, inklusive ändringar som gjorts via shell-kommandon.

Granska [verktyg] –help och hjälpen för underkommandon som är relevanta för [uppgift]. Installera inte verktyget om det saknas; rapportera istället den förutsättningen. Föreslå exakt vilka kommandon som behövs för att slutföra uppgiften. Förklara deras indata, utdata och om de skriver filer, ändrar fjärresurser eller använder inloggningsuppgifter. Inkludera ett alternativ för torrkörning om verktyget dokumenterar ett sådant. Markera saknad konfiguration eller behörigheter och be om förtydligande istället för att gissa resursnamn eller destinationer. Vänta på godkännande innan du kör uppgiftskommandona. Efter godkännande, kör endast de överenskomna kommandona och rapportera deras faktiska resultat, inklusive eventuella fel eller ofullständiga steg.

Jämför [invoices.csv] och [payments.csv] med hjälp av [faktura-ID eller matchningsnyckel]. Ändra inte källfilerna. Tillämpa följande regler: [valuta och avrundningstolerans], [fördelning av delbetalningar] och [hantering av återbetalningar, krediter och överbetalningar]. Om en regel saknas eller en matchning är tvetydig, markera den istället för att automatiskt tilldela betalningen. Bevara källradernas ID:n. För varje faktura ska du visa fakturabeloppet, tillämpade betalningar och återstående saldo. Rapportera dubbla ID:n, oförenliga fakturor, oförenliga betalningar och saldon utanför toleransgränsen. Avstäm faktura- och betalningssummorna separat. Redovisa varje källrad utan dubbelräkning; om en betalning är uppdelad på flera fakturor, visa varje fördelning och bekräfta att fördelningarna inte överstiger betalningen. Skriv ut resultaten till [nya utdatavägar] och sammanfatta undantag som kräver granskning.

Skriv ett skript som sammanfattar [export.csv] för perioden [startdatum och -tid, inklusive] till och med [slutdatum och -tid, exklusive], med hjälp av [tidszon] och [datums kolumn]. Gruppera posterna enligt [kategoriregler] och beräkna [nödvändiga mått]. Hantera dubbla ID:n och saknade värden enligt [regler]. Ändra inte inmatningsfilen. Kör skriptet på [exakt inmatningsfil]. Rapportera antalet inkluderade och exkluderade rader, kategorins summerade värden samt poster som inte kunde klassificeras. Jämför resultaten för [tre kategorier] med de oberoende kontrollerade siffrorna i [referensfil]. Om dessa siffror inte finns tillgängliga, ange att oberoende validering fortfarande återstår. Visa avvikelser och spara rapporten till [ny utdataväg].

Läs [angivna filer eller mappar] och utarbeta ett utkast till [dokumenttyp och längd] för [målgrupp], som täcker [frågor eller ämnen]. Underbygg varje saklig påstående med ett filnamn och en hänvisning till sida, avsnitt eller rad där sådan finns tillgänglig. Skilj mellan direkta citat och omskrivningar, och betrakta inte ett förslag eller ett föråldrat dokument som ett bekräftat aktuellt beslut. Markera motstridiga källor, saknad information och påståenden som du inte kan verifiera. Fyll inte i luckor med antaganden och redigera inte källfilerna. Lämna tillbaka utkastet med dess referenser och en kort lista över olösta frågor till granskaren.

För att anpassa en mall ersätter du platshållarna med uppgifter från ditt projekt och bestämmer vad Claude ska göra innan du gör ändringar. Följ dessa steg för att förbereda förfrågan och granska resultatet.

För en liten, väl definierad ändring kan du be Claude att genomföra den direkt. För okänd kod, ändringar som omfattar flera filer eller oklara krav bör du börja med en plan.

Tryck på Skift+Tab tills planeringsläget visas, eller starta Claude Code med claude --permission-mode plan. I det här läget kan Claude granska filer och köra skrivskyddade kommandon utan att redigera din källkod. Granska de föreslagna filerna, beroendena och testerna innan du godkänner implementeringen. Tryck på Ctrl+G för att öppna den föreslagna planen i din editor.

Ge Claude den information som behövs för att förstå uppgiften: en filreferens, en rensad fellogg, en skärmdump eller ett kravdokument. Använd @ följt av en filväg för att inkludera filens innehåll.

Välj den minsta användbara uppsättningen källor. Att inkludera en hel logg eller katalog kan tillföra irrelevant material och ta upp onödigt sammanhang. Ta bort inloggningsuppgifter och känslig information innan du delar loggar, och kontrollera att Claude har de verktyg som behövs för att hämta eventuella dokumentations-URL:er som du tillhandahåller.

Till exempel skickar kommandot `cat error.log | claude -p "Explain this error"` in en loggfil med en icke-interaktiv förfrågan. Använd det först efter att du har kontrollerat filens innehåll. Detta är det praktiska värdet med kontextuell AI: att ge modellen relevant information för uppgiften.

När du lägger till en funktion ska du identifiera en liknande komponent eller funktion i repositoriet. Ange för Claude vilka konventioner som ska följas, till exempel API-klienten, valideringslogiken, felhanteringen eller teststrukturen.

”Följ hur @src/widgets/Weather.tsx hämtar och cachelagrar data” ger Claude en konkret referens. Ange även eventuella skillnader som den nya funktionen kräver, så att den inte kopierar beteenden som inte längre passar. Dessa konventioner bör spegla ditt teams arbetsflöde för mjukvaruutveckling.

För kodändringar anger du det relevanta test-, build- eller lint-kommandot samt det beteende som ska kontrolleras. För forskning begär du filreferenser eller commit-ID:n. För arbete med användargränssnittet tillhandahåller du en referensbild och en konfigurerad metod för att fånga implementeringen i samma visningsområde.

Be Claude att rapportera vad den faktiskt har kontrollerat, inklusive fel och kontroller som har hoppats över. Granska om bevisen täcker kravet; en godkänd build innebär inte att alla begärda funktioner fungerar.

För längre uppgifter erbjuder Claude Code även ett /goal-villkor och Stop-hooks. Måluvärderaren bedömer bevis som framkommit i konversationen istället för att självständigt granska filer eller köra tester. En konfigurerad Stop-hook kan blockera slutförandet, men det finns begränsningar för upprepad blockering. Inget av dessa ersätter lämpliga tester och mänsklig granskning.

Om upprepade korrigeringar inte löser ett problem, stanna upp och identifiera vad som var oklart i den ursprungliga förfrågan. Spara användbara iakttagelser, aktuell Git-status och återstående arbete innan du rensar konversationen.

Anthropics guide till bästa praxis rekommenderar att man börjar om från början efter två misslyckade korrigeringar av samma problem. Använd /clear och ange sedan en reviderad prompt som inkluderar det du har lärt dig. Att rensa konversationen ångrar inte filändringar.

Tryck på Esc för att avbryta ett pågående svar. När inmatningsfältet är tomt trycker du två gånger på Esc för att öppna återgångsmenyn och välja vad som ska återställas. Återgången ångrar inte alla externa effekter, så använd Git-kontrollpunkter och separata återställningsprocedurer för ändringar i databaser eller fjärrtjänster.

Spara projektövergripande riktlinjer i CLAUDE.md, repeterbara procedurer i färdigheter och instruktioner för specifika filer i regler med sökvägsomfång. Använd krokar för åtgärder kopplade till specifika händelser, till exempel att köra ett formateringsverktyg efter en redigering.

Välj utifrån när instruktionen ska gälla:

Ett krav för en funktion hör vanligtvis hemma i dess uppgiftsprompt eller specifikation, snarare än i CLAUDE.md. Att lägga till tillfälliga instruktioner i en projektomfattande fil gör det svårare att skilja dem från konventioner som bör gälla i hela repositoriet.

Se till exempel till att projektets testkommando finns i CLAUDE.md, placera komponentspecifika konventioner i en regel med sökvägsomfång och spara en återkommande granskningsprocedur som en färdighet. Granska dessa filer när kommandon eller konventioner ändras, precis som du skulle göra med annan projektdokumentation.

Promptar, CLAUDE.md och färdighetsguider styr Claudes beteende; de garanterar inte att en instruktion kommer att följas. Hooks kan utföra kontroller vid konfigurerade händelser, men deras tillförlitlighet beror på hook-typen och implementeringen.

En kommandohook kör ett skript. En prompt- eller agenthook förlitar sig på en modells bedömning. Som det förklaras i Anthropics guide till bästa praxis: ”En prompt- eller agenthook ber en annan modell att fatta ett beslut, så den är inte heller deterministisk.” För en regel som måste tillämpas ska du använda lämpliga behörighetskontroller och testa den relevanta kommando- eller HTTP-hooken, inklusive hur den hanterar fel.

Anpassade underagenter är ett annat sätt att organisera återkommande arbetsuppgifter. Definiera en specialist i in.claude/agents/ när det behövs en särskild granskningsroll eller ett specifikt verktygsomfång, istället för att lägga till varje specialistinstruktion i huvudsessionen. Dessa guider till den bästa Claude-modellen för arbete och olika typer av AI-agenter ger ytterligare sammanhang.

Om ditt team hanterar prompter för flera olika AI-produkter kan du ta en titt på dessa verktyg för promptutveckling för att hantera bibliotek utöver Claude Code.

När en session ger ett ofullständigt eller olämpligt resultat, kontrollera om begäran lämnade viktiga beslut olösta. Dessa fem misstag kan göra arbetet svårare att diagnostisera och granska.

”Undersök arkivet” ger Claude väldigt lite vägledning om vilka filer som är viktiga eller när den ska sluta. Du kan få en allmän sammanfattning utan något svar på det problem som låg till grund för förfrågan.

Namnge det beteende eller beslut som du behöver förstå, identifiera en startpunkt och definiera det förväntade resultatet. Till exempel: ”Spåra hur denna slutpunkt kontrollerar behörigheter och ange de relevanta funktionerna.” Om du använder underagenter, ge var och en en avgränsad fråga istället för att delegera samma obegränsade sökning.

När man växlar mellan en funktion, ett icke-relaterat fel och en dokumentationsförfrågan kan konversationen behålla ett sammanhang som kanske inte är relevant för den aktuella uppgiften. Referenser som ”den filen” eller ”det tidigare tillvägagångssättet” blir tvetydiga.

Använd separata sessioner för arbete som inte hänger ihop. Om flera sessioner ska redigera repositoriet, använd separata Git-arbetsträd så att de inte ändrar samma arbetskatalog. En kort sidokommentar: Claude Codes /btw-kommando håller utväxlingen borta från den huvudsakliga konversationshistoriken.

En kompilering kan godkännas även om en funktion beter sig felaktigt. En testserie kan godkännas eftersom den aldrig har testat den felaktiga indata. Att be Claude att ”köra testerna” klargör inte vilka krav dessa tester verifierar.

Koppla acceptanskriterierna till specifika kontroller. Vid en buggfix ska du begära bevis på att reproduktionstestet misslyckades före ändringen och godkändes efteråt. Håll otestade kriterier synliga istället för att betrakta ett lyckat kommando som verifiering av hela ändringen.

En växande CLAUDE.md-fil kan innehålla föråldrade kommandon, dubbla regler och instruktioner som strider mot uppgiftsspecifika krav. Att lägga till starkare formuleringar löser inte dessa konflikter.

Jämför filen med det aktuella arkivet. Ta bort föråldrade riktlinjer, förtydliga motstridiga regler och flytta instruktioner med snäv tillämpning till regler eller färdigheter med sökvägsomfång. Om ett krav måste uppfyllas, konfigurera och testa lämpliga kontroller istället för att förlita dig på upprepade påminnelser.

En granskning kan avslöja både verkliga fel, osäkra problem och valfria förslag på omstrukturering. Att tillämpa alla förslag kan leda till omfattande ändringar utan att det önskade beteendet förbättras.

Be om belägg och redogör för konsekvenserna bakom varje iakttagelse. Prioritera felaktigheter och ouppfyllda krav, utred osäkra påståenden och håll icke-relaterade förbättringar borta från den aktuella diff-filen. En granskare bör kunna rapportera att det inte finns några åtgärdsbara iakttagelser när bevisen stöder den slutsatsen.

För att anpassa en mall ersätter du platshållarna med uppgifter från ditt projekt och bestämmer vad Claude ska göra innan du gör ändringar. Följ dessa steg för att förbereda förfrågan och granska resultatet.

För en liten, väl definierad ändring kan du be Claude att genomföra den direkt. För okänd kod, ändringar som omfattar flera filer eller oklara krav bör du börja med en plan.

Tryck på Skift+Tab tills planeringsläget visas, eller starta Claude Code med claude --permission-mode plan. I det här läget kan Claude granska filer och köra skrivskyddade kommandon utan att redigera din källkod. Granska de föreslagna filerna, beroendena och testerna innan du godkänner implementeringen. Tryck på Ctrl+G för att öppna den föreslagna planen i din editor.

Ge Claude den information som behövs för att förstå uppgiften: en filreferens, en rensad fellogg, en skärmdump eller ett kravdokument. Använd @ följt av en filväg för att inkludera filens innehåll.

Välj den minsta användbara uppsättningen källor. Att inkludera en hel logg eller katalog kan leda till att irrelevant material läggs till och ta upp onödigt utrymme. Ta bort inloggningsuppgifter och känslig information innan du delar loggar, och kontrollera att Claude har de verktyg som behövs för att hämta eventuella dokumentations-URL:er som du tillhandahåller.

Till exempel skickar kommandot `cat error.log | claude -p "Explain this error"` in en loggfil med en icke-interaktiv förfrågan. Använd det först efter att du har kontrollerat filens innehåll. Detta är det praktiska värdet med kontextuell AI: att ge modellen relevant information för uppgiften.

När du lägger till en funktion ska du identifiera en liknande komponent eller funktion i repositoriet. Ange för Claude vilka konventioner som ska följas, till exempel API-klienten, valideringslogiken, felhanteringen eller teststrukturen.

”Följ hur @src/widgets/Weather.tsx hämtar och cachelagrar data” ger Claude en konkret referens. Ange även eventuella skillnader som den nya funktionen kräver, så att den inte kopierar beteenden som inte längre passar. Dessa konventioner bör återspegla ditt teams arbetsflöde för mjukvaruutveckling.

För kodändringar anger du det relevanta test-, build- eller lint-kommandot samt det beteende som ska kontrolleras. För forskning begär du filreferenser eller commit-ID:n. För arbete med användargränssnittet tillhandahåller du en referensbild och en konfigurerad metod för att fånga implementeringen i samma visningsområde.

Be Claude att rapportera vad den faktiskt har kontrollerat, inklusive fel och kontroller som har hoppats över. Granska om bevisen täcker kravet; en godkänd build innebär inte att alla begärda funktioner fungerar.

För längre uppgifter erbjuder Claude Code även ett /goal-villkor och Stop-hooks. Måluvärderaren bedömer bevis som framkommit i konversationen istället för att självständigt granska filer eller köra tester. En konfigurerad Stop-hook kan blockera slutförandet, men det finns begränsningar för upprepad blockering. Inget av dessa ersätter lämpliga tester och mänsklig granskning.

Om upprepade korrigeringar inte löser ett problem, stanna upp och identifiera vad som var oklart i den ursprungliga förfrågan. Spara användbara iakttagelser, aktuell Git-status och återstående arbete innan du rensar konversationen.

Anthropics guide till bästa praxis rekommenderar att man börjar om från början efter två misslyckade korrigeringar av samma problem. Använd /clear och ange sedan en reviderad prompt som inkluderar det du har lärt dig. Att rensa konversationen ångrar inte filändringar.

Tryck på Esc för att avbryta ett pågående svar. När inmatningsfältet är tomt trycker du två gånger på Esc för att öppna återgångsmenyn och välja vad som ska återställas. Återgången ångrar inte alla externa effekter, så använd Git-kontrollpunkter och separata återställningsprocedurer för ändringar i databaser eller fjärrtjänster.

Spara projektövergripande riktlinjer i CLAUDE.md, repeterbara procedurer i färdigheter och instruktioner för specifika filer i regler med sökvägsomfång. Använd krokar för åtgärder kopplade till specifika händelser, till exempel att köra ett formateringsverktyg efter en redigering.

Välj utifrån när instruktionen ska gälla:

Ett krav för en funktion hör vanligtvis hemma i dess uppgiftsprompt eller specifikation, snarare än i CLAUDE.md. Att lägga till tillfälliga instruktioner i en projektomfattande fil gör det svårare att skilja dem från konventioner som bör gälla i hela repositoriet.

Se till exempel till att projektets testkommando finns i CLAUDE.md, placera komponentspecifika konventioner i en regel med sökvägsomfång och spara en återkommande granskningsprocedur som en färdighet. Granska dessa filer när kommandon eller konventioner ändras, precis som du skulle göra med annan projektdokumentation.

Promptar, CLAUDE.md och färdighetsguider styr Claudes beteende; de garanterar inte att en instruktion kommer att följas. Hooks kan utföra kontroller vid konfigurerade händelser, men deras tillförlitlighet beror på hook-typen och implementeringen.

En kommandohook kör ett skript. En prompt- eller agenthook förlitar sig på en modells bedömning. Som det förklaras i Anthropics guide till bästa praxis: ”En prompt- eller agenthook ber en annan modell att fatta ett beslut, så den är inte heller deterministisk.” För en regel som måste tillämpas ska du använda lämpliga behörighetskontroller och testa den relevanta kommando- eller HTTP-hooken, inklusive hur den hanterar fel.

Anpassade underagenter är ett annat sätt att organisera återkommande arbetsuppgifter. Definiera en specialist i claude/agents/ när det krävs en särskild granskningsroll eller ett specifikt verktygsomfång, istället för att lägga till varje specialistinstruktion i huvudsessionen. Dessa guider till den bästa Claude-modellen för arbete och olika typer av AI-agenter ger ytterligare sammanhang.

Om ditt team hanterar prompter för flera olika AI-produkter kan du ta en titt på dessa verktyg för promptutveckling för att hantera bibliotek utöver Claude Code.

När en session ger ett ofullständigt eller olämpligt resultat, kontrollera om begäran lämnade viktiga beslut olösta. Dessa fem misstag kan göra arbetet svårare att diagnostisera och granska.

”Undersök arkivet” ger Claude väldigt lite vägledning om vilka filer som är viktiga eller när den ska sluta. Du kan få en allmän sammanfattning utan något svar på det problem som låg till grund för förfrågan.

Namnge det beteende eller beslut som du behöver förstå, identifiera en startpunkt och definiera det förväntade resultatet. Till exempel: ”Spåra hur denna slutpunkt kontrollerar behörigheter och ange de relevanta funktionerna.” Om du använder underagenter, ge var och en en avgränsad fråga istället för att delegera samma obegränsade sökning.

När man växlar mellan en funktion, ett icke-relaterat fel och en dokumentationsförfrågan kan konversationen behålla ett sammanhang som kanske inte är relevant för den aktuella uppgiften. Referenser som ”den filen” eller ”det tidigare tillvägagångssättet” blir tvetydiga.

Använd separata sessioner för arbete som inte hänger ihop. Om flera sessioner ska redigera repositoriet, använd separata Git-arbetsträd så att de inte ändrar samma arbetskatalog. En kort sidokommentar: Claude Codes /btw-kommando håller utväxlingen borta från den huvudsakliga konversationshistoriken.

En kompilering kan godkännas även om en funktion beter sig felaktigt. En testserie kan godkännas eftersom den aldrig har testat den felaktiga indata. Att be Claude att ”köra testerna” klargör inte vilka krav dessa tester verifierar.

Koppla acceptanskriterierna till specifika kontroller. Vid en buggfix ska du begära bevis på att reproduktionstestet misslyckades före ändringen och godkändes efteråt. Håll otestade kriterier synliga istället för att betrakta ett lyckat kommando som verifiering av hela ändringen.

En växande CLAUDE.md-fil kan innehålla föråldrade kommandon, dubbla regler och instruktioner som strider mot uppgiftsspecifika krav. Att lägga till starkare formuleringar löser inte dessa konflikter.

Jämför filen med det aktuella arkivet. Ta bort föråldrade riktlinjer, förtydliga motstridiga regler och flytta instruktioner med snäv tillämpning till regler eller färdigheter som gäller för en viss väg. Om ett krav måste uppfyllas, konfigurera och testa lämpliga kontroller istället för att förlita dig på upprepade påminnelser.

En granskning kan avslöja både verkliga fel, osäkra problem och valfria förslag på omstrukturering. Att tillämpa alla förslag kan leda till omfattande ändringar utan att det önskade beteendet förbättras.

Be om belägg och redogör för konsekvenserna bakom varje iakttagelse. Prioritera felaktigheter och ouppfyllda krav, utred osäkra påståenden och håll icke-relaterade förbättringar borta från den aktuella diff-filen. En granskare bör kunna rapportera att det inte finns några åtgärdsbara iakttagelser när bevisen stöder den slutsatsen.

För att anpassa en mall ersätter du platshållarna med uppgifter från ditt projekt och bestämmer vad Claude ska göra innan du gör ändringar. Följ dessa steg för att förbereda förfrågan och granska resultatet.

För en liten, väldefinierad ändring kan du be Claude att genomföra den direkt. För okänd kod, ändringar som omfattar flera filer eller oklara krav bör du börja med en plan.

Tryck på Skift+Tab tills planeringsläget visas, eller starta Claude Code med claude --permission-mode plan. I det här läget kan Claude granska filer och köra skrivskyddade kommandon utan att redigera din källkod. Granska de föreslagna filerna, beroendena och testerna innan du godkänner implementeringen. Tryck på Ctrl+G för att öppna den föreslagna planen i din editor.

Ge Claude den information som behövs för att förstå uppgiften: en filreferens, en rensad fellogg, en skärmdump eller ett kravdokument. Använd @ följt av en filväg för att inkludera filens innehåll.

Välj den minsta användbara uppsättningen källor. Att inkludera en hel logg eller katalog kan leda till att irrelevant material läggs till och ta upp onödigt utrymme. Ta bort inloggningsuppgifter och känslig information innan du delar loggar, och kontrollera att Claude har de verktyg som behövs för att hämta eventuella dokumentations-URL:er som du tillhandahåller.

Till exempel skickar kommandot `cat error.log | claude -p "Explain this error"` in en loggfil med en icke-interaktiv förfrågan. Använd det först efter att du har kontrollerat filens innehåll. Detta är det praktiska värdet med kontextuell AI: att ge modellen relevant information för uppgiften.

När du lägger till en funktion ska du identifiera en liknande komponent eller funktion i repositoriet. Ange för Claude vilka konventioner som ska följas, till exempel API-klienten, valideringslogiken, felhanteringen eller teststrukturen.

”Följ hur @src/widgets/Weather.tsx hämtar och cachelagrar data” ger Claude en konkret referens. Ange även eventuella skillnader som den nya funktionen kräver, så att den inte kopierar beteenden som inte längre passar. Dessa konventioner bör spegla ditt teams arbetsflöde för mjukvaruutveckling.

För kodändringar anger du det relevanta test-, build- eller lint-kommandot samt det beteende som ska kontrolleras. För forskning begär du filreferenser eller commit-ID:n. För arbete med användargränssnittet tillhandahåller du en referensbild och en konfigurerad metod för att fånga implementeringen i samma visningsområde.

Be Claude att rapportera vad den faktiskt har kontrollerat, inklusive fel och kontroller som har hoppats över. Granska om bevisen täcker kravet; en godkänd build innebär inte att alla begärda funktioner fungerar.

För längre uppgifter erbjuder Claude Code även ett /goal-villkor och Stop-hooks. Måluvärderaren bedömer bevis som framkommit i konversationen istället för att självständigt granska filer eller köra tester. En konfigurerad Stop-hook kan blockera slutförandet, men det finns begränsningar för upprepad blockering. Inget av dessa ersätter lämpliga tester och mänsklig granskning.

Om upprepade korrigeringar inte löser ett problem, stanna upp och identifiera vad som var oklart i den ursprungliga förfrågan. Spara användbara iakttagelser, aktuell Git-status och återstående arbete innan du rensar konversationen.

Anthropics guide till bästa praxis rekommenderar att man börjar om från början efter två misslyckade korrigeringar av samma problem. Använd /clear och ange sedan en reviderad prompt som inkluderar det du har lärt dig. Att rensa konversationen ångrar inte filändringar.

Tryck på Esc för att avbryta ett pågående svar. När inmatningsfältet är tomt trycker du två gånger på Esc för att öppna återgångsmenyn och välja vad som ska återställas. Återgången ångrar inte alla externa effekter, så använd Git-kontrollpunkter och separata återställningsprocedurer för ändringar i databaser eller fjärrtjänster.

Spara projektövergripande riktlinjer i CLAUDE.md, repeterbara procedurer i färdigheter och instruktioner för specifika filer i regler med sökvägsomfång. Använd krokar för åtgärder kopplade till specifika händelser, till exempel att köra en formaterare efter en redigering.

Välj utifrån när instruktionen ska gälla:

Ett krav för en funktion hör vanligtvis hemma i dess uppgiftsprompt eller specifikation, snarare än i CLAUDE.md. Att lägga till tillfälliga instruktioner i en projektomfattande fil gör det svårare att skilja dem från konventioner som bör gälla i hela repositoriet.

Se till exempel till att projektets testkommando finns i CLAUDE.md, placera komponentspecifika konventioner i en regel med sökvägsomfång och spara en återkommande granskningsprocedur som en färdighet. Granska dessa filer när kommandon eller konventioner ändras, precis som du skulle göra med annan projektdokumentation.

Promptar, CLAUDE.md och färdighetsguider styr Claudes beteende; de garanterar inte att en instruktion kommer att följas. Hooks kan utföra kontroller vid konfigurerade händelser, men deras tillförlitlighet beror på hook-typen och implementeringen.

En kommandohook kör ett skript. En prompt- eller agenthook förlitar sig på en modells bedömning. Som det förklaras i Anthropics guide till bästa praxis: ”En prompt- eller agenthook ber en annan modell att fatta ett beslut, så den är inte heller deterministisk.” För en regel som måste tillämpas ska du använda lämpliga behörighetskontroller och testa den relevanta kommando- eller HTTP-hooken, inklusive hur den hanterar fel.

Anpassade underagenter är ett annat sätt att organisera återkommande arbetsuppgifter. Definiera en specialist i .claude/agents/ när det krävs en särskild granskningsroll eller ett specifikt verktygsomfång, istället för att lägga till varje specialistinstruktion i huvudsessionen. Dessa guider till den bästa Claude-modellen för arbete och olika typer av AI-agenter ger ytterligare sammanhang.

Om ditt team hanterar prompter för flera olika AI-produkter kan du ta en titt på dessa verktyg för promptutveckling för att hantera bibliotek utöver Claude Code.

När en session ger ett ofullständigt eller olämpligt resultat, kontrollera om begäran lämnade viktiga beslut olösta. Dessa fem misstag kan göra arbetet svårare att diagnostisera och granska.

”Undersök arkivet” ger Claude väldigt lite vägledning om vilka filer som är viktiga eller när den ska sluta. Du kan få en allmän sammanfattning utan något svar på det problem som låg till grund för förfrågan.

Namnge det beteende eller beslut som du behöver förstå, identifiera en startpunkt och definiera det förväntade resultatet. Till exempel: ”Spåra hur denna slutpunkt kontrollerar behörigheter och ange de relevanta funktionerna.” Om du använder underagenter, ge var och en en avgränsad fråga istället för att delegera samma obegränsade sökning.

När man växlar mellan en funktion, ett icke-relaterat fel och en dokumentationsförfrågan kan konversationen behålla ett sammanhang som kanske inte är relevant för den aktuella uppgiften. Referenser som ”den filen” eller ”det tidigare tillvägagångssättet” blir tvetydiga.

Använd separata sessioner för arbete som inte hänger ihop. Om flera sessioner ska redigera repositoriet, använd separata Git-arbetsträd så att de inte ändrar samma arbetskatalog. En kort sidokommentar: Claude Codes /btw-kommando håller utväxlingen borta från den huvudsakliga konversationshistoriken.

En kompilering kan godkännas även om en funktion beter sig felaktigt. En testserie kan godkännas eftersom den aldrig har testat den felaktiga indata. Att be Claude att ”köra testerna” klargör inte vilka krav dessa tester verifierar.

Koppla acceptanskriterierna till specifika kontroller. Vid en buggfix ska du begära bevis på att reproduktionstestet misslyckades före ändringen och godkändes efteråt. Håll otestade kriterier synliga istället för att betrakta ett lyckat kommando som verifiering av hela ändringen.

En växande CLAUDE.md-fil kan innehålla föråldrade kommandon, dubbla regler och instruktioner som strider mot uppgiftsspecifika krav. Att lägga till starkare formuleringar löser inte dessa konflikter.

Jämför filen med det aktuella arkivet. Ta bort föråldrade riktlinjer, förtydliga motstridiga regler och flytta instruktioner med snäv tillämpning till regler eller färdigheter som gäller för en viss väg. Om ett krav måste uppfyllas, konfigurera och testa lämpliga kontroller istället för att förlita dig på upprepade påminnelser.

En granskning kan avslöja både verkliga fel, osäkra problem och valfria förslag på omstrukturering. Att tillämpa alla förslag kan leda till omfattande ändringar utan att det önskade beteendet förbättras.

Be om bevis och redogör för konsekvenserna bakom varje iakttagelse. Prioritera felaktigheter och ouppfyllda krav, utred osäkra påståenden och håll icke-relaterade förbättringar borta från den aktuella diff-filen. En granskare bör kunna rapportera att det inte finns några åtgärdsbara iakttagelser när bevisen stöder den slutsatsen.

För att anpassa en mall ersätter du platshållarna med uppgifter från ditt projekt och bestämmer vad Claude ska göra innan du gör ändringar. Följ dessa steg för att förbereda förfrågan och granska resultatet.

För en liten, väl definierad ändring kan du be Claude att genomföra den direkt. För okänd kod, ändringar som omfattar flera filer eller oklara krav bör du börja med en plan.

Tryck på Skift+Tab tills planeringsläget visas, eller starta Claude Code med claude --permission-mode plan. I det här läget kan Claude granska filer och köra skrivskyddade kommandon utan att redigera din källkod. Granska de föreslagna filerna, beroendena och testerna innan du godkänner implementeringen. Tryck på Ctrl+G för att öppna den föreslagna planen i din editor.

Ge Claude den information som behövs för att förstå uppgiften: en filreferens, en rensad fellogg, en skärmdump eller ett kravdokument. Använd @ följt av en filväg för att inkludera filens innehåll.

Välj den minsta användbara uppsättningen källor. Att inkludera en hel logg eller katalog kan tillföra irrelevant material och ta upp onödigt sammanhang. Ta bort inloggningsuppgifter och känslig information innan du delar loggar, och kontrollera att Claude har de verktyg som behövs för att hämta eventuella dokumentations-URL:er som du tillhandahåller.

Till exempel skickar kommandot `cat error.log | claude -p "Explain this error"` in en loggfil med en icke-interaktiv förfrågan. Använd det först efter att du har kontrollerat filens innehåll. Detta är det praktiska värdet med kontextuell AI: att ge modellen relevant information för uppgiften.

När du lägger till en funktion ska du identifiera en liknande komponent eller funktion i repositoriet. Ange för Claude vilka konventioner som ska följas, till exempel API-klienten, valideringslogiken, felhanteringen eller teststrukturen.

”Följ hur @src/widgets/Weather.tsx hämtar och cachelagrar data” ger Claude en konkret referens. Ange även eventuella skillnader som den nya funktionen kräver, så att den inte kopierar beteenden som inte längre passar. Dessa konventioner bör spegla ditt teams arbetsflöde för mjukvaruutveckling.

För kodändringar anger du det relevanta test-, build- eller lint-kommandot samt det beteende som ska kontrolleras. För forskning begär du filreferenser eller commit-ID:n. För arbete med användargränssnittet tillhandahåller du en referensbild och en konfigurerad metod för att fånga implementeringen i samma visningsområde.

Be Claude att rapportera vad den faktiskt har kontrollerat, inklusive fel och kontroller som har hoppats över. Granska om bevisen täcker kravet; en godkänd build innebär inte att alla begärda funktioner fungerar.

För längre uppgifter erbjuder Claude Code även ett /goal-villkor och Stop-hooks. Måluvärderaren bedömer bevis som framkommit i konversationen istället för att självständigt granska filer eller köra tester. En konfigurerad Stop-hook kan blockera slutförandet, men det finns begränsningar för upprepad blockering. Inget av dessa ersätter lämpliga tester och mänsklig granskning.

Om upprepade korrigeringar inte löser ett problem, stanna upp och identifiera vad som var oklart i den ursprungliga förfrågan. Spara användbara iakttagelser, aktuell Git-status och återstående arbete innan du rensar konversationen.

Anthropics guide till bästa praxis rekommenderar att man börjar om från början efter två misslyckade korrigeringar av samma problem. Använd /clear och ange sedan en reviderad prompt som inkluderar det du har lärt dig. Att rensa konversationen ångrar inte filändringar.

Tryck på Esc för att avbryta ett pågående svar. När inmatningsfältet är tomt trycker du två gånger på Esc för att öppna återgångsmenyn och välja vad som ska återställas. Återgången ångrar inte alla externa effekter, så använd Git-kontrollpunkter och separata återställningsprocedurer för ändringar i databaser eller fjärrtjänster.

Spara projektövergripande riktlinjer i CLAUDE.md, repeterbara procedurer i färdigheter och instruktioner för specifika filer i regler med sökvägsomfång. Använd krokar för åtgärder kopplade till specifika händelser, till exempel att köra en formaterare efter en redigering.

Välj utifrån när instruktionen ska gälla:

Ett krav för en funktion hör vanligtvis hemma i dess uppgiftsprompt eller specifikation, snarare än i CLAUDE.md. Att lägga till tillfälliga instruktioner i en projektomfattande fil gör det svårare att skilja dem från konventioner som bör gälla i hela repositoriet.

Se till exempel till att projektets testkommando finns i CLAUDE.md, placera komponentspecifika konventioner i en regel med sökvägsomfång och spara en återkommande granskningsprocedur som en färdighet. Granska dessa filer när kommandon eller konventioner ändras, precis som du skulle göra med annan projektdokumentation.

Promptar, CLAUDE.md och färdighetsguider styr Claudes beteende; de garanterar inte att en instruktion kommer att följas. Hooks kan utföra kontroller vid konfigurerade händelser, men deras tillförlitlighet beror på hook-typen och implementeringen.

En kommandohook kör ett skript. En prompt- eller agenthook förlitar sig på en modells bedömning. Som det förklaras i Anthropics guide till bästa praxis: ”En prompt- eller agenthook ber en annan modell att fatta ett beslut, så den är inte heller deterministisk.” För en regel som måste tillämpas ska du använda lämpliga behörighetskontroller och testa den relevanta kommando- eller HTTP-hooken, inklusive hur den hanterar fel.

Anpassade underagenter är ett annat sätt att organisera återkommande arbetsuppgifter. Definiera en specialist i .claude/agents/ när det krävs en särskild granskningsroll eller ett specifikt verktygsomfång, istället för att lägga till varje specialistinstruktion i huvudsessionen. Dessa guider till den bästa Claude-modellen för arbete och olika typer av AI-agenter ger ytterligare sammanhang.

Om ditt team hanterar prompter för flera olika AI-produkter kan du ta en titt på dessa verktyg för promptutveckling för att hantera bibliotek utöver Claude Code.

När en session ger ett ofullständigt eller olämpligt resultat, kontrollera om begäran lämnade viktiga beslut olösta. Dessa fem misstag kan göra arbetet svårare att diagnostisera och granska.

”Undersök arkivet” ger Claude väldigt lite vägledning om vilka filer som är viktiga eller när den ska sluta. Du kan få en allmän sammanfattning utan något svar på det problem som låg till grund för förfrågan.

Namnge det beteende eller beslut som du behöver förstå, identifiera en startpunkt och definiera det förväntade resultatet. Till exempel: ”Spåra hur denna slutpunkt kontrollerar behörigheter och ange de relevanta funktionerna.” Om du använder underagenter, ge var och en en avgränsad fråga istället för att delegera samma obegränsade sökning.

När man växlar mellan en funktion, ett icke-relaterat fel och en dokumentationsförfrågan kan konversationen behålla ett sammanhang som kanske inte är relevant för den aktuella uppgiften. Referenser som ”den filen” eller ”det tidigare tillvägagångssättet” blir då tvetydiga.

Använd separata sessioner för arbete som inte hänger ihop. Om flera sessioner ska redigera repositoriet, använd separata Git-arbetsträd så att de inte ändrar samma arbetskatalog. En kort sidokommentar: Claude Codes /btw-kommando håller utväxlingen borta från den huvudsakliga konversationshistoriken.

En kompilering kan godkännas även om en funktion beter sig felaktigt. En testserie kan godkännas eftersom den aldrig har testat den felaktiga indata. Att be Claude att ”köra testerna” klargör inte vilka krav dessa tester verifierar.

Koppla acceptanskriterierna till specifika kontroller. Vid en buggfix ska du begära bevis på att reproduktionstestet misslyckades före ändringen och godkändes efteråt. Håll otestade kriterier synliga istället för att betrakta ett lyckat kommando som verifiering av hela ändringen.

En växande CLAUDE.md-fil kan innehålla föråldrade kommandon, dubbla regler och instruktioner som strider mot uppgiftsspecifika krav. Att lägga till starkare formuleringar löser inte dessa konflikter.

Jämför filen med det aktuella arkivet. Ta bort föråldrade riktlinjer, förtydliga motstridiga regler och flytta instruktioner med snäv tillämpning till regler eller färdigheter som gäller för en viss väg. Om ett krav måste uppfyllas, konfigurera och testa lämpliga kontroller istället för att förlita dig på upprepade påminnelser.

En granskning kan avslöja både verkliga fel, osäkra problem och valfria förslag på omstrukturering. Att tillämpa alla förslag kan leda till omfattande ändringar utan att det önskade beteendet förbättras.

Be om belägg och redogör för konsekvenserna bakom varje iakttagelse. Prioritera felaktigheter och ouppfyllda krav, utred osäkra påståenden och håll icke-relaterade förbättringar borta från den aktuella diff-filen. En granskare bör kunna rapportera att inga åtgärdsbara iakttagelser finns när beläggen stöder den slutsatsen.

För att anpassa en mall ersätter du platshållarna med uppgifter från ditt projekt och bestämmer vad Claude ska göra innan du gör ändringar. Följ dessa steg för att förbereda förfrågan och granska resultatet.

För en liten, väl definierad ändring kan du be Claude att genomföra den direkt. För okänd kod, ändringar som omfattar flera filer eller oklara krav bör du börja med en plan.

Tryck på Skift+Tab tills planeringsläget visas, eller starta Claude Code med claude --permission-mode plan. I det här läget kan Claude granska filer och köra skrivskyddade kommandon utan att redigera din källkod. Granska de föreslagna filerna, beroendena och testerna innan du godkänner implementeringen. Tryck på Ctrl+G för att öppna den föreslagna planen i din editor.

Ge Claude den information som behövs för att förstå uppgiften: en filreferens, en rensad fellogg, en skärmdump eller ett kravdokument. Använd @ följt av en filväg för att inkludera filens innehåll.

Välj den minsta användbara uppsättningen källor. Att inkludera en hel logg eller katalog kan leda till att irrelevant material läggs till och ta upp onödigt utrymme. Ta bort inloggningsuppgifter och känslig information innan du delar loggar, och kontrollera att Claude har de verktyg som behövs för att hämta eventuella dokumentations-URL:er som du tillhandahåller.

Till exempel skickar kommandot `cat error.log | claude -p "Explain this error"` in en loggfil med en icke-interaktiv förfrågan. Använd det först efter att du har kontrollerat filens innehåll. Detta är det praktiska värdet med kontextuell AI: att ge modellen relevant information för uppgiften.

När du lägger till en funktion ska du identifiera en liknande komponent eller funktion i repositoriet. Ange för Claude vilka konventioner som ska följas, till exempel API-klienten, valideringslogiken, felhanteringen eller teststrukturen.

”Följ hur @src/widgets/Weather.tsx hämtar och cachelagrar data” ger Claude en konkret referens. Ange även eventuella skillnader som den nya funktionen kräver, så att den inte kopierar beteenden som inte längre passar. Dessa konventioner bör spegla ditt teams arbetsflöde för mjukvaruutveckling.

För kodändringar anger du det relevanta test-, build- eller lint-kommandot samt det beteende som ska kontrolleras. För forskning begär du filreferenser eller commit-ID:n. För arbete med användargränssnittet tillhandahåller du en referensbild och en konfigurerad metod för att fånga implementeringen i samma visningsområde.

Be Claude att rapportera vad den faktiskt har kontrollerat, inklusive fel och kontroller som har hoppats över. Granska om bevisen täcker kravet; en godkänd build innebär inte att alla begärda funktioner fungerar.

För längre uppgifter erbjuder Claude Code även ett /goal-villkor och Stop-hooks. Måluvärderaren bedömer bevis som framkommit i konversationen istället för att självständigt granska filer eller köra tester. En konfigurerad Stop-hook kan blockera slutförandet, men det finns begränsningar för upprepad blockering. Inget av dessa ersätter lämpliga tester och mänsklig granskning.

Om upprepade korrigeringar inte löser ett problem, stanna upp och identifiera vad som var oklart i den ursprungliga förfrågan. Spara användbara iakttagelser, aktuell Git-status och återstående arbete innan du rensar konversationen.

Anthropics guide till bästa praxis rekommenderar att man börjar om från början efter två misslyckade korrigeringar av samma problem. Använd /clear och ange sedan en reviderad prompt som inkluderar det du har lärt dig. Att rensa konversationen ångrar inte filändringar.

Tryck på Esc för att avbryta ett pågående svar. När inmatningsfältet är tomt trycker du två gånger på Esc för att öppna återgångsmenyn och välja vad som ska återställas. Återgången ångrar inte alla externa effekter, så använd Git-kontrollpunkter och separata återställningsprocedurer för ändringar i databaser eller fjärrtjänster.

Spara projektövergripande riktlinjer i CLAUDE.md, repeterbara procedurer i färdigheter och instruktioner för specifika filer i regler med sökvägsomfång. Använd krokar för åtgärder kopplade till specifika händelser, till exempel att köra en formaterare efter en redigering.

Välj utifrån när instruktionen ska gälla:

Ett krav för en funktion hör vanligtvis hemma i dess uppgiftsprompt eller specifikation, snarare än i CLAUDE.md. Att lägga till tillfälliga instruktioner i en projektomfattande fil gör det svårare att skilja dem från konventioner som bör gälla i hela repositoriet.

Se till exempel till att projektets testkommando finns i CLAUDE.md, placera komponentspecifika konventioner i en regel med sökvägsomfång och spara en återkommande granskningsprocedur som en färdighet. Granska dessa filer när kommandon eller konventioner ändras, precis som du skulle göra med annan projektdokumentation.

Promptar, CLAUDE.md och färdighetsguider styr Claudes beteende; de garanterar inte att en instruktion kommer att följas. Hooks kan utföra kontroller vid konfigurerade händelser, men deras tillförlitlighet beror på hook-typen och implementeringen.

En kommandohook kör ett skript. En prompt- eller agenthook förlitar sig på en modells bedömning. Som det förklaras i Anthropics guide till bästa praxis: ”En prompt- eller agenthook ber en annan modell att fatta ett beslut, så den är inte heller deterministisk.” För en regel som måste tillämpas ska du använda lämpliga behörighetskontroller och testa den relevanta kommando- eller HTTP-hooken, inklusive hur den hanterar fel.

Anpassade underagenter är ett annat sätt att organisera återkommande arbetsuppgifter. Definiera en specialist i .claude/agents/ när det krävs en särskild granskningsroll eller ett specifikt verktygsomfång, istället för att lägga till varje specialistinstruktion i huvudsessionen. Dessa guider till den bästa Claude-modellen för arbete och olika typer av AI-agenter ger ytterligare sammanhang.

Om ditt team hanterar prompter för flera olika AI-produkter kan du ta en titt på dessa verktyg för promptutveckling för att hantera bibliotek utöver Claude Code.

När en session ger ett ofullständigt eller olämpligt resultat, kontrollera om begäran lämnade viktiga beslut olösta. Dessa fem misstag kan göra arbetet svårare att diagnostisera och granska.

”Undersök arkivet” ger Claude väldigt lite vägledning om vilka filer som är viktiga eller när den ska sluta. Du kan få en allmän sammanfattning utan något svar på det problem som låg till grund för förfrågan.

Namnge det beteende eller beslut som du behöver förstå, identifiera en startpunkt och definiera det förväntade resultatet. Till exempel: ”Spåra hur denna slutpunkt kontrollerar behörigheter och ange de relevanta funktionerna.” Om du använder underagenter, ge var och en en avgränsad fråga istället för att delegera samma obegränsade sökning.

När man växlar mellan en funktion, ett icke-relaterat fel och en dokumentationsförfrågan kan konversationen behålla ett sammanhang som kanske inte är relevant för den aktuella uppgiften. Referenser som ”den filen” eller ”det tidigare tillvägagångssättet” blir tvetydiga.

Använd separata sessioner för arbete som inte hänger ihop. Om flera sessioner ska redigera repositoriet, använd separata Git-arbetsträd så att de inte ändrar samma arbetskatalog. En kort sidokommentar: Claude Codes /btw-kommando håller utväxlingen borta från den huvudsakliga konversationshistoriken.

En kompilering kan godkännas även om en funktion beter sig felaktigt. En testserie kan godkännas eftersom den aldrig har testat den felaktiga indata. Att be Claude att ”köra testerna” klargör inte vilka krav dessa tester verifierar.

Koppla acceptanskriterierna till specifika kontroller. Vid en buggfix ska du begära bevis på att reproduktionstestet misslyckades före ändringen och godkändes efteråt. Håll otestade kriterier synliga istället för att betrakta ett lyckat kommando som verifiering av hela ändringen.

En växande CLAUDE.md-fil kan innehålla föråldrade kommandon, dubbla regler och instruktioner som strider mot uppgiftsspecifika krav. Att lägga till starkare formuleringar löser inte dessa konflikter.

Jämför filen med det aktuella arkivet. Ta bort föråldrade riktlinjer, förtydliga motstridiga regler och flytta instruktioner med snäv tillämpning till regler eller färdigheter som gäller för en viss väg. Om ett krav måste uppfyllas, konfigurera och testa lämpliga kontroller istället för att förlita dig på upprepade påminnelser.

En granskning kan avslöja både verkliga fel, osäkra problem och valfria förslag på omstrukturering. Att tillämpa alla förslag kan leda till omfattande ändringar utan att det önskade beteendet förbättras.

Be om belägg och redogör för konsekvenserna bakom varje iakttagelse. Prioritera felaktigheter och ouppfyllda krav, utred osäkra påståenden och håll icke-relaterade förbättringar borta från den aktuella diff-filen. En granskare bör kunna rapportera att det inte finns några åtgärdsbara iakttagelser när bevisen stöder den slutsatsen.

För att anpassa en mall ersätter du platshållarna med uppgifter från ditt projekt och bestämmer vad Claude ska göra innan du gör ändringar. Följ dessa steg för att förbereda förfrågan och granska resultatet.

För en liten, väl definierad ändring kan du be Claude att genomföra den direkt. För okänd kod, ändringar som omfattar flera filer eller oklara krav bör du börja med en plan.

Tryck på Skift+Tab tills planeringsläget visas, eller starta Claude Code med claude --permission-mode plan. I det här läget kan Claude granska filer och köra skrivskyddade kommandon utan att redigera din källkod. Granska de föreslagna filerna, beroendena och testerna innan du godkänner implementeringen. Tryck på Ctrl+G för att öppna den föreslagna planen i din editor.

Ge Claude den information som behövs för att förstå uppgiften: en filreferens, en rensad fellogg, en skärmdump eller ett kravdokument. Använd @ följt av en filväg för att inkludera filens innehåll.

Välj den minsta användbara uppsättningen källor. Att inkludera en hel logg eller katalog kan leda till att irrelevant material läggs till och ta upp onödigt utrymme. Ta bort inloggningsuppgifter och känslig information innan du delar loggar, och kontrollera att Claude har de verktyg som behövs för att hämta eventuella dokumentations-URL:er som du tillhandahåller.

Till exempel skickar kommandot `cat error.log | claude -p "Explain this error"` in en loggfil med en icke-interaktiv förfrågan. Använd det först efter att du har kontrollerat filens innehåll. Detta är det praktiska värdet med kontextuell AI: att ge modellen relevant information för uppgiften.

När du lägger till en funktion ska du identifiera en liknande komponent eller funktion i repositoriet. Ange för Claude vilka konventioner som ska följas, till exempel API-klienten, valideringslogiken, felhanteringen eller teststrukturen.

”Följ hur @src/widgets/Weather.tsx hämtar och cachelagrar data” ger Claude en konkret referens. Ange även eventuella skillnader som den nya funktionen kräver, så att den inte kopierar beteenden som inte längre passar. Dessa konventioner bör spegla ditt teams arbetsflöde för mjukvaruutveckling.

För kodändringar anger du det relevanta test-, build- eller lint-kommandot samt det beteende som ska kontrolleras. För forskning begär du filreferenser eller commit-ID:n. För arbete med användargränssnittet tillhandahåller du en referensbild och en konfigurerad metod för att fånga implementeringen i samma visningsområde.

Be Claude att rapportera vad den faktiskt har kontrollerat, inklusive fel och kontroller som har hoppats över. Granska om bevisen täcker kravet; en godkänd build innebär inte att alla begärda funktioner fungerar.

För längre uppgifter erbjuder Claude Code även ett /goal-villkor och Stop-hooks. Måluvärderaren bedömer bevis som framkommit i konversationen istället för att självständigt granska filer eller köra tester. En konfigurerad Stop-hook kan blockera slutförandet, men det finns begränsningar för upprepad blockering. Inget av dessa ersätter lämpliga tester och mänsklig granskning.

Om upprepade korrigeringar inte löser ett problem, stanna upp och identifiera vad som var oklart i den ursprungliga förfrågan. Spara användbara iakttagelser, aktuell Git-status och återstående arbete innan du rensar konversationen.

Anthropics guide för bästa praxis rekommenderar att man börjar om från början efter två misslyckade korrigeringar av samma problem. Använd /clear och ange sedan en reviderad prompt som inkluderar det du har lärt dig. Att rensa konversationen ångrar inte filändringar.

Tryck på Esc för att avbryta ett pågående svar. När inmatningsfältet är tomt trycker du två gånger på Esc för att öppna återgångsmenyn och välja vad som ska återställas. Återgången ångrar inte alla externa effekter, så använd Git-kontrollpunkter och separata återställningsprocedurer för ändringar i databaser eller fjärrtjänster.

Spara projektövergripande riktlinjer i CLAUDE.md, repeterbara procedurer i färdigheter och instruktioner för specifika filer i regler med sökvägsomfång. Använd krokar för åtgärder kopplade till specifika händelser, till exempel att köra en formaterare efter en redigering.

Välj utifrån när instruktionen ska gälla:

Ett krav för en funktion hör vanligtvis hemma i dess uppgiftsprompt eller specifikation, snarare än i CLAUDE.md. Att lägga till tillfälliga instruktioner i en projektomfattande fil gör det svårare att skilja dem från konventioner som bör gälla i hela repositoriet.

Se till exempel till att projektets testkommando finns i CLAUDE.md, placera komponentspecifika konventioner i en regel med sökvägsomfång och spara en återkommande granskningsprocedur som en färdighet. Granska dessa filer när kommandon eller konventioner ändras, precis som du skulle göra med annan projektdokumentation.

Promptar, CLAUDE.md och färdighetsguider styr Claudes beteende; de garanterar inte att en instruktion kommer att följas. Hooks kan utföra kontroller vid konfigurerade händelser, men deras tillförlitlighet beror på hook-typen och implementeringen.

En kommandohook kör ett skript. En prompt- eller agenthook förlitar sig på en modells bedömning. Som det förklaras i Anthropics guide till bästa praxis: ”En prompt- eller agenthook ber en annan modell att fatta ett beslut, så den är inte heller deterministisk.” För en regel som måste tillämpas ska du använda lämpliga behörighetskontroller och testa den relevanta kommando- eller HTTP-hooken, inklusive hur den hanterar fel.

Anpassade underagenter är ett annat sätt att organisera återkommande arbetsuppgifter. Definiera en specialist i .claude/agents/ när det krävs en särskild granskningsroll eller ett specifikt verktygsomfång, istället för att lägga till varje specialistinstruktion i huvudsessionen. Dessa guider till den bästa Claude-modellen för arbete och olika typer av AI-agenter ger ytterligare sammanhang.

Om ditt team hanterar prompter för flera olika AI-produkter kan du ta en titt på dessa verktyg för promptutveckling för att hantera bibliotek utöver Claude Code.

När en session ger ett ofullständigt eller olämpligt resultat, kontrollera om begäran lämnade viktiga beslut olösta. Dessa fem misstag kan göra arbetet svårare att diagnostisera och granska.

”Undersök arkivet” ger Claude väldigt lite vägledning om vilka filer som är viktiga eller när den ska sluta. Du kan få en allmän sammanfattning utan något svar på det problem som låg till grund för förfrågan.

Namnge det beteende eller beslut som du behöver förstå, identifiera en startpunkt och definiera det förväntade resultatet. Till exempel: ”Spåra hur denna slutpunkt kontrollerar behörigheter och ange de relevanta funktionerna.” Om du använder underagenter, ge var och en en avgränsad fråga istället för att delegera samma obegränsade sökning.

När man växlar mellan en funktion, ett icke-relaterat fel och en dokumentationsförfrågan kan konversationen behålla ett sammanhang som kanske inte är relevant för den aktuella uppgiften. Referenser som ”den filen” eller ”det tidigare tillvägagångssättet” blir tvetydiga.

Använd separata sessioner för arbete som inte hänger ihop. Om flera sessioner ska redigera repositoriet, använd separata Git-arbetsträd så att de inte ändrar samma arbetskatalog. En kort sidokommentar: Claude Codes /btw-kommando håller utväxlingen borta från den huvudsakliga konversationshistoriken.

En kompilering kan godkännas även om en funktion inte fungerar som den ska. En testserie kan godkännas eftersom den aldrig har testat den felaktiga indata. Att be Claude att ”köra testerna” klargör inte vilka krav dessa tester verifierar.

Koppla acceptanskriterierna till specifika kontroller. Vid en buggfix ska du begära bevis på att reproduktionstestet misslyckades före ändringen och godkändes efteråt. Håll otestade kriterier synliga istället för att betrakta ett lyckat kommando som verifiering av hela ändringen.

En växande CLAUDE.md-fil kan innehålla föråldrade kommandon, dubbla regler och instruktioner som strider mot uppgiftsspecifika krav. Att lägga till starkare formuleringar löser inte dessa konflikter.

Jämför filen med det aktuella arkivet. Ta bort föråldrade riktlinjer, förtydliga motstridiga regler och flytta instruktioner med snäv tillämpning till regler eller färdigheter som gäller för en viss väg. Om ett krav måste uppfyllas, konfigurera och testa lämpliga kontroller istället för att förlita dig på upprepade påminnelser.

En granskning kan avslöja både verkliga fel, osäkra problem och valfria förslag på omstrukturering. Att tillämpa alla förslag kan leda till omfattande ändringar utan att det önskade beteendet förbättras.

Be om belägg och redogör för konsekvenserna bakom varje iakttagelse. Prioritera felaktigheter och ouppfyllda krav, utred osäkra påståenden och håll icke-relaterade förbättringar borta från den aktuella diff-filen. En granskare bör kunna rapportera att inga åtgärdsbara iakttagelser finns när beläggen stöder den slutsatsen.