Claude Code-prompts: 25 kant-en-klare prompts en hoe je je eigen prompts schrijft

Klanten die een verlopen kortingsbon gebruiken, krijgen bij het afrekenen een 500-foutmelding. Bekijk @src/checkout/coupons.ts en de bijbehorende tests. Het verwachte gedrag is een melding dat de kortingsbon ongeldig is, zonder dat er een bestelling wordt aangemaakt. Schrijf een test die mislukt en de fout reproduceert, en los deze vervolgens op zonder het gedrag van geldige kortingsbonnen te wijzigen. Voer [checkout testcommando] uit en toon de resultaten voor en na. Als je de fout niet kunt reproduceren, meld dan wat je hebt gecontroleerd voordat je de implementatie wijzigt.

Voeg een datumkiezer toe aan [pad naar boekingsformulier]. Volg de conventies voor componenten en validatie in @src/components/TimeSelect.tsx. Gebruikers moeten [toegestane datums] kunnen selecteren, terwijl [niet-beschikbare datums] uitgeschakeld blijven. Voeg geen bibliotheken toe. Voer [commando voor componenttest] en [commando voor typecontrole] uit en rapporteer eventuele criteria die niet door deze controles worden gedekt.

Splits @src/reports/export.py op in kleinere functies, waarbij je de invoer, het uitvoerformat en het foutgedrag behoudt. Voer [export testcommando] uit vóór de bewerking en rapporteer eventuele bestaande fouten. Voer na het herstructureren de tests opnieuw uit en toon beide resultaten. Wijzig de openbare interface of niet-gerelateerde bestanden niet.

“Claude test elke wijziging die ik doorvoer op claude.ai/code met behulp van de Claude Chrome-extensie. Het opent een browser, test de gebruikersinterface en herhaalt dit totdat de code werkt en de gebruikerservaring goed aanvoelt. ”

Bekijk de README, de projectconfiguratie en de mappenstructuur op het hoogste niveau van deze opslagplaats. Gebruik referenties alleen voor zover dat nodig is om uit te leggen: wat de applicatie doet, wat de belangrijkste toegangspunten en componenten zijn, waar de tests zich bevinden en welke commando’s de opslagplaats definieert om ze uit te voeren. Vermeld de bestandspaden die je uitleg ondersteunen. Maak onderscheid tussen gedocumenteerd gedrag en je eigen conclusies, en markeer alles wat je niet kunt vaststellen. Lees geen geheimen of omgevingsbestanden, inspecteer geen geïnstalleerde afhankelijkheden en wijzig geen bestanden. Sluit af met de drie bestanden die ik als eerste zou moeten lezen en waarom.

Bekijk de Git-geschiedenis van [bestand, functie of klasse], met de nadruk op [gedrag of ontwerpvraag]. Identificeer de commits die dit gedrag hebben geïntroduceerd of substantieel hebben gewijzigd. Geef voor elke relevante commit de hash op, vat de wijziging samen en leg eventuele motiveringen uit die zijn gedocumenteerd in het commitbericht of de gekoppelde discussie waartoe je toegang hebt. Geef afgeleide redenen aan als ‘conclusies’. Als de geschiedenis geen verklaring biedt voor een beslissing, vermeld dit dan. Wijzig geen bestanden of de Git-geschiedenis.

Traceer wat er gebeurt wanneer [gebruikersactie of systeemgebeurtenis] plaatsvindt, beginnend bij [bekende route, handler of map]. Volg de relevante aanroepen door validatie, bedrijfslogica en eventuele database-schrijfbewerkingen of externe verzoeken. Maak een lijst van de bestanden en functies in de volgorde van uitvoering, met verwijzingen naar de betreffende regels waar beschikbaar. Leg de belangrijkste foutpaden uit en identificeer bestaande tests die de werkstroom dekken. Markeer elke verbinding die je niet vanuit de code kunt bevestigen. Voer de werkstroom niet uit, roep geen externe diensten aan en voer geen bewerkingen uit aan bestanden.

Plan hoe je [functie] in [repositorygebied] gaat implementeren. Het verwachte gedrag is [vereisten], en deze gebieden moeten ongewijzigd blijven: [beperkingen]. Bekijk de relevante code en bestaande tests. Bepaal welke bestanden moeten worden aangepast, de volgorde van implementatie en eventuele risico’s op het gebied van compatibiliteit of gegevensmigratie. Breng elke vereiste in kaart door deze aan een voorgestelde test of andere verificatiestap te koppelen. Maak een aparte lijst van onopgeloste vragen en aannames. Implementeer de functie nog niet. Leg het plan ter beoordeling aan mij voor.

Ik wil [korte beschrijving] bouwen voor [gebruikers en gebruiksscenario]. Lees eerst [relevante bestanden of vereisten] en gebruik vervolgens AskUserQuestion om beslissingen te verduidelijken die de implementatie wezenlijk zouden beïnvloeden. Concentreer je op randgevallen, gegevensverwerking, toestemming, verwacht UI-gedrag en afwegingen. Stel geen vragen waarop de verstrekte context al een antwoord geeft. Zodra de belangrijkste beslissingen zijn genomen, stel je een specificatie op met daarin de vereisten, acceptatiecriteria, beperkingen en wat buiten de scope valt. Markeer eventuele resterende aannames. Laat me de specificatie zien voordat je deze opslaat in [pad naar specificatie], en overschrijf geen bestaand bestand zonder goedkeuring.

Beoordeel de impact van het wijzigen van [functie, component of interface] van [huidig gedrag] naar [voorgesteld gedrag]. Zoek in [opslagplaats of directory] naar de definitie, directe aanroepers, imports en gerelateerde tests. Maak een lijst van de bestanden die waarschijnlijk moeten worden aangepast en leg uit hoe elk bestand hierdoor kan worden beïnvloed, met verwijzingen naar bestanden en regels waar beschikbaar. Markeer dynamisch opgeloste aanroepen, externe afnemers of andere afhankelijkheden die je niet kunt verifiëren. Breng eventuele compatibiliteitskwesties in kaart die vóór de implementatie moeten worden opgelost. Breng geen wijzigingen aan in bestanden; lever de impactbeoordeling in en wacht op mijn beoordeling.

Voeg [functie] toe aan [bestand of pagina] met dit gedrag: [acceptatiecriteria]. Bekijk de [bestaande implementatie] en volg de conventies daarvan voor het ophalen van gegevens, het afhandelen van fouten en het organiseren van componenten. Gebruik alleen bibliotheken die al in het project zijn geïnstalleerd. Houd wijzigingen binnen [reikwijdte] en behoud [bestaand gedrag of openbare interface]. Voeg tests toe of werk deze bij voor de acceptatiecriteria. Voer [testcommando] en [typecontrole- of lint-commando] uit en voer vervolgens de rapportage uit van de gewijzigde bestanden, resultaten en eventuele controles die je niet kon voltooien. Als het bestaande patroon in strijd is met een vereiste, leg dan het conflict uit voordat je verdergaat.

Implementeer [functienaam] in [bestand] om aan [vereisten] te voldoen. Houd rekening met [normaal geval], [randgeval] en [gedrag bij ongeldige invoer]. Voer eerst [relevant testcommando] uit en voer rapportage uit van eventuele fouten. Schrijf tests voor het gevraagde gedrag en voer deze uit vóór de implementatie. Controleer of de nieuwe tests om de verwachte reden mislukken. Implementeer de functie en voer de tests opnieuw uit. Verzwak geen asserties, sla geen tests over en wijzig het verwachte gedrag niet om de tests te laten slagen. Als de vereisten in strijd zijn met bestaande tests, stop dan en leg het conflict uit. Toon de resultaten van voor en na.

Implementeer de bijlage in [component of pagina], met behulp van de bestaande componenten en stijlen van het project. Behoud [vereist gedrag] en vermijd wijzigingen buiten [de reikwijdte]. Gebruik [geconfigureerde browser of schermafbeelding] om [lokale route] vast te leggen bij [viewport-afmetingen] met [testgegevens en UI-status]. Als de tool of applicatie niet beschikbaar is, rapporteer dan wat er nodig is in plaats van te beweren dat er een visuele controle is uitgevoerd. Vergelijk de opname met de referentie, waarbij je je richt op [layout, spatiëring, typografie of andere acceptatiecriteria]. Voer maximaal [nummer] correctierondes uit en rapporteer vervolgens de resterende verschillen. Breng geen wijzigingen aan in de referentieafbeelding. Voer [relevante componenttests] en [type-check of build-commando] uit. Neem de gemaakte schermafbeelding en de daadwerkelijke controleresultaten op in je samenvatting.

Gebruikers ondervinden [symptoom] wanneer [trigger of invoer]. Het verwachte gedrag is [verwacht resultaat]. Begin met het inspecteren van [map, functie of werkstroom] en de bijbehorende tests. Maak een test die faalt en waarmee het gemelde gedrag kan worden gereproduceerd. Als je het niet kunt reproduceren, leg dan uit wat je hebt gecontroleerd en welke informatie ontbreekt, voordat je de implementatie wijzigt. Zodra het is gereproduceerd, los je de oorzaak op zonder [gedrag dat intact moet blijven] te wijzigen. Voer de nieuwe test uit en [bijbehorende testopdracht]. Toon de fout vóór de oplossing, de resultaten daarna en eventuele resterende fouten.

[Build-commando] mislukt in [lokale of CI-omgeving] met de volgende uitvoer: [gezuiverd foutenlogboek]. Inspecteer de relevante code en configuratie om de oorzaak te achterhalen. Controleer op verschillen in de omgeving of afhankelijkheden als de fout lokaal niet kan worden gereproduceerd. Breng de kleinst mogelijke wijziging aan die de oorzaak verhelpt. Schakel geen controles uit, onderdruk geen fouten, sla geen tests over en versoepel de compilerinstellingen niet louter om een geslaagde build te krijgen. Voer de build opnieuw uit na de wijziging. Als deze na [nummer] pogingen tot herstel nog steeds mislukt, stop dan en rapporteer wat je hebt geprobeerd, de huidige fout en de volgende diagnostische stap. Vat de oorzaak samen en voeg het daadwerkelijke buildresultaat toe.

Help me een bug in te perken voordat ik een oplossing voorstel. Waargenomen gedrag: [wat er gebeurt]Verwacht gedrag: [wat er zou moeten gebeuren]Wanneer het zich voordoet: [voorwaarden of frequentie]Wat ik al heb geprobeerd: [stappen en resultaten]Stel één vraag per keer, en kies daarbij de vraag die het beste onderscheid maakt tussen de waarschijnlijke oorzaken. Herhaal geen vragen waarop de verstrekte informatie al een antwoord geeft. Zodra er voldoende bewijs is, vat dan de meest waarschijnlijke verklaring samen, wat er nog onzeker is en de kleinste test die deze verklaring zou kunnen bevestigen of uitsluiten. Voer nog geen bewerking uit aan de bestanden.

Gebruik een subagent om [diff of vertakking vergeleken met de basis] te beoordelen aan de hand van [goedgekeurd plan of vereistenbestand]. Als de vereisten ontbreken of dubbelzinnig zijn, meld dit dan voordat je de volledigheid beoordeelt. Controleer of elke vereiste is geïmplementeerd, of er tests zijn voor relevante randgevallen en of eventuele wijzigingen buiten de overeengekomen reikwijdte vallen. Inspecteer waar nodig de omliggende code om de diff te begrijpen. Rapporteer fouten en niet-voldane vereisten met verwijzingen naar bestanden en regels, de impact ervan en het bewijs dat elke bevinding ondersteunt. Maak een onderscheid tussen bevestigde problemen en onopgeloste vragen. Verzin geen bevindingen om een quotum te halen en neem geen niet-gerelateerde stijlvoorkeuren op. Voer geen bewerkingen uit aan bestanden.

Controleer [bestanden of diff] op injectierisico’s, ontbrekende autorisatiecontroles, blootgestelde geheime gegevens en onveilige verwerking van gebruikersinvoer. Inspecteer de relevante aanroepers en validatielogica voordat er een rapportage plaatsvindt. Identificeer voor elk probleem het betreffende bestand en de betreffende regels, de voorwaarden die nodig zijn om het probleem te triggeren, de waarschijnlijke impact en een voorgestelde oplossing. Maak onderscheid tussen een bevestigd kwetsbaar pad en een punt van zorg dat verder getest moet worden. Vermeld geen geheime waarden in het rapport, wijzig geen bestanden en test niet op live-services. Geef aan welke gebieden je hebt beoordeeld en wat buiten de reikwijdte valt.

Vat samen hoe je de voltooide wijziging hebt getoetst aan de [acceptatiecriteria]. Vermeld voor elk criterium de uitgevoerde controle, het exacte commando (indien van toepassing) en het waargenomen resultaat. Voeg relevante uitvoer toe, waarbij geheime en gevoelige gegevens zijn verwijderd. Geef eventuele reeds bestaande fouten apart aan. Maak een duidelijk onderscheid tussen controles die zijn geslaagd, controles die zijn mislukt en controles die niet zijn uitgevoerd. Leg uit waarom bepaalde controles zijn overgeslagen of waarom de limiet voor de dekking is bereikt. Beschrijf de wijziging niet als volledig geverifieerd als sommige criteria nog niet zijn gecontroleerd.

Herstructureer [bestand of module] met het oog op [een specifiek doel, zoals het opsplitsen van een grote functie of het verwijderen van geneste callbacks]. Behoud de openbare interface, retourwaarden, foutgedrag en neveneffecten. Voer [relevant testcommando] uit vóór de bewerking om een uitgangspunt vast te stellen. Als dit mislukt, rapporteer dan de fouten voordat je verdergaat. Identificeer elk gedrag dat niet door de bestaande tests wordt gedekt en voeg waar nodig gerichte tests toe. Voer de herstructurering uit zonder niet-gerelateerde wijzigingen of nieuwe afhankelijkheden. Verzwak bestaande asserties niet om de implementatie mogelijk te maken. Voer de tests en [type-check of lint-commando] opnieuw uit. Toon de resultaten van voor en na, vat de structurele wijzigingen samen en markeer elk gedrag dat je niet kon verifiëren.

Zoek naar gebruik van [oude API of bibliotheek] binnen [directory-scope], met uitzondering van gegenereerde en vendored bestanden. Maak een lijst van de betrokken bestanden en eventuele gedeelde configuraties of afhankelijkheden die door de migratie kunnen worden beïnvloed. Stel drie representatieve bestanden voor voor een proefmigratie naar [nieuwe API of versie], met behulp van [migratiegids of bestaand voorbeeld]. Leg uit waarom je deze hebt geselecteerd en markeer eventuele vereiste gedragswijzigingen. Wacht op mijn goedkeuring voordat je bewerkingen uitvoert. Migreer na goedkeuring alleen de proefbestanden en eventuele expliciet goedgekeurde gedeelde afhankelijkheden. Voer [relevante tests] en [build- of typecontrolecommando] uit. Breid de migratie niet uit naar andere bestanden. Rapporteer de verschillen, testresultaten, compatibiliteitsproblemen en eventuele wijzigingen die nodig zijn in de migratieaanpak. Stop voor beoordeling voordat je doorgaat met de resterende bestanden.

Inspecteer de huidige vertakking, de Git-status en de diff voor [functie of fix]. Identificeer de bestanden die bij deze wijziging horen en vermeld niet-gerelateerde of niet-bijgehouden bestanden apart. Stel een commitbericht op volgens het format van de laatste 10 commits. Stel een beschrijving voor de pull-aanvraag op waarin wordt vermeld wat er is gewijzigd, waarom, welke tests daadwerkelijk zijn uitgevoerd en eventuele resterende beperkingen. Toon de voorgestelde bestandslijst, het commitbericht en de PR-beschrijving voordat je iets in de fase van staging zet of publiceert. Wacht op mijn goedkeuring. Zet na goedkeuring alleen de overeengekomen bestanden in de fase van staging, voer een commit uit op [feature-branch], push naar [remote] en open een pull-aanvraag tegen [basis-branch]. Wijzig geen bestaande commits, voer geen force-push uit en voer geen samenvoegverzoek uit. Stuur de commit-hash en de PR-link terug.

Stel een README-sectie op voor [module], gericht op [lezer, zoals een backend-engineer die zich bij het project aansluit]. Behandel de vereisten, de installatie, de drie commando’s die ze het meest zullen gebruiken en veelvoorkomende fouten die door de code of bestaande documentatie worden ondersteund. Controleer de namen en opties van de commando’s aan de hand van [pakketscripts, Makefile, CLI-help of CI-configuratie]. Markeer alles wat je niet kunt bevestigen. Test veilige lokale commando’s in [testomgeving] indien beschikbaar. Voordat je commando’s uitvoert die afhankelijkheden installeren, bestanden verwijderen, gegevens migreren, implementeren of toegang geven tot externe diensten, leg je de gevolgen ervan uit en vraag je om goedkeuring. Maak een duidelijk onderscheid tussen commando’s die je met succes hebt uitgevoerd en commando’s die alleen zijn gecontroleerd aan de hand van de configuratie of documentatie. Toon de voorgestelde README-sectie voordat je [documentatiepad] bewerkt, en behoud inhoud die hier geen verband mee houdt.

Vergelijk [pad naar CLAUDE.md] met de huidige structuur, scripts en conventies van de opslagplaats. Voer nog geen bewerkingen uit aan het bestand. Identificeer verouderde instructies, duplicaten, tegenstrijdigheden en regels die betrouwbaar uit de code kunnen worden afgeleid. Leg elke voorgestelde verwijdering uit in plaats van instructies louter te schrappen om het bestand in te korten. Stel ontbrekende build- of testcommando’s alleen voor als je deze kunt verifiëren in project-scripts, een Makefile, CI-configuratie of bestaande documentatie. Vermeld de bron voor elke toevoeging. Lever een voorgestelde diff in die belangrijke projectbeperkingen in stand houdt. Markeer taakspecifieke instructies die beter zouden passen in een skill of een regel op padniveau, en wacht op goedkeuring voordat je wijzigingen doorvoert.

Stel een Claude Code-commando-hook voor die [bestaand formatter-commando] uitvoert na wijzigingen via ‘Edit’ of ‘Write’ in [bestands patronen]. Bekijk eerst de bestaande instelling in claude/settings.json en de instelling van de formatter. Gebruik de juiste PostToolUse-instelling voor de geïnstalleerde versie van Claude Code. Formatteer alleen het betreffende bestand, ga veilig om met paden en sluit [gegenereerde bestanden of andere uitgesloten paden] uit. Installeer geen afhankelijkheden en vervang geen bestaande hooks. Toon het verschil tussen de voorgestelde instellingen en leg uit hoe fouten van de formatter worden gerapporteerd. Wacht op goedkeuring voordat je het toepast. Test het na goedkeuring met een tijdelijk bestand in het project en rapporteer het resultaat. Geef aan welke bewerkingspaden het wel en welke het niet dekt, inclusief wijzigingen die via shell-commando's zijn aangebracht.

Bekijk [tool] –help en de helptekst voor subcommando’s die relevant zijn voor [Taak]. Installeer de tool niet als deze ontbreekt; meld in plaats daarvan dat dit een vereiste is. Stel de exacte commando’s voor die nodig zijn om de Taak te voltooien. Leg de invoer en uitvoer uit, en geef aan of ze bestanden schrijven, externe bronnen wijzigen of inloggegevens gebruiken. Neem een dry-run-optie op als de tool die documenteert. Signaleer ontbrekende configuratie of toestemming, en vraag om opheldering in plaats van te gissen naar bronnamen of bestemmingen. Wacht op goedkeuring voordat je de Taak-commando’s uitvoert. Voer na goedkeuring alleen de overeengekomen commando’s uit en rapporteer de daadwerkelijke resultaten, inclusief eventuele fouten of onvolledige stappen.

Vergelijk [invoices.csv] en [payments.csv] aan de hand van [factuurnummer of overeenkomende sleutel]. Wijzig de bronbestanden niet. Pas de volgende regels toe: [valuta en afrondingstolerantie], [toewijzing van gedeeltelijke betalingen] en [afhandeling van terugbetalingen, kredieten en te veel betaalde bedragen]. Als een regel ontbreekt of een overeenkomst onduidelijk is, markeer dit dan in plaats van de betaling automatisch toe te wijzen. Behoud de ID’s van de bronrijen. Geef voor elke factuur het gefactureerde bedrag, de verrekende betalingen en het resterende saldo weer. Meld dubbele ID’s, niet-gekoppelde facturen, niet-gekoppelde betalingen en saldi buiten de tolerantie. Stem de totalen van facturen en betalingen afzonderlijk af. Verwerk elke bronrij zonder dubbeltelling; als een betaling over meerdere facturen is verdeeld, toon dan elke toewijzing en controleer of de toewijzingen het bedrag van de betaling niet overschrijden. Sla de resultaten op in [nieuwe uitvoerpaden] en vat uitzonderingen samen die moeten worden gecontroleerd.

Schrijf een script dat [export.csv] samenvat voor de periode van [startdatum en -tijd, inclusief] tot en met [einddatum en -tijd, exclusief], met gebruikmaking van [tijdzone] en [datumkolom]. Groepeer records op basis van [categorieregels] en bereken [vereiste statistieken]. Behandel dubbele ID's en ontbrekende waarden volgens [regels]. Wijzig het invoerbestand niet. Voer het script uit op [het exacte invoerbestand]. Rapporteer het aantal opgenomen en uitgesloten rijen, de categorietotalen en de records die niet konden worden geclassificeerd. Vergelijk de resultaten voor [drie categorieën] met de onafhankelijk gecontroleerde tellingen in [het referentiebestand]. Als die tellingen niet beschikbaar zijn, vermeld dan dat onafhankelijke validatie nog uitstaat. Toon afwijkingen en sla het rapport op in [nieuw uitvoerpad].

Lees [aangegeven bestanden of map] en stel een [documenttype en lengte] op voor [doelgroep], waarin [vragen of onderwerpen] aan bod komen. Ondersteun elke feitelijke bewering met een bestandsnaam en, indien beschikbaar, een verwijzing naar een pagina, paragraaf of regel. Maak onderscheid tussen directe citaten en parafrases, en beschouw een voorstel of verouderd document niet als een bevestigd, actueel besluit. Markeer tegenstrijdige bronnen, ontbrekende informatie en beweringen die je niet kunt verifiëren. Vul hiaten niet op met aannames en voer geen bewerking uit aan de bronbestanden. Lever het concept in met de bronvermeldingen en een korte lijst met onopgeloste vragen voor de beoordelaar.

Om een sjabloon aan te passen, vervang je de plaatshouders door gegevens uit je project en bepaal je wat Claude moet doen voordat je wijzigingen aanbrengt. Volg deze stappen om het verzoek voor te bereiden en het resultaat te beoordelen.

Voor een kleine, duidelijk omschreven wijziging kun je Claude vragen deze direct door te voeren. Bij onbekende code, wijzigingen in meerdere bestanden of onduidelijke vereisten is het raadzaam om eerst een plan op te stellen.

Druk op Shift+Tab totdat de Plan-modus verschijnt, of start Claude Code met claude --permission-mode plan. In deze modus kan Claude bestanden inspecteren en alleen-lezen commando's uitvoeren zonder je broncode te bewerken. Bekijk de voorgestelde bestanden, afhankelijkheden en tests voordat je de implementatie goedkeurt. Druk op Ctrl+G om het voorgestelde plan in je editor te openen.

Geef Claude de informatie die nodig is om de Taak te begrijpen: een bestandsverwijzing, een opgeschoond foutenlogboek, een schermafbeelding of een document met vereisten. Gebruik @ gevolgd door een bestandspad om de content van dat bestand op te nemen.

Kies de kleinste bruikbare set bronnen. Het opnemen van een volledig logbestand of een volledige map kan irrelevante informatie toevoegen en context verspillen. Verwijder inloggegevens en gevoelige gegevens voordat u logbestanden deelt, en controleer of Claude over de benodigde tools beschikt om de door u opgegeven URL’s naar documentatie op te halen.

Als voorbeeld: fout in het logbestand.log | claude -p "Explain this fout" verstuurt een logbestand via een niet-interactief verzoek. Gebruik dit alleen nadat je de content van het bestand hebt gecontroleerd. Dit is de praktische waarde van contextuele AI: het model relevante informatie voor de Taak verstrekken.

Zoek bij het toevoegen van een functie een vergelijkbare component of functie in de opslagplaats. Geef aan Claude door welke conventies hij moet volgen, zoals de API-client, validatielogica, foutafhandeling of teststructuur.

“Volg hoe @src/widgets/Weather.tsx gegevens ophaalt en in de cache opslaat” geeft Claude een concreet referentiepunt. Noem ook eventuele verschillen die de nieuwe functie vereist, zodat er geen gedrag wordt gekopieerd dat niet langer past. Deze conventies moeten aansluiten bij de softwareontwikkelingswerkstroom van je team.

Geef bij codewijzigingen het relevante test-, build- of lint-commando op, evenals het gedrag dat moet worden gecontroleerd. Vraag voor onderzoek naar bestandsreferenties of commit-ID’s. Geef bij UI-werk een referentieafbeelding en een geconfigureerde manier om de implementatie binnen dezelfde viewport vast te leggen.

Vraag Claude om de rapportage uit te voeren over wat er daadwerkelijk is gecontroleerd, inclusief fouten en overgeslagen controles. Controleer of het bewijs voldoet aan de vereisten; een geslaagde build betekent niet automatisch dat elk gewenst gedrag werkt.

Voor langere taken biedt Claude Code ook een /goal-voorwaarde en Stop-hooks. De doelbeoordelaar evalueert bewijsmateriaal dat tijdens het gesprek naar voren komt, in plaats van zelfstandig bestanden te inspecteren of tests uit te voeren. Een geconfigureerde Stop-hook kan de voltooiing blokkeren, maar er gelden limieten voor herhaaldelijk blokkeren. Geen van beide vervangt passende tests en menselijke beoordeling.

Als herhaalde correcties een probleem niet oplossen, stop dan even en breng in kaart wat er in de oorspronkelijke aanvraag onduidelijk was. Sla de nuttige bevindingen, de huidige Git-status en het resterende werk op voordat je het gesprek wist.

De gids met best practices van Anthropic raadt aan om opnieuw te beginnen na twee mislukte correcties op hetzelfde probleem. Gebruik /clear en geef vervolgens een aangepaste prompt waarin je de geleerde lessen verwerkt. Het wissen van het gesprek maakt wijzigingen in bestanden niet ongedaan.

Druk op Esc om een lopende respons te onderbreken. Als het invoerveld leeg is, druk je twee keer op Esc om het terugspoelmenu te openen en te kiezen wat je wilt herstellen. Terugspoelen maakt niet alle externe effecten ongedaan, dus gebruik Git-checkpoints en afzonderlijke herstelprocedures voor wijzigingen in databases of externe diensten.

Sla projectbrede richtlijnen op in CLAUDE.md, herhaalbare procedures in skills en instructies voor specifieke bestanden in regels die gelden voor een bepaald pad. Gebruik hooks voor acties die aan specifieke gebeurtenissen zijn gekoppeld, zoals het uitvoeren van een formatter na een bewerking.

Maak een keuze op basis van het moment waarop de instructie van toepassing moet zijn:

Een vereiste voor een bepaalde functie hoort meestal thuis in de bijbehorende taakopdracht of specificatie, en niet in CLAUDE.md. Door tijdelijke instructies toe te voegen aan een projectbestand, worden ze moeilijker te onderscheiden van conventies die in de hele opslagplaats van toepassing zouden moeten zijn.

Als voorbeeld zet je het testcommando van het project in CLAUDE.md, plaats component-specifieke conventies in een regel met een pad-scope en sla een terugkerende beoordelingsprocedure op als een skill. Controleer deze bestanden wanneer commando’s of conventies veranderen, net zoals je dat bij andere projectdocumentatie zou doen.

Prompts, CLAUDE.md en vaardigheden sturen het gedrag van Claude aan; ze garanderen niet dat een instructie wordt opgevolgd. Hooks kunnen controles uitvoeren bij geconfigureerde gebeurtenissen, maar de betrouwbaarheid ervan hangt af van het type hook en de implementatie.

Een command hook voert een script uit. Een prompt- of agent-hook is afhankelijk van het oordeel van een model. Zoals in de gids met best practices van Anthropic wordt uitgelegd: “Een prompt- of agent-hook vraagt een ander model om een beslissing te nemen, dus ook deze is niet deterministisch.” Gebruik voor een regel die moet worden afgedwongen de juiste toestemming en test de betreffende command- of HTTP-hook, inclusief hoe deze omgaat met fouten.

Aangepaste subagenten zijn een andere manier om terugkerende taken te organiseren. Definieer een specialist in `claude/agents/` wanneer er een aparte beoordelingsrol of toolscope nodig is, in plaats van elke specialistische instructie aan de hoofdsessie toe te voegen. Deze handleidingen over het beste Claude-model voor werk en soorten AI-agenten bieden aanvullende context.

Als je team prompts voor verschillende AI-producten beheert, bekijk dan deze tools voor prompt-engineering om bibliotheken buiten Claude Code te beheren.

Wanneer een sessie een onvolledig of ongeschikt resultaat oplevert, controleer dan of er in de opdracht belangrijke beslissingen onopgelost zijn gebleven. Deze vijf fouten kunnen het diagnosticeren en beoordelen van het werk bemoeilijken.

“Onderzoek de opslagplaats” geeft Claude weinig aanwijzingen over welke bestanden van belang zijn of wanneer hij moet stoppen. Mogelijk ontvangt u een algemene samenvatting zonder antwoord op het probleem dat aanleiding gaf tot het verzoek.

Geef een naam aan het gedrag of de beslissing die je moet begrijpen, bepaal een startlocatie en definieer de verwachte uitvoer. Bijvoorbeeld: „Traceer hoe dit eindpunt toestemming controleert en noem de relevante functies.” Als je subagenten gebruikt, geef elke subagent dan een afgebakende vraag in plaats van dezelfde onbeperkte zoekopdracht te delegeren.

Als je schakelt tussen een functie, een niet-gerelateerde bug en een verzoek om documentatie, blijft er context in het gesprek hangen die mogelijk niet van toepassing is op de huidige Taak. Verwijzingen zoals ‘dat bestand’ of ‘de eerdere aanpak’ worden dan dubbelzinnig.

Gebruik aparte sessies voor werk dat geen verband houdt met elkaar. Als er vanuit meerdere sessies bewerkingen in de opslagplaats worden uitgevoerd, gebruik dan aparte Git-werkbomen, zodat ze niet dezelfde werkdirectory wijzigen. Even terzijde: met het /btw-commando van Claude Code wordt de uitwisseling buiten de hoofdgeschiedenis van het gesprek gehouden.

Een build kan slagen terwijl een functie zich onjuist gedraagt. Een testsuite kan slagen omdat de foutieve invoer nooit is getest. Als je Claude vraagt om “de tests uit te voeren”, wordt daarmee niet vastgesteld welke vereiste die tests verifiëren.

Breng de acceptatiecriteria in kaart met specifieke controles. Vraag bij het verhelpen van een bug om bewijs dat de reproductietest vóór de wijziging mislukte en erna slaagde. Houd niet-geteste criteria zichtbaar in plaats van één geslaagd commando te beschouwen als verificatie van de gehele wijziging.

Een steeds groter wordend CLAUDE.md-bestand kan verouderde commando’s, dubbele regels en instructies bevatten die in strijd zijn met taakspecifieke vereisten. Het toevoegen van strengere bewoordingen lost deze conflicten niet op.

Vergelijk het bestand met de huidige opslagplaats. Verwijder verouderde richtlijnen, verduidelijk tegenstrijdige regels en verplaats instructies met een beperkte toepasbaarheid naar regels of vaardigheden die binnen een bepaald pad gelden. Als een vereiste moet worden afgedwongen, configureer en test dan de juiste controles in plaats van te vertrouwen op herhaalde herinneringen.

Een beoordeling kan zowel echte fouten, onduidelijke punten van zorg als optionele suggesties voor refactoring aan het licht brengen. Het toepassen van elke suggestie kan de omvang van de wijziging vergroten zonder dat het gewenste gedrag daardoor wordt verbeterd.

Vraag naar het bewijs en de impact achter elke bevinding. Geef prioriteit aan problemen en niet-voldane vereisten, onderzoek onduidelijke beweringen en houd niet-gerelateerde verbeteringen buiten de huidige diff. Een reviewer moet in staat zijn om te melden dat er geen actiegerichte problemen zijn wanneer het bewijs die conclusie ondersteunt.

Om een sjabloon aan te passen, vervang je de plaatshouders door gegevens uit je project en bepaal je wat Claude moet doen voordat je wijzigingen aanbrengt. Volg deze stappen om het verzoek voor te bereiden en het resultaat te beoordelen.

Voor een kleine, duidelijk omschreven wijziging kun je Claude vragen deze direct door te voeren. Bij onbekende code, wijzigingen in meerdere bestanden of onduidelijke vereisten: begin met een plan.

Druk op Shift+Tab totdat de Plan-modus verschijnt, of start Claude Code met claude --permission-mode plan. In deze modus kan Claude bestanden inspecteren en alleen-lezen commando's uitvoeren zonder je code te bewerken. Bekijk de voorgestelde bestanden, afhankelijkheden en tests voordat je de implementatie goedkeurt. Druk op Ctrl+G om het voorgestelde plan in je editor te openen.

Geef Claude de informatie die nodig is om de Taak te begrijpen: een bestandsverwijzing, een opgeschoond log met fouten, een schermafbeelding of een document met vereisten. Gebruik @ gevolgd door een bestandspad om de content van dat bestand op te nemen.

Kies de kleinste bruikbare set bronnen. Het opnemen van een volledig logbestand of een volledige map kan irrelevante informatie toevoegen en context verspillen. Verwijder inloggegevens en gevoelige gegevens voordat u logbestanden deelt, en controleer of Claude over de benodigde tools beschikt om de door u opgegeven URL’s naar documentatie op te halen.

Als voorbeeld: `cat fout.log | claude -p "Explain deze fout"` verstuurt een logbestand via een niet-interactief verzoek. Gebruik dit alleen nadat je de inhoud van het bestand hebt gecontroleerd. Dit is de praktische waarde van contextuele AI: het model relevante informatie voor de Taak verstrekken.

Zoek bij het toevoegen van een functie een vergelijkbare component of functie in de opslagplaats. Geef aan Claude door welke conventies hij moet volgen, zoals de API-client, validatielogica, foutafhandeling of teststructuur.

“Volg hoe @src/widgets/Weather.tsx gegevens ophaalt en in de cache opslaat” geeft Claude een concreet referentiepunt. Noem ook eventuele verschillen die de nieuwe functie vereist, zodat er geen gedrag wordt gekopieerd dat niet langer past. Deze conventies moeten aansluiten bij de softwareontwikkelingswerkstroom van je team.

Geef bij codewijzigingen het relevante test-, build- of lint-commando op, evenals het gedrag dat moet worden gecontroleerd. Vraag voor onderzoek naar bestandsreferenties of commit-ID's. Geef bij UI-werk een referentieafbeelding en een geconfigureerde manier om de implementatie binnen dezelfde viewport vast te leggen.

Vraag Claude om een rapportage te leveren over wat er daadwerkelijk is gecontroleerd, inclusief fouten en overgeslagen controles. Controleer of het bewijsmateriaal voldoet aan de vereisten; een geslaagde build betekent niet automatisch dat elk gewenst gedrag werkt.

Voor langere taken biedt Claude Code ook een /doel-voorwaarde en Stop-hooks. De doelbeoordelaar evalueert bewijsmateriaal dat tijdens het gesprek naar voren komt, in plaats van zelfstandig bestanden te inspecteren of tests uit te voeren. Een geconfigureerde Stop-hook kan de voltooiing blokkeren, maar er gelden limieten voor herhaaldelijk blokkeren. Geen van beide vervangt passende tests en menselijke beoordeling.

Als herhaalde correcties een probleem niet oplossen, stop dan even en breng in kaart wat er in de oorspronkelijke aanvraag onduidelijk was. Sla de nuttige bevindingen, de huidige Git-status en het resterende werk op voordat je het gesprek wist.

De gids met best practices van Anthropic raadt aan om opnieuw te beginnen na twee mislukte correcties op hetzelfde probleem. Gebruik /clear en geef vervolgens een aangepaste prompt waarin je de geleerde lessen verwerkt. Het wissen van het gesprek maakt wijzigingen in bestanden niet ongedaan.

Druk op Esc om een lopende respons te onderbreken. Als het invoerveld leeg is, druk je twee keer op Esc om het terugspoelmenu te openen en te kiezen wat je wilt herstellen. Terugspoelen maakt niet alle externe effecten ongedaan, dus gebruik Git-checkpoints en afzonderlijke herstelprocedures voor wijzigingen in databases of externe diensten.

Sla projectbrede richtlijnen op in CLAUDE.md, herhaalbare procedures in skills en instructies voor specifieke bestanden in regels die gelden voor een bepaald pad. Gebruik hooks voor acties die aan specifieke gebeurtenissen zijn gekoppeld, zoals het uitvoeren van een formatter na een bewerking.

Kies op basis van het moment waarop de instructie van toepassing moet zijn:

Een vereiste voor een bepaalde functie hoort meestal thuis in de bijbehorende taakopdracht of specificatie, en niet in CLAUDE.md. Door tijdelijke instructies toe te voegen aan een projectbestand, worden ze moeilijker te onderscheiden van conventies die in de hele opslagplaats van toepassing zouden moeten zijn.

Zet bijvoorbeeld het testcommando van het project in CLAUDE.md, plaats component-specifieke conventies in een regel met een pad-scope en sla een terugkerende beoordelingsprocedure op als een skill. Bekijk deze bestanden wanneer commando’s of conventies veranderen, net zoals je dat bij andere projectdocumentatie zou doen.

Prompts, CLAUDE.md en vaardigheden sturen het gedrag van Claude aan; ze garanderen niet dat een instructie wordt opgevolgd. Hooks kunnen controles uitvoeren bij geconfigureerde gebeurtenissen, maar de betrouwbaarheid ervan hangt af van het type hook en de implementatie.

Een command hook voert een script uit. Een prompt- of agent-hook is afhankelijk van het oordeel van een model. Zoals in de gids met best practices van Anthropic wordt uitgelegd: “Een prompt- of agent-hook vraagt een ander model om een beslissing te nemen, dus ook deze is niet deterministisch.” Gebruik voor een regel die moet worden afgedwongen de juiste toestemmingcontroles en test de betreffende command- of HTTP-hook, inclusief hoe deze omgaat met fouten.

Aangepaste subagenten zijn een andere manier om terugkerende taken te organiseren. Definieer een specialist in `claude/agents/` wanneer er een aparte beoordelingsrol of toolscope nodig is, in plaats van elke specialistische instructie aan de hoofdsessie toe te voegen. Deze handleidingen over het beste Claude-model voor werk en soorten AI-agenten bieden aanvullende context.

Als je team prompts voor verschillende AI-producten beheert, bekijk dan deze tools voor prompt-engineering om bibliotheken buiten Claude Code te beheren.

Wanneer een sessie een onvolledig of ongeschikt resultaat oplevert, controleer dan of er in de opdracht belangrijke beslissingen onopgelost zijn gebleven. Deze vijf fouten kunnen het diagnosticeren en beoordelen van het werk bemoeilijken.

“Onderzoek de opslagplaats” geeft Claude weinig aanwijzingen over welke bestanden van belang zijn of wanneer hij moet stoppen. Mogelijk ontvangt u een algemene samenvatting zonder antwoord op het probleem dat aanleiding gaf tot het verzoek.

Geef een naam aan het gedrag of de beslissing die je moet begrijpen, bepaal een locatie en definieer de verwachte uitvoer. Bijvoorbeeld: „Traceer hoe dit eindpunt toestemming controleert en noem de relevante functies.” Als je subagenten gebruikt, geef elke subagent dan een afgebakende vraag in plaats van dezelfde onbeperkte zoekopdracht te delegeren.

Als je schakelt tussen een functie, een niet-gerelateerde bug en een verzoek om documentatie, blijft er context in het gesprek hangen die mogelijk niet van toepassing is op de huidige Taak. Verwijzingen zoals ‘dat bestand’ of ‘de eerdere aanpak’ worden dan dubbelzinnig.

Gebruik aparte sessies voor werk dat geen verband houdt met elkaar. Als er vanuit meerdere sessies bewerkingen in de opslagplaats worden uitgevoerd, gebruik dan aparte Git-werkbomen, zodat ze niet dezelfde werkdirectory wijzigen. Even terzijde: met het /btw-commando van Claude Code wordt de uitwisseling buiten de hoofdgeschiedenis van het gesprek gehouden.

Een build kan slagen terwijl een functie zich onjuist gedraagt. Een testsuite kan slagen omdat de foutieve invoer nooit is getest. Als je Claude vraagt om “de tests uit te voeren”, wordt daarmee niet vastgesteld welke vereiste die tests verifiëren.

Breng de acceptatiecriteria in kaart met specifieke controles. Vraag bij het verhelpen van een bug om bewijs dat de reproductietest vóór de wijziging mislukte en erna slaagde. Houd niet-geteste criteria zichtbaar in plaats van één succesvol commando te beschouwen als verificatie van de gehele wijziging.

Een steeds groter wordend CLAUDE.md-bestand kan verouderde commando’s, dubbele regels en instructies bevatten die in strijd zijn met taakspecifieke vereisten. Het toevoegen van strengere bewoordingen lost deze conflicten niet op.

Vergelijk het bestand met de huidige opslagplaats. Verwijder verouderde richtlijnen, verduidelijk tegenstrijdige regels en verplaats instructies met een beperkte toepasbaarheid naar regels of vaardigheden die binnen een bepaald pad gelden. Als een vereiste moet worden afgedwongen, configureer en test dan de juiste controles in plaats van te vertrouwen op herhaalde herinneringen.

Een beoordeling kan zowel echte fouten, onduidelijke punten van zorg als optionele suggesties voor refactoring aan het licht brengen. Het toepassen van elke suggestie kan de omvang van de wijziging vergroten zonder dat het gewenste gedrag daardoor wordt verbeterd.

Vraag naar het bewijs en de impact achter elke bevinding. Geef prioriteit aan problemen en niet-voldane vereisten, onderzoek onduidelijke beweringen en houd niet-gerelateerde verbeteringen buiten de huidige diff. Een reviewer moet in staat zijn om te melden dat er geen actiegerichte problemen zijn wanneer het bewijs die conclusie ondersteunt.

Om een sjabloon aan te passen, vervang je de plaatshouders door gegevens uit je project en bepaal je wat Claude moet doen voordat je wijzigingen aanbrengt. Volg deze stappen om het verzoek voor te bereiden en het resultaat te beoordelen.

Voor een kleine, duidelijk omschreven wijziging kun je Claude vragen deze direct door te voeren. Bij onbekende code, wijzigingen in meerdere bestanden of onduidelijke vereisten: begin met een plan.

Druk op Shift+Tab totdat de Plan-modus verschijnt, of start Claude Code met claude --permission-mode plan. In deze modus kan Claude bestanden inspecteren en alleen-lezen commando's uitvoeren zonder je broncode te bewerken. Bekijk de voorgestelde bestanden, afhankelijkheden en tests voordat je de implementatie goedkeurt. Druk op Ctrl+G om het voorgestelde plan in je editor te openen.

Geef Claude de informatie die nodig is om de Taak te begrijpen: een bestandsverwijzing, een opgeschoond log met fouten, een schermafbeelding of een document met vereisten. Gebruik @ gevolgd door een bestandspad om de content van dat bestand op te nemen.

Kies de kleinste bruikbare set bronnen. Het opnemen van een volledig logbestand of een volledige map kan irrelevante informatie toevoegen en context verspillen. Verwijder inloggegevens en gevoelige gegevens voordat u logbestanden deelt, en controleer of Claude over de benodigde tools beschikt om de door u opgegeven URL’s naar documentatie op te halen.

Als voorbeeld: fout in het logbestand.log | claude -p "Explain this fout" verstuurt een logbestand via een niet-interactief verzoek. Gebruik dit alleen nadat je de inhoud van het bestand hebt gecontroleerd. Dit is de praktische waarde van contextuele AI: het model relevante informatie voor de Taak verstrekken.

Zoek bij het toevoegen van een functie een vergelijkbare component of functie in de opslagplaats. Geef aan Claude door welke conventies hij moet volgen, zoals de API-client, validatielogica, foutafhandeling of teststructuur.

“Volg hoe @src/widgets/Weather.tsx gegevens ophaalt en in de cache opslaat” geeft Claude een concreet referentiepunt. Noem ook eventuele verschillen die de nieuwe functie vereist, zodat er geen gedrag wordt gekopieerd dat niet langer past. Deze conventies moeten aansluiten bij de softwareontwikkelingswerkstroom van je team.

Geef bij codewijzigingen het relevante test-, build- of lint-commando op, evenals het gedrag dat moet worden gecontroleerd. Vraag voor onderzoek naar bestandsreferenties of commit-ID’s. Geef bij UI-werk een referentieafbeelding en een geconfigureerde manier om de implementatie binnen dezelfde viewport vast te leggen.

Vraag Claude om een rapportage te leveren over wat er daadwerkelijk is gecontroleerd, inclusief fouten en overgeslagen controles. Controleer of de bevindingen voldoen aan de vereisten; een geslaagde build betekent niet automatisch dat elk gewenst gedrag werkt.

Voor langere taken biedt Claude Code ook een /goal-voorwaarde en Stop-hooks. De doelbeoordelaar evalueert bewijsmateriaal dat tijdens het gesprek naar voren komt, in plaats van zelfstandig bestanden te inspecteren of tests uit te voeren. Een geconfigureerde Stop-hook kan de voltooiing blokkeren, maar er gelden limieten voor herhaaldelijk blokkeren. Geen van beide vervangt passende tests en menselijke beoordeling.

Als herhaalde correcties een probleem niet oplossen, stop dan even en breng in kaart wat er in de oorspronkelijke aanvraag onduidelijk was. Sla de nuttige bevindingen, de huidige Git-status en het resterende werk op voordat je het gesprek wist.

De gids met best practices van Anthropic raadt aan om opnieuw te beginnen na twee mislukte correcties op hetzelfde probleem. Gebruik /clear en geef vervolgens een aangepaste prompt waarin je de geleerde lessen verwerkt. Het wissen van het gesprek maakt wijzigingen in bestanden niet ongedaan.

Druk op Esc om een lopende respons te onderbreken. Als het invoerveld leeg is, druk je twee keer op Esc om het terugspoelmenu te openen en te kiezen wat je wilt herstellen. Terugspoelen maakt niet alle externe effecten ongedaan, dus gebruik Git-checkpoints en aparte herstelprocedures voor wijzigingen in databases of externe diensten.

Sla projectbrede richtlijnen op in CLAUDE.md, herhaalbare procedures in skills en instructies voor specifieke bestanden in regels die gelden voor een bepaald pad. Gebruik hooks voor acties die aan specifieke gebeurtenissen zijn gekoppeld, zoals het uitvoeren van een formatter na een bewerking.

Maak een keuze op basis van het moment waarop de instructie van toepassing moet zijn:

Een vereiste voor een bepaalde functie hoort meestal thuis in de bijbehorende taakopdracht of specificatie, en niet in CLAUDE.md. Door tijdelijke instructies toe te voegen aan een projectbestand, worden ze moeilijker te onderscheiden van conventies die in de hele opslagplaats van toepassing zouden moeten zijn.

Als voorbeeld zet je bijvoorbeeld het testcommando van het project in CLAUDE.md, plaats component-specifieke conventies in een regel met een pad-scope en sla een terugkerende beoordelingsprocedure op als een skill. Controleer deze bestanden wanneer commando’s of conventies veranderen, net zoals je dat bij andere projectdocumentatie zou doen.

Prompts, CLAUDE.md en vaardigheden sturen het gedrag van Claude aan; ze garanderen niet dat een instructie wordt opgevolgd. Hooks kunnen controles uitvoeren bij geconfigureerde gebeurtenissen, maar de betrouwbaarheid ervan hangt af van het type hook en de implementatie.

Een command hook voert een script uit. Een prompt- of agent-hook is afhankelijk van het oordeel van een model. Zoals in de gids met best practices van Anthropic wordt uitgelegd: „Een prompt- of agent-hook vraagt een ander model om een beslissing te nemen, dus is deze ook niet deterministisch.” Gebruik voor een regel die moet worden afgedwongen de juiste toestemming en test de betreffende command- of HTTP-hook, inclusief hoe deze omgaat met fouten.

Aangepaste subagenten zijn een andere manier om terugkerende taken te organiseren. Definieer een specialist in `claude/agents/` wanneer er een aparte beoordelingsrol of toolscope nodig is, in plaats van elke specialistische instructie aan de hoofdsessie toe te voegen. Deze handleidingen over het beste Claude-model voor werk en soorten AI-agenten bieden aanvullende context.

Als je team prompts voor verschillende AI-producten beheert, bekijk dan deze tools voor prompt-engineering om bibliotheken buiten Claude Code te beheren.

Wanneer een sessie een onvolledig of ongeschikt resultaat oplevert, controleer dan of er in de opdracht belangrijke beslissingen onopgelost zijn gebleven. Deze vijf fouten kunnen het diagnosticeren en beoordelen van het werk bemoeilijken.

“Onderzoek de opslagplaats” geeft Claude weinig aanwijzingen over welke bestanden van belang zijn of wanneer hij moet stoppen. Mogelijk ontvangt u een algemene samenvatting zonder antwoord op het probleem dat aanleiding gaf tot het verzoek.

Geef een naam aan het gedrag of de beslissing die je moet begrijpen, bepaal een locatie en definieer de verwachte uitvoer. Bijvoorbeeld: „Traceer hoe dit eindpunt toestemming controleert en noem de relevante functies.” Als je subagenten gebruikt, geef elke subagent dan een afgebakende vraag in plaats van dezelfde onbeperkte zoekopdracht te delegeren.

Als je schakelt tussen een functie, een niet-gerelateerde bug en een verzoek om documentatie, blijft er context in het gesprek hangen die mogelijk niet van toepassing is op de huidige Taak. Verwijzingen zoals ‘dat bestand’ of ‘de eerdere aanpak’ worden dan dubbelzinnig.

Gebruik aparte sessies voor werk dat geen verband houdt met elkaar. Als er vanuit meerdere sessies bewerkingen in de opslagplaats worden uitgevoerd, gebruik dan aparte Git-werkbomen, zodat ze niet dezelfde werkdirectory wijzigen. Even terzijde: met het /btw-commando van Claude Code wordt de uitwisseling buiten de hoofdgeschiedenis van het gesprek gehouden.

Een build kan slagen terwijl een functie zich onjuist gedraagt. Een testsuite kan slagen omdat de foutieve invoer nooit is getest. Als je Claude vraagt om “de tests uit te voeren”, wordt daarmee niet vastgesteld welke vereiste die tests verifiëren.

Breng de acceptatiecriteria in kaart met specifieke controles. Vraag bij het verhelpen van een bug om bewijs dat de reproductietest vóór de wijziging mislukte en erna slaagde. Houd niet-geteste criteria zichtbaar in plaats van één geslaagd commando te beschouwen als verificatie van de gehele wijziging.

Een steeds groter wordend CLAUDE.md-bestand kan verouderde commando’s, dubbele regels en instructies bevatten die in strijd zijn met taakspecifieke vereisten. Het toevoegen van strengere bewoordingen lost deze conflicten niet op.

Vergelijk het bestand met de huidige opslagplaats. Verwijder verouderde richtlijnen, verduidelijk tegenstrijdige regels en verplaats instructies met een beperkte toepasbaarheid naar regels of vaardigheden die binnen een bepaald pad gelden. Als een vereiste moet worden afgedwongen, configureer en test dan de juiste controles in plaats van te vertrouwen op herhaalde herinneringen.

Een beoordeling kan zowel echte fouten, onduidelijke punten van zorg als optionele suggesties voor refactoring aan het licht brengen. Het toepassen van elke suggestie kan de omvang van de wijziging vergroten zonder dat het gewenste gedrag daardoor wordt verbeterd.

Vraag naar het bewijs en de impact achter elke bevinding. Geef prioriteit aan problemen en niet-voldane vereisten, onderzoek onduidelijke beweringen en houd niet-gerelateerde verbeteringen buiten de huidige diff. Een reviewer moet in staat zijn om te melden dat er geen actiegerichte bevindingen zijn wanneer het bewijs die conclusie ondersteunt.

Om een sjabloon aan te passen, vervang je de plaatshouders door gegevens uit je project en bepaal je wat Claude moet doen voordat je wijzigingen aanbrengt. Volg deze stappen om het verzoek voor te bereiden en het resultaat te beoordelen.

Voor een kleine, duidelijk omschreven wijziging kun je Claude vragen deze direct door te voeren. Bij onbekende code, wijzigingen in meerdere bestanden of onduidelijke vereisten is het raadzaam om eerst een plan op te stellen.

Druk op Shift+Tab totdat de Plan-modus verschijnt, of start Claude Code met claude --permission-mode plan. In deze modus kan Claude bestanden inspecteren en alleen-lezen commando's uitvoeren zonder je broncode te bewerken. Bekijk de voorgestelde bestanden, afhankelijkheden en tests voordat je de implementatie goedkeurt. Druk op Ctrl+G om het voorgestelde plan in je editor te openen.

Geef Claude de informatie die nodig is om de Taak te begrijpen: een bestandsverwijzing, een opgeschoond logboek met fouten, een schermafbeelding of een document met vereisten. Gebruik @ gevolgd door een bestandspad om de content van dat bestand op te nemen.

Kies de kleinste bruikbare set bronnen. Het opnemen van een volledig logbestand of een volledige map kan irrelevante informatie toevoegen en context verspillen. Verwijder inloggegevens en gevoelige gegevens voordat je logbestanden deelt, en controleer of Claude over de benodigde tools beschikt om de door jou opgegeven documentatie-URL’s op te halen.

Als voorbeeld: `cat fout.log | claude -p "Explain deze fout"` verstuurt een logbestand via een niet-interactief verzoek. Gebruik dit alleen nadat je de inhoud van het bestand hebt gecontroleerd. Dit is de praktische waarde van contextuele AI: het model relevante informatie voor de taak verstrekken.

Zoek bij het toevoegen van een functie een vergelijkbare component of functie in de opslagplaats. Geef aan Claude door welke conventies hij moet volgen, zoals de API-client, validatielogica, foutafhandeling of teststructuur.

“Volg hoe @src/widgets/Weather.tsx gegevens ophaalt en in de cache opslaat” geeft Claude een concreet referentiepunt. Noem ook eventuele verschillen die de nieuwe functie vereist, zodat er geen gedrag wordt gekopieerd dat niet langer past. Deze conventies moeten aansluiten bij de softwareontwikkelingswerkstroom van je team.

Geef bij codewijzigingen het relevante test-, build- of lint-commando op, evenals het gedrag dat moet worden gecontroleerd. Vraag voor onderzoek naar bestandsreferenties of commit-ID’s. Geef bij UI-werk een referentieafbeelding en een geconfigureerde manier om de implementatie binnen dezelfde viewport vast te leggen.

Vraag Claude om de rapportage uit te voeren over wat er daadwerkelijk is gecontroleerd, inclusief fouten en overgeslagen controles. Controleer of de bevindingen voldoen aan de vereisten; een geslaagde build betekent niet automatisch dat elk gewenst gedrag werkt.

Voor langere taken biedt Claude Code ook een /goal-voorwaarde en Stop-hooks. De doelbeoordelaar evalueert bewijsmateriaal dat tijdens het gesprek naar voren komt, in plaats van zelfstandig bestanden te inspecteren of tests uit te voeren. Een geconfigureerde Stop-hook kan de voltooiing blokkeren, maar er gelden limieten voor herhaaldelijk blokkeren. Geen van beide vervangt passende tests en menselijke beoordeling.

Als herhaalde correcties een probleem niet oplossen, stop dan even en breng in kaart wat er in de oorspronkelijke aanvraag onduidelijk was. Sla de nuttige bevindingen, de huidige Git-status en het resterende werk op voordat je het gesprek wist.

De gids met best practices van Anthropic raadt aan om opnieuw te beginnen na twee mislukte correcties op hetzelfde probleem. Gebruik /clear en geef vervolgens een aangepaste prompt waarin je de geleerde lessen verwerkt. Het wissen van het gesprek maakt wijzigingen in bestanden niet ongedaan.

Druk op Esc om een lopende respons te onderbreken. Als het invoerveld leeg is, druk je twee keer op Esc om het terugspoelmenu te openen en te kiezen wat je wilt herstellen. Terugspoelen maakt niet alle externe effecten ongedaan, dus gebruik Git-checkpoints en afzonderlijke herstelprocedures voor wijzigingen in databases of externe diensten.

Sla projectbrede richtlijnen op in CLAUDE.md, herhaalbare procedures in skills en instructies voor specifieke bestanden in regels die gelden voor een bepaald pad. Gebruik hooks voor acties die aan specifieke gebeurtenissen zijn gekoppeld, zoals het uitvoeren van een formatter na een bewerking.

Maak een keuze op basis van het moment waarop de instructie van toepassing moet zijn:

Een vereiste voor een bepaalde functie hoort meestal thuis in de bijbehorende taakopdracht of specificatie, en niet in CLAUDE.md. Door tijdelijke instructies toe te voegen aan een projectbestand, worden ze moeilijker te onderscheiden van conventies die in de hele opslagplaats van toepassing zouden moeten zijn.

Zet bijvoorbeeld het testcommando van het project in CLAUDE.md, plaats component-specifieke conventies in een regel met een pad-scope en sla een terugkerende beoordelingsprocedure op als een skill. Controleer deze bestanden wanneer commando’s of conventies veranderen, net zoals je dat bij andere projectdocumentatie zou doen.

Prompts, CLAUDE.md en vaardigheden sturen het gedrag van Claude aan; ze garanderen niet dat een instructie wordt opgevolgd. Hooks kunnen controles uitvoeren bij geconfigureerde gebeurtenissen, maar de betrouwbaarheid ervan hangt af van het type hook en de implementatie.

Een command hook voert een script uit. Een prompt- of agent-hook is afhankelijk van het oordeel van een model. Zoals in de gids met best practices van Anthropic wordt uitgelegd: “Een prompt- of agent-hook vraagt een ander model om een beslissing te nemen, dus ook deze is niet deterministisch.” Gebruik voor een regel die moet worden afgedwongen de juiste toestemmingcontroles en test de betreffende command- of HTTP-hook, inclusief hoe deze omgaat met fouten.

Aangepaste subagenten zijn een andere manier om terugkerende taken te organiseren. Definieer een specialist in `claude/agents/` wanneer er een aparte beoordelingsrol of toolscope nodig is, in plaats van elke specialistische instructie aan de hoofdsessie toe te voegen. Deze handleidingen over het beste Claude-model voor werk en soorten AI-agenten bieden aanvullende context.

Als je team prompts voor verschillende AI-producten beheert, bekijk dan deze tools voor prompt-engineering om bibliotheken buiten Claude Code te beheren.

Wanneer een sessie een onvolledig of ongeschikt resultaat oplevert, controleer dan of er in de opdracht belangrijke beslissingen onopgelost zijn gebleven. Deze vijf fouten kunnen het diagnosticeren en beoordelen van het werk bemoeilijken.

„Onderzoek de opslagplaats“ geeft Claude weinig aanwijzingen over welke bestanden van belang zijn of wanneer hij moet stoppen. Mogelijk ontvangt u een algemene samenvatting zonder antwoord op het probleem dat aanleiding gaf tot het verzoek.

Geef een naam aan het gedrag of de beslissing die je moet begrijpen, bepaal een startlocatie en definieer de verwachte uitvoer. Als voorbeeld: „Traceer hoe dit eindpunt toestemming controleert en noem de relevante functies.” Als je subagenten gebruikt, geef elke subagent dan een afgebakende vraag in plaats van dezelfde onbeperkte zoekopdracht te delegeren.

Als je schakelt tussen een functie, een niet-gerelateerde bug en een verzoek om documentatie, blijft er context in het gesprek hangen die mogelijk niet van toepassing is op de huidige Taak. Verwijzingen zoals ‘dat bestand’ of ‘de eerdere aanpak’ worden dan dubbelzinnig.

Gebruik aparte sessies voor werk dat geen verband houdt met elkaar. Als er vanuit meerdere sessies bewerkingen in de opslagplaats worden uitgevoerd, gebruik dan aparte Git-werkbomen, zodat ze niet dezelfde werkdirectory wijzigen. Even terzijde: met het /btw-commando van Claude Code wordt de uitwisseling buiten de hoofdgeschiedenis van het gesprek gehouden.

Een build kan slagen terwijl een functie zich onjuist gedraagt. Een testsuite kan slagen omdat de foutieve invoer nooit is getest. Als je Claude vraagt om “de tests uit te voeren”, wordt daarmee niet vastgesteld welke vereiste die tests verifiëren.

Breng de acceptatiecriteria in kaart met specifieke controles. Vraag bij het verhelpen van een bug om bewijs dat de reproductietest vóór de wijziging mislukte en erna slaagde. Houd niet-geteste criteria zichtbaar in plaats van één geslaagd commando te beschouwen als verificatie van de gehele wijziging.

Een steeds groter wordend CLAUDE.md-bestand kan verouderde commando’s, dubbele regels en instructies bevatten die in strijd zijn met taakspecifieke vereisten. Het toevoegen van strengere bewoordingen lost deze conflicten niet op.

Vergelijk het bestand met de huidige opslagplaats. Verwijder verouderde richtlijnen, verduidelijk tegenstrijdige regels en verplaats instructies met een beperkte toepasbaarheid naar regels of vaardigheden die binnen een bepaald pad gelden. Als een vereiste moet worden afgedwongen, configureer en test dan de juiste controles in plaats van te vertrouwen op herhaalde herinneringen.

Een beoordeling kan zowel echte fouten, onduidelijke punten van zorg als optionele suggesties voor refactoring aan het licht brengen. Het toepassen van elke suggestie kan de omvang van de wijziging vergroten zonder dat het gewenste gedrag daardoor wordt verbeterd.

Vraag naar het bewijs en de impact achter elke bevinding. Geef prioriteit aan problemen en niet-voldane vereisten, onderzoek onduidelijke beweringen en houd niet-gerelateerde verbeteringen buiten de huidige diff. Een reviewer moet in staat zijn om te melden dat er geen actiegerichte bevindingen zijn wanneer het bewijs die conclusie ondersteunt.

Om een sjabloon aan te passen, vervang je de plaatshouders door gegevens uit je project en bepaal je wat Claude moet doen voordat je wijzigingen aanbrengt. Volg deze stappen om het verzoek voor te bereiden en het resultaat te beoordelen.

Voor een kleine, duidelijk omschreven wijziging kun je Claude vragen deze direct door te voeren. Bij onbekende code, wijzigingen in meerdere bestanden of onduidelijke vereisten: begin met een plan.

Druk op Shift+Tab totdat de Plan-modus verschijnt, of start Claude Code met claude --permission-mode plan. In deze modus kan Claude bestanden inspecteren en alleen-lezen commando's uitvoeren zonder je code te bewerken. Bekijk de voorgestelde bestanden, afhankelijkheden en tests voordat je de implementatie goedkeurt. Druk op Ctrl+G om het voorgestelde plan in je editor te openen.

Geef Claude de informatie die nodig is om de Taak te begrijpen: een bestandsverwijzing, een opgeschoond logboek met fouten, een schermafbeelding of een document met vereisten. Gebruik @ gevolgd door een bestandspad om de content van dat bestand op te nemen.

Kies de kleinste bruikbare set bronnen. Het opnemen van een volledig logbestand of een volledige map kan irrelevante informatie toevoegen en context verspillen. Verwijder inloggegevens en gevoelige gegevens voordat je logbestanden deelt, en controleer of Claude over de benodigde tools beschikt om de door jou opgegeven documentatie-URL’s op te halen.

Bijvoorbeeld: fout in het logbestand.log | claude -p "Explain this fout" verstuurt een logbestand via een niet-interactief verzoek. Gebruik dit alleen nadat je de content van het bestand hebt gecontroleerd. Dit is de praktische waarde van contextuele AI: het model relevante informatie voor de Taak verstrekken.

Zoek bij het toevoegen van een functie een vergelijkbare component of functie in de opslagplaats. Geef aan Claude door welke conventies hij moet volgen, zoals de API-client, validatielogica, foutafhandeling of teststructuur.

“Volg hoe @src/widgets/Weather.tsx gegevens ophaalt en in de cache opslaat” geeft Claude een concreet referentiepunt. Noem ook eventuele verschillen die de nieuwe functie vereist, zodat er geen gedrag wordt gekopieerd dat niet langer past. Deze conventies moeten aansluiten bij de softwareontwikkelingswerkstroom van je team.

Geef bij code-wijzigingen het relevante test-, build- of lint-commando op, evenals het gedrag dat moet worden gecontroleerd. Vraag voor onderzoek naar bestandsreferenties of commit-ID’s. Geef bij UI-werk een referentieafbeelding en een geconfigureerde manier om de implementatie binnen dezelfde viewport vast te leggen.

Vraag Claude om een rapportage te leveren over wat er daadwerkelijk is gecontroleerd, inclusief fouten en overgeslagen controles. Controleer of het bewijsmateriaal voldoet aan de vereisten; een geslaagde build betekent niet automatisch dat elk gewenst gedrag werkt.

Voor langere taken biedt Claude Code ook een /doel-voorwaarde en Stop-hooks. De doelbeoordelaar evalueert bewijsmateriaal dat tijdens het gesprek naar voren komt, in plaats van zelfstandig bestanden te inspecteren of tests uit te voeren. Een geconfigureerde Stop-hook kan de voltooiing blokkeren, maar er gelden limieten voor herhaaldelijk blokkeren. Geen van beide vervangt passende tests en menselijke beoordeling.

Als herhaalde correcties een probleem niet oplossen, stop dan even en breng in kaart wat er in de oorspronkelijke aanvraag onduidelijk was. Sla de nuttige bevindingen, de huidige Git-status en het resterende werk op voordat je het gesprek afsluit.

De gids met best practices van Anthropic raadt aan om opnieuw te beginnen na twee mislukte correcties op hetzelfde probleem. Gebruik /clear en geef vervolgens een aangepaste prompt waarin je de geleerde lessen verwerkt. Het wissen van het gesprek maakt wijzigingen in bestanden niet ongedaan.

Druk op Esc om een lopende respons te onderbreken. Als het invoerveld leeg is, druk je twee keer op Esc om het terugspoelmenu te openen en te kiezen wat je wilt herstellen. Terugspoelen maakt niet alle externe effecten ongedaan, dus gebruik Git-checkpoints en aparte herstelprocedures voor wijzigingen in databases of externe diensten.

Sla projectbrede richtlijnen op in CLAUDE.md, herhaalbare procedures in skills en instructies voor specifieke bestanden in regels die gelden voor een bepaald pad. Gebruik hooks voor acties die aan specifieke gebeurtenissen zijn gekoppeld, zoals het uitvoeren van een formatter na een bewerking.

Maak een keuze op basis van het moment waarop de instructie van toepassing moet zijn:

Een vereiste voor een bepaalde functie hoort meestal thuis in de bijbehorende taakopdracht of specificatie, en niet in CLAUDE.md. Door tijdelijke instructies toe te voegen aan een projectbestand, worden ze moeilijker te onderscheiden van conventies die in de hele opslagplaats van toepassing zouden moeten zijn.

Zet bijvoorbeeld het testcommando van het project in CLAUDE.md, plaats component-specifieke conventies in een regel met een pad-scope en sla een terugkerende beoordelingsprocedure op als een skill. Bekijk deze bestanden wanneer commando’s of conventies veranderen, net zoals je dat bij andere projectdocumentatie zou doen.

Prompts, CLAUDE.md en vaardigheden sturen het gedrag van Claude aan; ze garanderen niet dat een instructie wordt opgevolgd. Hooks kunnen controles uitvoeren bij geconfigureerde gebeurtenissen, maar de betrouwbaarheid ervan hangt af van het type hook en de implementatie.

Een command hook voert een script uit. Een prompt- of agent-hook is afhankelijk van het oordeel van een model. Zoals in de gids met best practices van Anthropic wordt uitgelegd: “Een prompt- of agent-hook vraagt een ander model om een beslissing te nemen, dus ook deze is niet deterministisch.” Gebruik voor een regel die moet worden afgedwongen de juiste toestemming en test de betreffende command- of HTTP-hook, inclusief hoe deze omgaat met fouten.

Aangepaste subagenten zijn een andere manier om terugkerende taken te organiseren. Definieer een specialist in `claude/agents/` wanneer er een aparte rol of toolscope nodig is, in plaats van elke specialistische instructie aan de hoofdsessie toe te voegen. Deze handleidingen over het beste Claude-model voor werk en soorten AI-agenten bieden aanvullende context.

Als je team prompts voor verschillende AI-producten beheert, bekijk dan deze tools voor prompt-engineering om bibliotheken buiten Claude Code te beheren.

Wanneer een sessie een onvolledig of ongeschikt resultaat oplevert, controleer dan of er in de opdracht belangrijke beslissingen onopgelost zijn gebleven. Deze vijf fouten kunnen het diagnosticeren en beoordelen van het werk bemoeilijken.

„Onderzoek de opslagplaats“ geeft Claude weinig aanwijzingen over welke bestanden van belang zijn of wanneer hij moet stoppen. Mogelijk ontvangt u een algemene samenvatting zonder antwoord op het probleem dat aanleiding gaf tot het verzoek.

Geef een naam aan het gedrag of de beslissing die je moet begrijpen, bepaal een locatie en definieer de verwachte uitvoer. Bijvoorbeeld: „Traceer hoe dit eindpunt toestemming controleert en noem de relevante functies.” Als je subagenten gebruikt, geef elke subagent dan een afgebakende vraag in plaats van dezelfde onbeperkte zoekopdracht te delegeren.

Als je schakelt tussen een functie, een niet-gerelateerde bug en een verzoek om documentatie, blijft er context in het gesprek hangen die mogelijk niet van toepassing is op de huidige Taak. Verwijzingen zoals ‘dat bestand’ of ‘de eerdere aanpak’ worden dan dubbelzinnig.

Gebruik aparte sessies voor werk dat geen verband houdt met elkaar. Als er vanuit meerdere sessies bewerkingen in de opslagplaats worden uitgevoerd, gebruik dan aparte Git-werkbomen, zodat ze niet dezelfde werkdirectory wijzigen. Even terzijde: met het /btw-commando van Claude Code wordt de uitwisseling buiten de hoofdgeschiedenis van het gesprek gehouden.

Een build kan slagen terwijl een functie zich onjuist gedraagt. Een testsuite kan slagen omdat de foutieve invoer nooit is getest. Als je Claude vraagt om “de tests uit te voeren”, wordt daarmee niet vastgesteld welke vereiste die tests verifiëren.

Breng de acceptatiecriteria in kaart met specifieke controles. Vraag bij het verhelpen van een bug om bewijs dat de reproductietest vóór de wijziging mislukte en erna slaagde. Houd niet-geteste criteria zichtbaar in plaats van één geslaagd commando te beschouwen als verificatie van de gehele wijziging.

Een steeds groter wordend CLAUDE.md-bestand kan verouderde commando’s, dubbele regels en instructies bevatten die in strijd zijn met taakspecifieke vereisten. Het toevoegen van strengere bewoordingen lost deze conflicten niet op.

Vergelijk het bestand met de huidige opslagplaats. Verwijder verouderde richtlijnen, verduidelijk tegenstrijdige regels en verplaats instructies met een beperkte toepasbaarheid naar regels of vaardigheden die binnen een bepaald pad gelden. Als een vereiste moet worden afgedwongen, configureer en test dan de juiste controles in plaats van te vertrouwen op herhaalde herinneringen.

Een beoordeling kan zowel echte fouten, onduidelijke punten van zorg als optionele suggesties voor refactoring aan het licht brengen. Het toepassen van elke suggestie kan de omvang van de wijziging vergroten zonder dat het gewenste gedrag daardoor wordt verbeterd.

Vraag naar het bewijs en de impact achter elke bevinding. Geef prioriteit aan problemen en niet-voldane vereisten, onderzoek onduidelijke beweringen en houd niet-gerelateerde verbeteringen buiten de huidige diff. Een reviewer moet in staat zijn om te melden dat er geen actiegerichte bevindingen zijn wanneer het bewijs die conclusie ondersteunt.

Om een sjabloon aan te passen, vervang je de plaatshouders door gegevens uit je project en bepaal je wat Claude moet doen voordat je wijzigingen aanbrengt. Volg deze stappen om het verzoek voor te bereiden en het resultaat te beoordelen.

Voor een kleine, duidelijk omschreven wijziging kun je Claude vragen deze direct door te voeren. Bij onbekende code, wijzigingen in meerdere bestanden of onduidelijke vereisten: begin met een plan.

Druk op Shift+Tab totdat de Plan-modus verschijnt, of start Claude Code met claude --permission-mode plan. In deze modus kan Claude bestanden inspecteren en alleen-lezen commando's uitvoeren zonder je broncode te bewerken. Bekijk de voorgestelde bestanden, afhankelijkheden en tests voordat je de implementatie goedkeurt. Druk op Ctrl+G om het voorgestelde plan in je editor te openen.

Geef Claude de informatie die nodig is om de Taak te begrijpen: een bestandsverwijzing, een opgeschoond logboek met fouten, een schermafbeelding of een document met vereisten. Gebruik @ gevolgd door een bestandspad om de content van dat bestand op te nemen.

Kies de kleinste bruikbare set bronnen. Het opnemen van een volledig logbestand of een volledige map kan irrelevante informatie toevoegen en context verspillen. Verwijder inloggegevens en gevoelige gegevens voordat u logbestanden deelt, en controleer of Claude over de benodigde tools beschikt om de door u opgegeven URL’s naar documentatie op te halen.

Als voorbeeld: `cat fout.log | claude -p "Explain deze fout"` verstuurt een logbestand via een niet-interactief verzoek. Gebruik dit alleen nadat je de inhoud van het bestand hebt gecontroleerd. Dit is de praktische waarde van contextuele AI: het model relevante informatie voor de Taak verstrekken.

Zoek bij het toevoegen van een functie een vergelijkbare component of functie in de opslagplaats. Geef aan Claude door welke conventies hij moet volgen, zoals de API-client, validatielogica, foutafhandeling of teststructuur.

“Volg hoe @src/widgets/Weather.tsx gegevens ophaalt en in de cache opslaat” geeft Claude een concreet referentiepunt. Noem ook eventuele verschillen die de nieuwe functie vereist, zodat er geen gedrag wordt gekopieerd dat niet langer past. Deze conventies moeten aansluiten bij de softwareontwikkelingswerkstroom van je team.

Geef bij codewijzigingen het relevante test-, build- of lint-commando op, evenals het gedrag dat moet worden gecontroleerd. Vraag voor onderzoek naar bestandsreferenties of commit-ID’s. Geef bij UI-werk een referentieafbeelding en een geconfigureerde manier om de implementatie binnen dezelfde viewport vast te leggen.

Vraag Claude om de rapportage te doen over wat er daadwerkelijk is gecontroleerd, inclusief fouten en overgeslagen controles. Controleer of de bevindingen voldoen aan de vereisten; een geslaagde build betekent niet automatisch dat elk gewenst gedrag werkt.

Voor langere taken biedt Claude Code ook een /goal-voorwaarde en Stop-hooks. De goal-evaluator beoordeelt bewijsmateriaal dat tijdens het gesprek naar voren komt, in plaats van zelfstandig bestanden te inspecteren of tests uit te voeren. Een geconfigureerde Stop-hook kan de voltooiing blokkeren, maar er gelden limieten voor herhaaldelijk blokkeren. Geen van beide vervangt passende tests en menselijke beoordeling.

Als herhaalde correcties een probleem niet oplossen, stop dan even en breng in kaart wat er in de oorspronkelijke aanvraag onduidelijk was. Sla de nuttige bevindingen, de huidige Git-status en het resterende werk op voordat je het gesprek wist.

De gids met best practices van Anthropic raadt aan om opnieuw te beginnen na twee mislukte correcties op hetzelfde probleem. Gebruik /clear en geef vervolgens een aangepaste prompt waarin je de geleerde lessen verwerkt. Het wissen van het gesprek maakt wijzigingen in bestanden niet ongedaan.

Druk op Esc om een lopende respons te onderbreken. Als het invoerveld leeg is, druk je twee keer op Esc om het terugspoelmenu te openen en te kiezen wat je wilt herstellen. Terugspoelen maakt niet alle externe effecten ongedaan, dus gebruik Git-checkpoints en afzonderlijke herstelprocedures voor wijzigingen in databases of externe diensten.

Sla projectbrede richtlijnen op in CLAUDE.md, herhaalbare procedures in skills en instructies voor specifieke bestanden in regels die gelden voor een bepaald pad. Gebruik hooks voor acties die aan specifieke gebeurtenissen zijn gekoppeld, zoals het uitvoeren van een formatter na een bewerking.

Maak een keuze op basis van het moment waarop de instructie van toepassing moet zijn:

Een vereiste voor een bepaalde functie hoort meestal thuis in de bijbehorende taakopdracht of specificatie, en niet in CLAUDE.md. Door tijdelijke instructies toe te voegen aan een projectbestand, worden ze moeilijker te onderscheiden van conventies die in de hele opslagplaats van toepassing zouden moeten zijn.

Zet bijvoorbeeld het testcommando van het project in CLAUDE.md, plaats component-specifieke conventies in een regel met een pad-scope en sla een terugkerende beoordelingsprocedure op als een skill. Controleer deze bestanden wanneer commando’s of conventies veranderen, net zoals je dat bij andere projectdocumentatie zou doen.

Prompts, CLAUDE.md en vaardigheden sturen het gedrag van Claude aan; ze garanderen niet dat een instructie wordt opgevolgd. Hooks kunnen controles uitvoeren bij geconfigureerde gebeurtenissen, maar de betrouwbaarheid ervan hangt af van het type hook en de implementatie.

Een command hook voert een script uit. Een prompt- of agent-hook is afhankelijk van het oordeel van een model. Zoals in de gids met best practices van Anthropic wordt uitgelegd: “Een prompt- of agent-hook vraagt een ander model om een beslissing te nemen, dus ook deze is niet deterministisch.” Gebruik voor een regel die moet worden afgedwongen de juiste toestemming en test de betreffende command- of HTTP-hook, inclusief hoe deze omgaat met fouten.

Aangepaste subagenten zijn een andere manier om terugkerende taken te organiseren. Definieer een specialist in `claude/agents/` wanneer er een aparte beoordelingsrol of toolscope nodig is, in plaats van elke specialistische instructie aan de hoofdsessie toe te voegen. Deze handleidingen over het beste Claude-model voor werk en soorten AI-agenten bieden aanvullende context.

Als je team prompts voor verschillende AI-producten beheert, bekijk dan deze tools voor prompt-engineering om bibliotheken buiten Claude Code te beheren.

Wanneer een sessie een onvolledig of ongeschikt resultaat oplevert, controleer dan of er in de opdracht belangrijke beslissingen onopgelost zijn gebleven. Deze vijf fouten kunnen het diagnosticeren en beoordelen van het werk bemoeilijken.

„Onderzoek de opslagplaats“ geeft Claude weinig aanwijzingen over welke bestanden van belang zijn of wanneer hij moet stoppen. Mogelijk ontvangt u een algemene samenvatting zonder antwoord op het probleem dat aanleiding gaf tot het verzoek.

Geef een naam aan het gedrag of de beslissing die je moet begrijpen, bepaal een locatie en definieer de verwachte uitvoer. Bijvoorbeeld: „Traceer hoe dit eindpunt toestemming controleert en noem de relevante functies.” Als je subagenten gebruikt, geef elke subagent dan een afgebakende vraag in plaats van dezelfde onbeperkte zoekopdracht te delegeren.

Als je schakelt tussen een functie, een niet-gerelateerde bug en een verzoek om documentatie, blijft er context in het gesprek hangen die mogelijk niet van toepassing is op de huidige Taak. Verwijzingen zoals ‘dat bestand’ of ‘de eerdere aanpak’ worden dan dubbelzinnig.

Gebruik aparte sessies voor werk dat geen verband houdt met elkaar. Als er vanuit meerdere sessies bewerkingen in de opslagplaats worden uitgevoerd, gebruik dan aparte Git-werkbomen, zodat ze niet dezelfde werkdirectory wijzigen. Even terzijde: met het /btw-commando van Claude Code wordt de uitwisseling buiten de hoofdgeschiedenis van het gesprek gehouden.

Een build kan slagen terwijl een functie zich onjuist gedraagt. Een testsuite kan slagen omdat de foutieve invoer nooit is getest. Als je Claude vraagt om “de tests uit te voeren”, wordt daarmee niet vastgesteld welke vereiste die tests verifiëren.

Breng de acceptatiecriteria in kaart met specifieke controles. Vraag bij het verhelpen van een bug om bewijs dat de reproductietest vóór de wijziging mislukte en erna slaagde. Houd ongeteste criteria zichtbaar in plaats van één geslaagd commando te beschouwen als verificatie van de gehele wijziging.

Een steeds groter wordend CLAUDE.md-bestand kan verouderde commando’s, dubbele regels en instructies bevatten die in strijd zijn met taakspecifieke vereisten. Het toevoegen van strengere bewoordingen lost deze conflicten niet op.

Vergelijk het bestand met de huidige opslagplaats. Verwijder verouderde richtlijnen, verduidelijk tegenstrijdige regels en verplaats instructies met een beperkte toepasbaarheid naar regels of vaardigheden die binnen een bepaald pad gelden. Als een vereiste moet worden afgedwongen, configureer en test dan de juiste controles in plaats van te vertrouwen op herhaalde herinneringen.

Een beoordeling kan zowel echte fouten, onduidelijke punten van zorg als optionele suggesties voor refactoring aan het licht brengen. Het toepassen van elke suggestie kan de omvang van de wijziging vergroten zonder dat het gewenste gedrag daardoor wordt verbeterd.

Vraag naar het bewijs en de impact achter elke bevinding. Geef prioriteit aan problemen en niet-voldane vereisten, onderzoek onduidelijke beweringen en houd niet-gerelateerde verbeteringen buiten de huidige diff. Een reviewer moet in staat zijn om te melden dat er geen actiegerichte bevindingen zijn wanneer het bewijs die conclusie ondersteunt.