Claude-Code-Prompts: 25 kopierfertige Prompts und wie Sie Ihre eigenen erstellen

Kunden, die einen abgelaufenen Gutschein verwenden, erhalten beim Bezahlvorgang einen 500-Fehler. Überprüfen Sie die Datei @src/checkout/coupons.ts und die dazugehörigen Tests. Das erwartete Verhalten ist eine Meldung über einen ungültigen Gutschein, ohne dass eine Bestellung erstellt wird. Schreiben Sie einen fehlgeschlagenen Test, der den Fehler reproduziert, und beheben Sie ihn anschließend, ohne das Verhalten bei gültigen Gutscheinen zu ändern. Führen Sie den Befehl [checkout test] aus und zeigen Sie die Ergebnisse vor und nach der Änderung. Wenn Sie den Fehler nicht reproduzieren können, berichten Sie, was Sie vor der Änderung der Implementierung überprüft haben.

Fügen Sie eine Datumsauswahl zu [Pfad zum Buchungsformular] hinzu. Halten Sie sich dabei an die Komponenten- und Validierungskonventionen in @src/components/TimeSelect.tsx. Benutzer müssen [zulässige Daten] auswählen können, während [nicht verfügbare Daten] deaktiviert bleiben. Fügen Sie keine Bibliotheken hinzu. Führen Sie den [Befehl zum Testen der Komponente] und den [Befehl zur Typprüfung] aus und melden Sie alle Kriterien, die diese Prüfungen nicht abdecken.

Teilen Sie die Datei @src/reports/export.py in kleinere Funktionen auf, wobei Sie die Eingaben, das Format der Ausgabe und das Fehlerverhalten beibehalten. Führen Sie vor der Bearbeitung den Befehl [export test] aus und melden Sie alle vorhandenen Fehler. Führen Sie nach der Umgestaltung die Tests erneut aus und zeigen Sie beide Ergebnisse an. Ändern Sie weder die öffentliche Schnittstelle noch nicht relevante Dateien.

„Claude testet jede einzelne Änderung, die ich mithilfe der Claude-Chrome-Erweiterung auf claude.ai/code einstelle. Dabei wird ein Browser geöffnet, die Benutzeroberfläche getestet und der Vorgang so lange wiederholt, bis der Code funktioniert und die Benutzererfahrung stimmt. “

Sehen Sie sich die README-Datei, die Projektkonfiguration und die Verzeichnisstruktur auf oberster Ebene dieses Repositorys an. Folgen Sie den Verweisen nur soweit nötig, um Folgendes zu erläutern: Was die Anwendung tut, ihre Haupteinstiegspunkte und wichtigsten Komponenten, wo sich die Tests befinden und welche Befehle das Repository zu deren Ausführung definiert. Geben Sie die Dateipfade an, die Ihre Erläuterungen unterstützen. Unterscheiden Sie zwischen dokumentiertem Verhalten und Ihren eigenen Schlussfolgerungen und kennzeichnen Sie alles, was Sie nicht feststellen können. Lesen Sie keine Geheimdaten oder Umgebungsdateien aus, überprüfen Sie keine installierten Abhängigkeiten und ändern Sie keine Dateien. Schließen Sie mit den drei Dateien, die ich als Erstes lesen sollte, und begründen Sie, warum.

Überprüfen Sie den Git-Verlauf von [Datei, Funktion oder Klasse] und konzentrieren Sie sich dabei auf [Verhalten oder Designfrage]. Identifizieren Sie die Commits, durch die dieses Verhalten eingeführt oder wesentlich verändert wurde. Geben Sie für jeden relevanten Commit dessen Hash an, fassen Sie die Änderung zusammen und erläutern Sie etwaige Begründungen, die in der Commit-Meldung oder einer verknüpften Diskussion dokumentiert sind, auf die Sie Zugriff haben. Kennzeichnen Sie abgeleitete Gründe als „Schlussfolgerungen“. Wenn der Verlauf eine Entscheidung nicht erklärt, weisen Sie darauf hin. Ändern Sie keine Dateien oder den Git-Verlauf.

Verfolgen Sie, was bei [Benutzeraktion oder Systemereignis] geschieht, beginnend bei [bekannter Route, Handler oder Ordner]. Verfolgen Sie die relevanten Aufrufe durch die Validierung, die Geschäftslogik sowie etwaige Datenbank-Schreibvorgänge oder externe Anfragen. Listen Sie die Dateien und Funktionen in der Ausführungsreihenfolge auf, gegebenenfalls mit Zeilenverweisen. Erläutern Sie die wichtigsten Fehlerpfade und identifizieren Sie vorhandene Tests, die den Flow abdecken. Markieren Sie alle Verbindungen, die Sie anhand des Codes nicht bestätigen können. Führen Sie den Flow nicht aus, rufen Sie keine externen Dienste auf und führen Sie keine Bearbeitung der Dateien durch.

Planen Sie, wie [Feature] im [Repository-Bereich] implementiert werden soll. Das erwartete Verhalten ist [Anforderungen], und diese Bereiche müssen unverändert bleiben: [Einschränkungen]. Prüfen Sie den relevanten Code und die vorhandenen Tests. Identifizieren Sie die Dateien, die geändert werden müssen, die Reihenfolge der Implementierung sowie etwaige Kompatibilitäts- oder Datenmigrationsrisiken. Ordnen Sie jede Anforderung einem vorgeschlagenen Test oder einem anderen Schritt der Überprüfung zu. Führen Sie eine Liste mit offenen Fragen und Annahmen auf. Implementieren Sie das Feature noch nicht. Legen Sie den Plan mir zur Überprüfung vor.

Ich möchte [kurze Beschreibung] für [Benutzer und Anwendungsfall] erstellen. Lies zunächst [relevante Dateien oder Anforderungen] und nutze dann „AskUserQuestion“, um Entscheidungen zu klären, die wesentliche Auswirkungen auf die Umsetzung haben würden. Konzentriere dich auf Randfälle, den Umgang mit Daten, Berechtigungen, das erwartete Verhalten der Benutzeroberfläche und Abwägungen. Stelle keine Fragen, die der bereitgestellte Kontext bereits beantwortet. Sobald die Schlüsselentscheidungen getroffen sind, erstelle einen Spezifikationsentwurf, der Anforderungen, Abnahmekriterien, Einschränkungen und den Umfang der Arbeit abdeckt. Markiere alle verbleibenden Annahmen. Zeige mir die Spezifikation, bevor du sie unter [Spezifikationspfad] speicherst, und überschreibe keine vorhandene Datei ohne Genehmigung.

Bewerten Sie die Auswirkungen einer Änderung von [Funktion, Komponente oder Schnittstelle] vom [aktuellen Verhalten] zum [vorgeschlagenen Verhalten]. Durchsuchen Sie [Repositorys oder Verzeichnisbereiche] nach deren Definition, direkten Aufrufern, Importen und zugehörigen Tests. Erstellen Sie eine Liste der Dateien, die wahrscheinlich geändert werden müssen, und erläutern Sie, wie jede davon betroffen sein könnte, gegebenenfalls mit Datei- und Zeilenverweisen. Markieren Sie dynamisch aufgelöste Aufrufe, externe Verbraucher oder andere Abhängigkeiten, die Sie nicht überprüfen können. Identifizieren Sie alle Kompatibilitätsfragen, die vor der Implementierung geklärt werden müssen. Nehmen Sie keine Änderungen an Dateien vor; reichen Sie die Auswirkungsanalyse ein und warten Sie auf meine Überprüfung.

Füge [Feature] zu [Datei oder Seite] mit folgendem Verhalten hinzu: [Akzeptanzkriterien]. Überprüfe die [bestehende Implementierung] und halte dich an deren Konventionen für das Abrufen von Daten, die Fehlerbehandlung und die Organisation von Komponenten. Verwende ausschließlich Bibliotheken, die bereits im Projekt installiert sind. Halten Sie Änderungen innerhalb des [Umfangs] und bewahren Sie das [bestehende Verhalten oder die öffentliche Schnittstelle] bei. Fügen Sie Tests für die Akzeptanzkriterien hinzu oder aktualisieren Sie diese. Führen Sie den [Testbefehl] und den [Typüberprüfungs- oder Lint-Befehl] aus und melden Sie anschließend die geänderten Dateien, die Ergebnisse sowie alle Prüfungen, die Sie nicht abschließen konnten. Falls das bestehende Muster im Widerspruch zu einer Anforderung steht, erläutern Sie den Konflikt, bevor Sie fortfahren.

Implementieren Sie [Funktionsname] in [Datei], um [Anforderungen] zu erfüllen. Berücksichtigen Sie dabei den [Normalfall], den [Randfall] und das [Verhalten bei ungültiger Eingabe]. Führen Sie zunächst den [entsprechenden Testbefehl] aus und melden Sie etwaige Fehler. Schreiben Sie Tests für das gewünschte Verhalten und führen Sie diese vor der Implementierung aus. Vergewissern Sie sich, dass die neuen Tests aus dem erwarteten Grund fehlschlagen. Implementieren Sie die Funktion und führen Sie die Tests erneut aus. Schwächen Sie keine Assertions ab, überspringen Sie keine Tests und ändern Sie nicht das erwartete Verhalten, nur damit die Tests bestehen. Wenn die Anforderungen im Widerspruch zu bestehenden Tests stehen, halten Sie inne und erläutern Sie den Konflikt. Zeigen Sie die Ergebnisse vor und nach der Änderung auf.

Implementieren Sie den Anhang in [Komponente oder Seite] unter Verwendung der vorhandenen Komponenten und Stile des Projekts. Behalten Sie [erforderliches Verhalten] bei und vermeiden Sie Änderungen außerhalb des [Umfangs]. Verwenden Sie [konfigurierten Browser oder Screenshot-Tool], um [lokale Route] bei [Viewport-Abmessungen] mit [Testdaten und UI-Zustand] zu erfassen. Falls das Tool oder die Anwendung nicht verfügbar ist, berichten Sie, was benötigt wird, anstatt eine visuelle Überprüfung zu behaupten. Vergleichen Sie die Aufnahme mit der Referenz und konzentrieren Sie sich dabei auf [Layout, Abstände, Typografie oder andere Abnahmekriterien]. Führen Sie bis zu [Anzahl] Korrekturdurchläufe durch und melden Sie anschließend die verbleibenden Unterschiede. Ändern Sie das Referenzbild nicht. Führen Sie [relevante Komponententests] sowie den [Typ-Check oder Build-Befehl] aus. Fügen Sie den aufgenommenen Screenshot und das tatsächliche Prüfergebnis Ihrer Zusammenfassung bei.

Benutzer stoßen auf [Symptom], wenn [Auslöser oder Eingabe]. Das erwartete Verhalten ist [erwartetes Ergebnis]. Beginnen Sie mit der Überprüfung von [Ordner, Funktion oder Flow] und den zugehörigen Tests. Erstellen Sie einen fehlgeschlagenen Test, der das gemeldete Verhalten reproduziert. Wenn Sie es nicht reproduzieren können, erläutern Sie, was Sie überprüft haben und welche Informationen fehlen, bevor Sie die Implementierung ändern. Sobald das Verhalten reproduziert wurde, beheben Sie die Ursache, ohne [Verhalten, das unverändert bleiben muss] zu ändern. Führen Sie den neuen Test und [den zugehörigen Befehl] aus. Zeigen Sie den Fehler vor der Behebung, die Ergebnisse danach sowie etwaige verbleibende Fehler an.

Der [Build-Befehl] schlägt in der [lokalen oder CI-Umgebung] mit folgender Ausgabe fehl: [bereinigtes Fehlerprotokoll]. Überprüfen Sie den entsprechenden Code und die Konfiguration, um die Ursache zu ermitteln. Prüfen Sie auf Unterschiede in der Umgebung oder bei den Abhängigkeiten, falls sich der Fehler lokal nicht reproduzieren lässt. Nehmen Sie die kleinste Änderung vor, die die Ursache behebt. Deaktivieren Sie keine Prüfungen, unterdrücken Sie keine Fehler, überspringen Sie keine Tests und lockern Sie keine Compiler-Einstellungen, nur um einen erfolgreichen Build zu erhalten. Führen Sie den Build nach der Änderung erneut aus. Wenn er nach [Anzahl] Korrekturversuchen immer noch fehlschlägt, halten Sie inne und melden Sie, was Sie versucht haben, den aktuellen Fehler und den nächsten Diagnoseschritt. Fassen Sie die Ursache zusammen und fügen Sie das tatsächliche Ergebnis des Builds bei.

Hilf mir, einen Fehler einzugrenzen, bevor du eine Lösung vorschlägst. Beobachtetes Verhalten: [was passiert] Erwartetes Verhalten: [was passieren sollte] Wann es auftritt: [Bedingungen oder Häufigkeit] Was ich bereits versucht habe: [Schritte und Ergebnisse] Stelle jeweils nur eine Frage und wähle dabei die Frage aus, mit der sich die wahrscheinlichen Ursachen am besten unterscheiden lassen. Wiederhole keine Fragen, die durch die bereitgestellten Informationen bereits beantwortet sind. Sobald genügend Anhaltspunkte vorliegen, fasse die wahrscheinlichste Erklärung zusammen, was noch unklar ist und welchen kleinsten Test man durchführen könnte, um diese zu bestätigen oder auszuschließen. Führe noch keine Bearbeitung der Dateien durch.

Verwenden Sie einen Unteragenten, um [Diff oder Bereich im Vergleich zur Basis] anhand des [genehmigten Plans oder der Anforderungsdatei] zu überprüfen. Falls Anforderungen fehlen oder mehrdeutig sind, melden Sie dies, bevor Sie die Vollständigkeit bewerten. Prüfen Sie, ob jede Anforderung implementiert ist, relevante Randfälle getestet wurden und ob Änderungen außerhalb des vereinbarten Umfangs liegen. Untersuchen Sie bei Bedarf den umgebenden Code, um den Diff zu verstehen. Melden Sie Korrektheitsprobleme und nicht erfüllte Anforderungen mit Datei- und Zeilenverweisen, deren Auswirkungen und den Belegen, die jeden Befund unterstützen. Trennen Sie bestätigte Probleme von ungelösten Fragen. Erfinden Sie keine Befunde, um eine Quote zu erfüllen, und fügen Sie keine irrelevanten Stilvorlieben hinzu. Führen Sie keine Bearbeitung der Dateien durch.

Überprüfen Sie [Dateien oder Diff-Dateien] auf Injektionsrisiken, fehlende Autorisierungsprüfungen, offengelegte Geheimnisse und unsicheren Umgang mit Benutzereingaben. Überprüfen Sie die relevanten Aufrufer und die Validierungslogik, bevor Sie einen Bericht über ein Problem erstellen. Identifizieren Sie für jedes Problem die betroffene Datei und die betroffenen Zeilen, die Auslöser, die wahrscheinlichen Auswirkungen sowie einen Lösungsvorschlag. Unterscheiden Sie einen bestätigten anfälligen Pfad von einem Verdachtsfall, der weiterer Tests bedarf. Geben Sie geheime Werte im Bericht nicht wieder, ändern Sie keine Dateien und führen Sie keine Tests an Live-Diensten durch. Geben Sie an, welche Bereiche Sie überprüft haben und was außerhalb des Untersuchungsumfangs liegt.

Fassen Sie zusammen, wie Sie die fertiggestellte Änderung anhand der [Abnahmekriterien] überprüft haben. Führen Sie für jedes Kriterium die durchgeführte Prüfung, gegebenenfalls den genauen Befehl und das beobachtete Ergebnis auf. Fügen Sie relevante Ausgaben bei, wobei Geheimnisse und sensible Daten unkenntlich gemacht werden müssen. Weisen Sie bereits bestehende Fehler separat aus. Unterscheiden Sie klar zwischen Prüfungen, die bestanden wurden, solchen, die fehlgeschlagen sind, und solchen, die nicht ausgeführt wurden. Erläutern Sie alle übersprungenen Prüfungen oder Limite im Abdeckungsgrad. Beschreiben Sie die gesamte Änderung nicht als verifiziert, wenn einige Kriterien noch nicht überprüft wurden.

Refactorn Sie [Datei oder Modul] mit dem Ziel [spezifisches Ziel, z. B. das Aufteilen einer großen Funktion oder das Entfernen verschachtelter Callbacks]. Behalten Sie dabei die öffentliche Schnittstelle, die Rückgabewerte, das Verhalten bei Fehlern und die Nebenwirkungen bei. Führen Sie vor der Bearbeitung den [entsprechenden Testbefehl] aus, um eine Ausgangsbasis zu schaffen. Sollte der Test fehlschlagen, dokumentieren Sie die Fehler, bevor Sie fortfahren. Identifizieren Sie jegliches Verhalten, das von den bestehenden Tests nicht abgedeckt wird, und fügen Sie bei Bedarf gezielte Tests hinzu. Führen Sie das Refactoring ohne irrelevante Änderungen oder neue Abhängigkeiten durch. Schwächen Sie bestehende Assertions nicht ab, um der Implementierung Rechnung zu tragen. Führen Sie die Tests und [Typüberprüfung oder Lint-Befehl] erneut aus. Zeigen Sie die Ergebnisse vor und nach der Änderung, fassen Sie die strukturellen Änderungen zusammen und kennzeichnen Sie jegliches Verhalten, das Sie nicht überprüfen konnten.

Suchen Sie nach Verwendungen von [alter API oder Bibliothek] innerhalb des [Verzeichnisbereichs], wobei generierte und Vendor-Dateien ausgeschlossen werden. Erstellen Sie eine Liste der betroffenen Dateien sowie aller gemeinsam genutzten Konfigurationen oder Abhängigkeiten, die von der Migration betroffen sein könnten. Schlagen Sie drei repräsentative Dateien für eine Pilotmigration auf die [neue API oder Version] vor, wobei Sie den [Migrationsleitfaden oder ein vorhandenes Beispiel] verwenden. Erläutern Sie, warum Sie diese ausgewählt haben, und kennzeichnen Sie alle erforderlichen Verhaltensänderungen. Warten Sie vor der Bearbeitung auf meine Genehmigung. Migrieren Sie nach der Genehmigung nur die Pilotdateien und alle ausdrücklich genehmigten gemeinsam genutzten Abhängigkeiten. Führen Sie [relevante Tests] und den [Build- oder TypüberprüfungsBefehl] aus. Weiten Sie die Migration nicht auf andere Dateien aus. Berichten Sie über die Unterschiede, Testergebnisse, Kompatibilitätsprobleme und alle erforderlichen Änderungen am Migrationsansatz. Halten Sie zur Überprüfung inne, bevor Sie mit den verbleibenden Dateien fortfahren.

Überprüfe den aktuellen Bereich, den Git-Status und den Diff für [Feature oder Fix]. Identifiziere die zu dieser Änderung gehörenden Dateien und erstelle eine Liste nicht relevanter oder nicht verfolgter Dateien. Verfasse einen Commit-Text, der dem Format der letzten 10 Commits folgt. Erstelle eine Pull Request-Beschreibung, die die Änderungen, deren Gründe, die tatsächlich ausgeführten Tests sowie etwaige verbleibende Limite enthält. Zeige die vorgeschlagene Dateiliste, die Commit-Meldung und die PR-Beschreibung, bevor du irgendetwas stagest oder veröffentlichst. Warte auf meine Freigabe. Nach der Freigabe stagest du nur die vereinbarten Dateien, committest auf dem [Feature-Zweig], pushst auf [Remote] und eröffnest einen Pull Request für den [Basis-Zweig]. Ändere keine bestehenden Commits, führe keinen Force-Push durch und führe keine Zusammenführungen durch. Sende den Commit-Hash und den PR-Link zurück.

Entwerfen Sie einen README-Abschnitt für [Modul], der sich an [Leser, z. B. einen Backend-Entwickler, der neu zum Projekt hinzukommt] richtet. Behandeln Sie dabei die Voraussetzungen, das Setup, die drei Befehle, die am häufigsten verwendet werden, sowie häufige Fehler, die im Code oder in der vorhandenen Dokumentation unterstützt werden. Überprüfen Sie Befehlsnamen und Optionen anhand von [Paketskripten, Makefile, CLI-Hilfe oder CI-Konfiguration]. Markieren Sie alles, was Sie nicht bestätigen können. Testen Sie sichere lokale Befehle in der [Testumgebung], sofern verfügbar. Bevor Sie Befehle ausführen, die Abhängigkeiten installieren, Dateien löschen, Daten migrieren, Deploys durchführen oder auf externe Dienste zugreifen, erklären Sie deren Auswirkungen und bitten Sie um Zustimmung. Unterscheiden Sie klar zwischen Befehlen, die Sie erfolgreich ausgeführt haben, und solchen, die lediglich anhand der Konfiguration oder Dokumentation überprüft wurden. Zeigen Sie den vorgeschlagenen README-Abschnitt vor der Bearbeitung von [Dokumentationspfad] an und behalten Sie nicht relevante Inhalte bei.

Vergleiche [Pfad zu CLAUDE.md] mit der aktuellen Struktur, den Skripten und den Konventionen des Repositorys. Starte die Bearbeitung der Datei noch nicht. Identifiziere veraltete Anweisungen, Duplikate, Widersprüche und Regeln, die sich zuverlässig aus dem Code ableiten lassen. Begründe jede vorgeschlagene Streichung, anstatt Anweisungen nur zu entfernen, um die Datei zu verkürzen. Schlage fehlende Build- oder Testbefehle nur dann vor, wenn du sie in Projektskripten, einem Makefile, der CI-Konfiguration oder der vorhandenen Dokumentation überprüfen kannst. Geben Sie für jede Ergänzung die Quelle an. Liefern Sie einen vorgeschlagenen Diff, der wichtige Vorgaben des Projekts beibehält. Markieren Sie aufgabenspezifische Anweisungen, die besser in eine Skill- oder Pfad-spezifische Regel passen würden, und warten Sie auf die Genehmigung, bevor Sie Änderungen übernehmen.

Schlagen Sie einen Claude-Code-Befehlshook vor, der nach Änderungen mit „Edit“ oder „Write“ an [Dateimuster] den [vorhandenen Formatierungsbefehl] ausführt. Überprüfen Sie zunächst die vorhandene Konfiguration in `claude/einstellungen.json` und die Konfiguration des Formatierers. Verwenden Sie die passende „PostToolUse“-Konfiguration für die installierte Claude-Code-Version. Formatieren Sie nur die betroffene Datei, behandeln Sie Pfade sicher und schließen Sie [generierte Dateien oder andere ausgeschlossene Pfade] aus. Installieren Sie keine Abhängigkeiten und ersetzen Sie keine bestehenden Hooks. Zeigen Sie den Diff der vorgeschlagenen Einstellungen und erklären Sie, wie Fehler des Formatierers gemeldet werden. Warten Sie auf die Genehmigung, bevor Sie den Hook anwenden. Testen Sie ihn nach der Genehmigung mit einer temporären Datei im Projekt und berichten Sie über das Ergebnis. Geben Sie an, welche Bearbeitungspfade abgedeckt sind und welche nicht, einschließlich der durch Shell-Befehle vorgenommenen Änderungen.

Sehen Sie sich [tool] –help und die Hilfe zu den für [Aufgabe] relevanten Unterbefehlen an. Installieren Sie das tool nicht, wenn es fehlt; melden Sie stattdessen diese Voraussetzung. Schlagen Sie die genauen Befehle vor, die zur Abschließung der Aufgabe erforderlich sind. Erläutern Sie deren Eingaben, Ausgaben und ob sie Dateien schreiben, Remote-Ressourcen ändern oder Anmeldedaten verwenden. Fügen Sie eine Dry-Run-Option hinzu, falls das Tool eine solche dokumentiert. Weisen Sie auf fehlende Konfigurationen oder Berechtigungen hin und bitten Sie um Klärung, anstatt Ressourcennamen oder Ziele zu erraten. Warten Sie auf die Genehmigung, bevor Sie die Befehle zur Aufgabenausführung ausführen. Führen Sie nach der Genehmigung nur die vereinbarten Befehle aus und melden Sie deren tatsächliche Ergebnisse, einschließlich etwaiger Fehler oder unvollständiger Schritte.

Vergleichen Sie [invoices.csv] und [Zahlungen.csv] anhand der [Rechnungs-ID oder des Schlüssels für den Abgleich]. Ändern Sie die Quelldateien nicht. Wenden Sie folgende Regeln an: [Währung und Rundungstoleranz], [Zuordnung von Teilzahlungen] und [Umgang mit Rückerstattungen, Guthaben und Überzahlungen]. Wenn eine Regel fehlt oder eine Übereinstimmung mehrdeutig ist, kennzeichnen Sie diese, anstatt die Zahlung automatisch zuzuordnen. Behalten Sie die IDen der Quellzeilen bei. Zeigen Sie für jede Rechnung den Rechnungsbetrag, die verrechneten Zahlungen und den Restbetrag an. Melden Sie doppelte IDs, nicht zugeordnete Rechnungen, nicht zugeordnete Zahlungen und Salden außerhalb der Toleranz. Stimmen Sie Rechnungs- und Zahlungssummen separat ab. Berücksichtigen Sie jede Quellzeile, ohne sie doppelt zu zählen; wenn sich eine Zahlung auf mehrere Rechnungen verteilt, zeigen Sie jede Zuordnung an und stellen Sie sicher, dass die Zuordnungen den Zahlungsbetrag nicht überschreiten. Schreiben Sie die Ergebnisse in [neue Ausgabepfade] und fassen Sie Ausnahmen zusammen, die einer Überprüfung bedürfen.

Schreiben Sie ein Skript, das [export.csv] für den Zeitraum von [Startdatum und -zeit, einschließlich] bis [Enddatum und -zeit, ausschließlich] unter Verwendung von [Zeitzone] und [Datumsspalten] zusammenfasst. Gruppieren Sie die Datensätze nach [Kategoreregeln] und berechnen Sie [erforderliche Metriken]. Behandeln Sie doppelte IDs und fehlende Werte gemäß [Regeln]. Ändern Sie die Eingabedatei nicht. Führen Sie das Skript auf der [genauen Eingabedatei] aus. Geben Sie die Anzahl der ein- und ausgeschlossenen Zeilen, die Kategoriesummen sowie die Datensätze an, die nicht klassifiziert werden konnten. Vergleichen Sie die Ergebnisse für [drei Kategorien] mit den unabhängig überprüften Zahlen in der [Referenzdatei]. Falls diese Zahlen nicht verfügbar sind, geben Sie an, dass die unabhängige Validierung noch aussteht. Zeigen Sie Abweichungen an und speichern Sie den Bericht unter [neuem Ausgabepfad].

Lesen Sie [angegebene Dateien oder Ordner] und erstellen Sie einen Entwurf für ein [Dokumenttyp und -umfang] für [Zielgruppe], der [Fragen oder Themen] abdeckt. Unterstützen Sie jede sachliche Behauptung mit einem Dateinamen und, sofern verfügbar, einem Verweis auf eine Seite, einen Abschnitt oder eine Zeile. Unterscheiden Sie direkte Zitate von Paraphrasen und behandeln Sie einen Vorschlag oder ein veraltetes Dokument nicht als bestätigte aktuelle Entscheidung. Weisen Sie auf widersprüchliche Quellen, fehlende Informationen und Behauptungen hin, die Sie nicht überprüfen können. Füllen Sie Lücken nicht mit Annahmen und führen Sie keine Bearbeitung der Quelldateien durch. Reichen Sie den Entwurf mit den Quellenangaben und einer kurzen Liste offener Fragen für den Prüfer ein.

Um eine Vorlage anzupassen, ersetzen Sie deren Platzhalter durch Angaben aus Ihrem Projekt und legen Sie fest, was Claude tun soll, bevor Sie Änderungen vornehmen. Befolgen Sie diese Schritte, um die Anfrage vorzubereiten und das Ergebnis zu überprüfen.

Bei einer kleinen, klar definierten Änderung können Sie Claude bitten, diese direkt umzusetzen. Bei unbekanntem Code, Änderungen, die mehrere Dateien betreffen, oder ungeklärten Anforderungen sollten Sie zunächst einen Plan erstellen.

Drücken Sie „Umschalt+Tab“, bis der Plan-Modus angezeigt wird, oder starten Sie Claude Code mit dem Befehl „claude --permission-mode plan“. In diesem Modus kann Claude Dateien überprüfen und schreibgeschützte Befehle ausführen, ohne Ihre Code-Bearbeitung durchzuführen. Überprüfen Sie die vorgeschlagenen Dateien, Abhängigkeiten und Tests, bevor Sie die Umsetzung genehmigen. Drücken Sie „Strg+G“, um den vorgeschlagenen Plan in Ihrem Editor zu öffnen.

Geben Sie Claude die Informationen, die zum Verständnis der Aufgabe erforderlich sind: einen Dateiverweis, ein bereinigtes Fehlerprotokoll, einen Screenshot oder ein Anforderungsdokument. Verwenden Sie „@“, gefolgt von einem Dateipfad, um den Inhalt dieser Datei einzufügen.

Wählen Sie die kleinste sinnvolle Auswahl an Quellen aus. Das Einbeziehen eines gesamten Protokolls oder Verzeichnisses kann irrelevantes Material hinzufügen und den Kontext überfrachten. Entfernen Sie Anmeldedaten und sensible Informationen, bevor Sie Protokolle freigeben, und stellen Sie sicher, dass Claude über die erforderlichen Tools verfügt, um die von Ihnen angegebenen Dokumentations-URLs abzurufen.

Beispielsweise übermittelt der Befehl „cat error.log | claude -p ‚Explain this Fehler‘“ ein Protokoll mit einer nicht-interaktiven Anfrage. Verwenden Sie ihn erst, nachdem Sie den Inhalt der Datei überprüft haben. Darin liegt der praktische Wert kontextbezogener KI: dem Modell relevante Informationen für die jeweilige Aufgabe zur Verfügung zu stellen.

Wenn Sie ein neues Feature hinzufügen, identifizieren Sie eine ähnliche Komponente oder Funktion im Repository. Teilen Sie Claude mit, welche Konventionen zu befolgen sind, beispielsweise hinsichtlich des API-Clients, der Validierungslogik, der Fehlerbehandlung oder der Teststruktur.

„Verfolgen Sie, wie @src/widgets/Weather.tsx Daten abruft und zwischenspeichert“ gibt Claude einen konkreten Anhaltspunkt. Nennen Sie außerdem alle Unterschiede, die das neue Feature erfordert, damit kein Verhalten kopiert wird, das nicht mehr passt. Diese Konventionen sollten den Softwareentwicklungs-Workflow Ihres Teams widerspiegeln.

Geben Sie bei Codeänderungen den entsprechenden Test-, Build- oder Lint-Befehl sowie das zu prüfende Verhalten an. Fordern Sie für Recherchezwecke Dateireferenzen oder Commit-IDs an. Stellen Sie bei der Arbeit an der Benutzeroberfläche ein Referenzbild sowie eine konfigurierte Methode zur Verfügung, um die Implementierung im gleichen Ansichtsbereich zu erfassen.

Bitten Sie Claude, einen Bericht über das zu erstellen, was tatsächlich geprüft wurde, einschließlich Fehlern und übersprungenen Prüfungen. Überprüfen Sie, ob die Nachweise die Anforderung abdecken; ein erfolgreicher Build bedeutet nicht, dass jedes geforderte Verhalten funktioniert.

Für umfangreichere Aufgaben bietet Claude Code außerdem eine /goal-Bedingung und Stop-Hooks. Der Zielauswerter bewertet die in der Unterhaltung zutage getretenen Hinweise, anstatt Dateien eigenständig zu überprüfen oder Tests auszuführen. Ein konfigurierter Stop-Hook kann die Fertigstellung blockieren, unterliegt jedoch Limiten hinsichtlich wiederholter Blockierungen. Beides ersetzt jedoch keine angemessenen Tests und keine Überprüfung durch Menschen.

Wenn wiederholte Korrekturen ein Problem nicht beheben, halten Sie inne und ermitteln Sie, was in der ursprünglichen Anfrage unklar geblieben ist. Speichern Sie die nützlichen Erkenntnisse, den aktuellen Git-Status und die verbleibende Arbeit, bevor Sie die Unterhaltung löschen.

Der Leitfaden für Best Practices von Anthropic empfiehlt, nach zwei erfolglosen Korrekturversuchen zum selben Problem von vorne zu beginnen. Verwenden Sie den Befehl /clear und geben Sie anschließend eine überarbeitete Eingabe an, die Ihre gewonnenen Erkenntnisse berücksichtigt. Das Löschen der Unterhaltung macht Dateiänderungen nicht rückgängig.

Drücken Sie die Esc-Taste, um eine laufende Antwort zu unterbrechen. Wenn das Eingabefeld leer ist, drücken Sie zweimal die Esc-Taste, um das Rückspulen-Menü zu öffnen und auszuwählen, was wiederhergestellt werden soll. Das Rückspulen macht nicht alle externen Auswirkungen rückgängig. Verwenden Sie daher Git-Checkpoints und separate Wiederherstellungsverfahren für Änderungen an Datenbanken oder Remote-Diensten.

Speichern Sie projektweite Richtlinien in „CLAUDE.md“, wiederholbare Abläufe in „Skills“ und Anweisungen für bestimmte Dateien in pfadbezogenen Regeln. Verwenden Sie Hooks für Aktionen, die an bestimmte Ereignisse geknüpft sind, wie beispielsweise das Ausführen eines Formatierers nach einer Bearbeitung.

Wählen Sie je nachdem aus, wann die Anweisung gelten soll:

Eine Anforderung für ein Feature gehört in der Regel in die entsprechende Aufgabe oder Spezifikation und nicht in die Datei „CLAUDE.md“. Das Hinzufügen temporärer Anweisungen zu einer projektweiten Datei erschwert es, diese von Konventionen zu unterscheiden, die im gesamten Repository gelten sollten.

Speichern Sie beispielsweise den Testbefehl des Projekts in der Datei „CLAUDE.md“, legen Sie komponentenbezogene Konventionen in einer pfadbezogenen Regel fest und speichern Sie ein wiederkehrendes Überprüfungsverfahren als „Skill“. Überprüfen Sie diese Dateien bei Änderungen an Befehlen oder Konventionen, genau wie Sie es auch bei anderer Projektdokumentation tun würden.

Prompts, CLAUDE.md und Skills steuern das Verhalten von Claude; sie garantieren jedoch nicht, dass eine Anweisung befolgt wird. Hooks können bei konfigurierten Ereignissen Prüfungen durchführen, ihre Zuverlässigkeit hängt jedoch vom Hook-Typ und der Implementierung ab.

Ein Befehlshook führt ein Skript aus. Ein Prompt- oder Agent-Hook stützt sich auf die Entscheidung eines Modells. Wie im Leitfaden zu Best Practices von Anthropic erläutert wird: „Ein Prompt- oder Agent-Hook bittet ein anderes Modell um eine Entscheidung, ist also ebenfalls nicht deterministisch.“ Verwenden Sie für eine Regel, die durchgesetzt werden muss, geeignete Berechtigungskontrollen und testen Sie den entsprechenden Befehls- oder HTTP-Hook, einschließlich der Art und Weise, wie er mit Fehlern umgeht.

Benutzerdefinierte Unteragenten sind eine weitere Möglichkeit, wiederkehrende Aufgaben zu organisieren. Definieren Sie einen Spezialisten unter „in.claude/agents/“, wenn eine eigene Rolle für die Überprüfung oder ein eigener Tool-Umfang erforderlich ist, anstatt jede Spezialanweisung zur Hauptsitzung hinzuzufügen. Diese Leitfäden zum besten Claude-Modell für die Arbeit und zu den Arten von KI-Agenten bieten zusätzlichen Kontext.

Wenn Ihr Team Prompts für mehrere KI-Produkte verwaltet, sehen Sie sich diese Prompt-Engineering-Tools an, mit denen Sie Bibliotheken über Claude Code hinaus verwalten können.

Wenn eine Sitzung ein unvollständiges oder ungeeignetes Ergebnis liefert, prüfen Sie, ob in der Anforderung wichtige Entscheidungen offen geblieben sind. Diese fünf Fehler können die Diagnose und Überprüfung der Arbeit erschweren.

„Untersuche das Repository“ gibt Claude kaum Anhaltspunkte dafür, welche Dateien relevant sind oder wann es aufhören soll. Möglicherweise erhalten Sie eine allgemeine Zusammenfassung ohne Antwort auf das Problem, das Anlass für die Anfrage war.

Benennen Sie das Verhalten oder die Entscheidung, die Sie verstehen müssen, legen Sie einen Startpunkt fest und definieren Sie die erwartete Ausgabe. Beispiel: „Verfolgen Sie nach, wie dieser Endpunkt Berechtigungen prüft, und nennen Sie die entsprechenden Funktionen.“ Wenn Sie Unteragenten einsetzen, geben Sie jedem einzelnen eine abgegrenzte Frage vor, anstatt dieselbe uneingeschränkte Suche zu delegieren.

Der Wechsel zwischen einem Feature, einem nicht damit zusammenhängenden Fehler und einer Dokumentationsanfrage führt dazu, dass die Unterhaltung einen Kontext enthält, der möglicherweise nicht auf die aktuelle Aufgabe zutrifft. Verweise wie „diese Datei“ oder „der frühere Ansatz“ werden dadurch mehrdeutig.

Verwenden Sie separate Sitzungen für nicht miteinander in Zusammenhang stehende Aufgaben. Wenn mehrere Sitzungen das Repository bearbeiten, verwenden Sie separate Git-Worktrees, damit nicht dasselbe Arbeitsverzeichnis geändert wird. Eine kurze Nebenbemerkung: Der Befehl /btw von Claude Code hält den Austausch aus dem Hauptverlauf der Unterhaltung heraus.

Ein Build kann erfolgreich sein, obwohl sich ein Feature falsch verhält. Eine Testsuite kann erfolgreich sein, weil sie die fehlerhafte Eingabe nie getestet hat. Wenn man Claude auffordert, „die Tests auszuführen“, wird dadurch nicht festgestellt, welche Anforderung diese Tests überprüfen.

Ordnen Sie die Akzeptanzkriterien bestimmten Prüfungen zu. Fordern Sie bei einer Fehlerbehebung den Nachweis an, dass der Reproduktionstest vor der Änderung fehlgeschlagen ist und danach erfolgreich war. Halten Sie ungetestete Kriterien in Sichtbarkeit, anstatt einen erfolgreichen Befehl als Überprüfung für die gesamte Änderung zu betrachten.

Eine ständig wachsende CLAUDE.md-Datei kann veraltete Befehle, doppelte Regeln und Anweisungen enthalten, die im Widerspruch zu aufgabenspezifischen Anforderungen stehen. Eine strengere Formulierung löst diese Konflikte nicht.

Überprüfen Sie die Datei anhand des aktuellen Repositorys. Entfernen Sie veraltete Anleitungen, klären Sie widersprüchliche Regeln und verschieben Sie nur in engen Anwendungsfällen gültige Anweisungen in Regeln oder Fähigkeiten, die auf den Pfad beschränkt sind. Wenn eine Anforderung durchgesetzt werden muss, konfigurieren und testen Sie die entsprechenden Kontrollen, anstatt sich auf wiederholte Erinnerungen zu verlassen.

Eine Überprüfung kann echte Fehler, unklare Probleme und optionale Refactoring-Vorschläge gleichzeitig aufzeigen. Die Umsetzung aller Vorschläge kann den Änderungsumfang vergrößern, ohne das gewünschte Verhalten zu verbessern.

Fragen Sie nach den Belegen und den Auswirkungen hinter jedem Befund. Priorisieren Sie Korrektheitsprobleme und nicht erfüllte Anforderungen, untersuchen Sie unklare Behauptungen und halten Sie nicht relevante Verbesserungen aus dem aktuellen Diff heraus. Ein Prüfer sollte in der Lage sein, keine umsetzbaren Befunde zu melden, wenn die Belege diese Schlussfolgerung unterstützen.

Um eine Vorlage anzupassen, ersetzen Sie deren Platzhalter durch Angaben aus Ihrem Projekt und legen Sie fest, was Claude tun soll, bevor Sie Änderungen vornehmen. Befolgen Sie diese Schritte, um die Anfrage vorzubereiten und das Ergebnis zu überprüfen.

Bei einer kleinen, klar definierten Änderung können Sie Claude bitten, diese direkt umzusetzen. Bei unbekanntem Code, Änderungen, die mehrere Dateien betreffen, oder ungeklärten Anforderungen sollten Sie zunächst einen Plan erstellen.

Drücken Sie „Umschalt+Tab“, bis der Plan-Modus angezeigt wird, oder starten Sie Claude Code mit dem Befehl „claude --permission-mode plan“. In diesem Modus kann Claude Dateien überprüfen und schreibgeschützte Befehle ausführen, ohne Ihre Code-Bearbeitung durchzuführen. Überprüfen Sie die vorgeschlagenen Dateien, Abhängigkeiten und Tests, bevor Sie die Umsetzung genehmigen. Drücken Sie „Strg+G“, um den vorgeschlagenen Plan in Ihrem Editor zu öffnen.

Geben Sie Claude die Informationen, die zum Verständnis der Aufgabe erforderlich sind: einen Dateiverweis, ein bereinigtes Fehlerprotokoll, einen Screenshot oder ein Anforderungsdokument. Verwenden Sie „@“, gefolgt von einem Dateipfad, um den Inhalt dieser Datei einzufügen.

Wählen Sie die kleinste sinnvolle Auswahl an Quellen aus. Das Einbeziehen eines gesamten Protokolls oder Verzeichnisses kann irrelevantes Material hinzufügen und den Kontext überfrachten. Entfernen Sie Anmeldedaten und sensible Informationen, bevor Sie Protokolle freigeben, und stellen Sie sicher, dass Claude über die erforderlichen Tools verfügt, um die von Ihnen angegebenen Dokumentations-URLs abzurufen.

Beispielsweise übermittelt der Befehl „cat error.log | claude -p ‚Explain this Fehler‘“ ein Protokoll mit einer nicht-interaktiven Anfrage. Verwenden Sie ihn erst, nachdem Sie den Inhalt der Datei überprüft haben. Darin liegt der praktische Wert kontextbezogener KI: dem Modell relevante Informationen für die jeweilige Aufgabe zur Verfügung zu stellen.

Wenn Sie ein neues Feature hinzufügen, identifizieren Sie eine ähnliche Komponente oder Funktion im Repository. Teilen Sie Claude mit, welche Konventionen zu befolgen sind, beispielsweise hinsichtlich des API-Clients, der Validierungslogik, der Fehlerbehandlung oder der Teststruktur.

„Verfolgen Sie, wie @src/widgets/Weather.tsx Daten abruft und zwischenspeichert“ gibt Claude einen konkreten Anhaltspunkt. Nennen Sie außerdem alle Unterschiede, die das neue Feature erfordert, damit kein Verhalten kopiert wird, das nicht mehr passt. Diese Konventionen sollten den Softwareentwicklungs-Workflow Ihres Teams widerspiegeln.

Geben Sie bei Codeänderungen den entsprechenden Test-, Build- oder Lint-Befehl sowie das zu prüfende Verhalten an. Fordern Sie für Recherchezwecke Dateireferenzen oder Commit-IDs an. Stellen Sie bei der Arbeit an der Benutzeroberfläche ein Referenzbild sowie eine konfigurierte Methode bereit, um die Implementierung im gleichen Ansichtsbereich zu erfassen.

Bitten Sie Claude, einen Bericht über das zu erstellen, was tatsächlich geprüft wurde, einschließlich Fehlern und übersprungenen Prüfungen. Überprüfen Sie, ob die Nachweise die Anforderung abdecken; ein erfolgreicher Build bedeutet nicht, dass jedes geforderte Verhalten funktioniert.

Für umfangreichere Aufgaben bietet Claude Code außerdem eine /goal-Bedingung und Stop-Hooks. Der Zielauswerter bewertet die in der Unterhaltung zutage getretenen Hinweise, anstatt Dateien eigenständig zu überprüfen oder Tests auszuführen. Ein konfigurierter Stop-Hook kann die Fertigstellung blockieren, unterliegt jedoch Limiten hinsichtlich wiederholter Blockierungen. Beides ersetzt jedoch keine angemessenen Tests und keine Überprüfung durch Menschen.

Wenn wiederholte Korrekturen ein Problem nicht beheben, halten Sie inne und ermitteln Sie, was in der ursprünglichen Anfrage unklar geblieben ist. Speichern Sie die nützlichen Erkenntnisse, den aktuellen Git-Status und die verbleibende Arbeit, bevor Sie die Unterhaltung löschen.

Der Leitfaden für Best Practices von Anthropic empfiehlt, nach zwei erfolglosen Korrekturversuchen zum selben Problem von vorne zu beginnen. Verwenden Sie den Befehl /clear und geben Sie anschließend eine überarbeitete Eingabe an, die Ihre gewonnenen Erkenntnisse berücksichtigt. Das Löschen der Unterhaltung macht Dateiänderungen nicht rückgängig.

Drücken Sie die Esc-Taste, um eine laufende Antwort zu unterbrechen. Wenn das Eingabefeld leer ist, drücken Sie zweimal die Esc-Taste, um das Rückspulen-Menü zu öffnen und auszuwählen, was wiederhergestellt werden soll. Das Rückspulen macht nicht alle externen Auswirkungen rückgängig. Verwenden Sie daher Git-Checkpoints und separate Wiederherstellungsverfahren für Änderungen an Datenbanken oder Remote-Diensten.

Speichern Sie projektweite Richtlinien in „CLAUDE.md“, wiederholbare Abläufe in „Skills“ und Anweisungen für bestimmte Dateien in pfadbezogenen Regeln. Verwenden Sie Hooks für Aktionen, die an bestimmte Ereignisse geknüpft sind, wie beispielsweise das Ausführen eines Formatierers nach einer Bearbeitung.

Wählen Sie je nachdem aus, wann die Anweisung gelten soll:

Eine Anforderung für ein Feature gehört in der Regel in die entsprechende Aufgabe oder Spezifikation und nicht in die Datei „CLAUDE.md“. Das Hinzufügen temporärer Anweisungen zu einer projektweiten Datei erschwert es, diese von Konventionen zu unterscheiden, die im gesamten Repository gelten sollten.

Speichern Sie beispielsweise den Testbefehl des Projekts in der Datei „CLAUDE.md“, legen Sie komponentenbezogene Konventionen in einer pfadbezogenen Regel fest und speichern Sie ein wiederkehrendes Überprüfungsverfahren als „Skill“. Überprüfen Sie diese Dateien bei Änderungen an Befehlen oder Konventionen, genau wie Sie es auch bei anderer Projektdokumentation tun würden.

Prompts, CLAUDE.md und Skills steuern das Verhalten von Claude; sie garantieren jedoch nicht, dass eine Anweisung befolgt wird. Hooks können bei konfigurierten Ereignissen Prüfungen durchführen, ihre Zuverlässigkeit hängt jedoch vom Hook-Typ und der Implementierung ab.

Ein Befehlshook führt ein Skript aus. Ein Prompt- oder Agent-Hook stützt sich auf die Entscheidung eines Modells. Wie im Leitfaden zu Best Practices von Anthropic erläutert wird: „Ein Prompt- oder Agent-Hook bittet ein anderes Modell um eine Entscheidung, ist also ebenfalls nicht deterministisch.“ Verwenden Sie für eine Regel, die durchgesetzt werden muss, geeignete Berechtigungskontrollen und testen Sie den entsprechenden Befehls- oder HTTP-Hook, einschließlich der Art und Weise, wie er mit Fehlern umgeht.

Benutzerdefinierte Unteragenten sind eine weitere Möglichkeit, wiederkehrende Aufgaben zu organisieren. Definieren Sie einen Spezialisten unter „in.claude/agents/“, wenn eine bestimmte Rolle oder ein bestimmter Tool-Umfang erforderlich ist, anstatt jede Spezialistenanweisung zur Hauptsitzung hinzuzufügen. Diese Leitfäden zum besten Claude-Modell für die Arbeit und zu den Arten von KI-Agenten bieten zusätzlichen Kontext.

Wenn Ihr Team Prompts für mehrere KI-Produkte verwaltet, sehen Sie sich diese Prompt-Engineering-Tools an, mit denen Sie Bibliotheken über Claude Code hinaus verwalten können.

Wenn eine Sitzung ein unvollständiges oder ungeeignetes Ergebnis liefert, prüfen Sie, ob in der Anforderung wichtige Entscheidungen offen geblieben sind. Diese fünf Fehler können die Diagnose und Überprüfung der Arbeit erschweren.

„Untersuche das Repository“ gibt Claude kaum Anhaltspunkte dafür, welche Dateien relevant sind oder wann es aufhören soll. Möglicherweise erhalten Sie eine allgemeine Zusammenfassung ohne Antwort auf das Problem, das Anlass für die Anfrage war.

Benennen Sie das Verhalten oder die Entscheidung, die Sie verstehen müssen, legen Sie einen Startpunkt fest und definieren Sie die erwartete Ausgabe. Beispiel: „Verfolgen Sie nach, wie dieser Endpunkt Berechtigungen prüft, und nennen Sie die entsprechenden Funktionen.“ Wenn Sie Unteragenten einsetzen, geben Sie jedem einzelnen eine abgegrenzte Frage vor, anstatt dieselbe uneingeschränkte Suche zu delegieren.

Der Wechsel zwischen einem Feature, einem nicht damit zusammenhängenden Fehler und einer Dokumentationsanfrage führt dazu, dass die Unterhaltung einen Kontext enthält, der möglicherweise nicht auf die aktuelle Aufgabe zutrifft. Verweise wie „diese Datei“ oder „der frühere Ansatz“ werden dadurch mehrdeutig.

Verwenden Sie separate Sitzungen für nicht miteinander in Zusammenhang stehende Aufgaben. Wenn mehrere Sitzungen das Repository bearbeiten, verwenden Sie separate Git-Worktrees, damit nicht dasselbe Arbeitsverzeichnis geändert wird. Eine kurze Nebenbemerkung: Der Befehl /btw von Claude Code hält den Austausch aus dem Hauptverlauf der Unterhaltung heraus.

Ein Build kann erfolgreich sein, obwohl sich ein Feature falsch verhält. Eine Testsuite kann erfolgreich sein, weil sie die fehlerhafte Eingabe nie getestet hat. Wenn man Claude auffordert, „die Tests auszuführen“, wird dadurch nicht festgestellt, welche Anforderung diese Tests überprüfen.

Ordnen Sie die Akzeptanzkriterien bestimmten Prüfungen zu. Fordern Sie bei einer Fehlerbehebung den Nachweis an, dass der Reproduktionstest vor der Änderung fehlgeschlagen ist und danach erfolgreich war. Halten Sie ungetestete Kriterien in Sicht, anstatt einen erfolgreichen Befehl als Überprüfung für die gesamte Änderung zu betrachten.

Eine ständig wachsende CLAUDE.md-Datei kann veraltete Befehle, doppelte Regeln und Anweisungen enthalten, die im Widerspruch zu aufgabenspezifischen Anforderungen stehen. Eine strengere Formulierung löst diese Konflikte nicht.

Überprüfen Sie die Datei anhand des aktuellen Repositorys. Entfernen Sie veraltete Anleitungen, klären Sie widersprüchliche Regeln und verschieben Sie nur in engen Anwendungsfällen gültige Anweisungen in Regeln oder Fähigkeiten, die auf den Pfad beschränkt sind. Wenn eine Anforderung durchgesetzt werden muss, konfigurieren und testen Sie die entsprechenden Kontrollen, anstatt sich auf wiederholte Erinnerungen zu verlassen.

Eine Überprüfung kann echte Fehler, unklare Probleme und optionale Refactoring-Vorschläge gleichzeitig aufzeigen. Die Umsetzung aller Vorschläge kann den Änderungsumfang vergrößern, ohne das gewünschte Verhalten zu verbessern.

Fragen Sie nach den Belegen und den Auswirkungen hinter jedem Befund. Priorisieren Sie Korrektheitsprobleme und nicht erfüllte Anforderungen, untersuchen Sie unklare Behauptungen und halten Sie nicht relevante Verbesserungen aus dem aktuellen Diff heraus. Ein Prüfer sollte in der Lage sein, keine umsetzbaren Befunde zu melden, wenn die Belege diese Schlussfolgerung unterstützen.

Um eine Vorlage anzupassen, ersetzen Sie deren Platzhalter durch Angaben aus Ihrem Projekt und legen Sie fest, was Claude tun soll, bevor Sie Änderungen vornehmen. Befolgen Sie diese Schritte, um die Anfrage vorzubereiten und das Ergebnis zu überprüfen.

Bei einer kleinen, klar definierten Änderung können Sie Claude bitten, diese direkt umzusetzen. Bei unbekanntem Code, Änderungen, die mehrere Dateien betreffen, oder ungeklärten Anforderungen sollten Sie zunächst einen Plan erstellen.

Drücken Sie „Umschalt+Tab“, bis der Plan-Modus angezeigt wird, oder starten Sie Claude Code mit dem Befehl „claude --permission-mode plan“. In diesem Modus kann Claude Dateien überprüfen und schreibgeschützte Befehle ausführen, ohne Ihre Code-Bearbeitung durchzuführen. Überprüfen Sie die vorgeschlagenen Dateien, Abhängigkeiten und Tests, bevor Sie die Umsetzung genehmigen. Drücken Sie „Strg+G“, um den vorgeschlagenen Plan in Ihrem Editor zu öffnen.

Geben Sie Claude die Informationen, die zum Verständnis der Aufgabe erforderlich sind: einen Dateiverweis, ein bereinigtes Fehlerprotokoll, einen Screenshot oder ein Anforderungsdokument. Verwenden Sie „@“ gefolgt von einem Dateipfad, um den Inhalt dieser Datei einzubinden.

Wählen Sie die kleinste sinnvolle Auswahl an Quellen. Das Einbeziehen eines gesamten Protokolls oder Verzeichnisses kann irrelevantes Material hinzufügen und den Kontext überfrachten. Entfernen Sie Anmeldedaten und sensible Informationen, bevor Sie Protokolle freigeben, und stellen Sie sicher, dass Claude über die erforderlichen Tools verfügt, um die von Ihnen angegebenen Dokumentations-URLs abzurufen.

Beispielsweise übermittelt der Befehl „cat Fehler.log | claude -p ‚Explain this Fehler‘“ ein Protokoll mit einer nicht-interaktiven Anfrage. Verwenden Sie ihn erst, nachdem Sie den Inhalt der Datei überprüft haben. Darin liegt der praktische Wert kontextbezogener KI: dem Modell relevante Informationen für die jeweilige Aufgabe zur Verfügung zu stellen.

Wenn Sie ein neues Feature hinzufügen, identifizieren Sie eine ähnliche Komponente oder Funktion im Repository. Teilen Sie Claude mit, welche Konventionen zu befolgen sind, beispielsweise hinsichtlich des API-Clients, der Validierungslogik, der Fehlerbehandlung oder der Teststruktur.

„Verfolgen Sie, wie @src/widgets/Weather.tsx Daten abruft und zwischenspeichert“ gibt Claude einen konkreten Anhaltspunkt. Nennen Sie außerdem alle Unterschiede, die das neue Feature erfordert, damit kein Verhalten kopiert wird, das nicht mehr passt. Diese Konventionen sollten den Softwareentwicklungs-Workflow Ihres Teams widerspiegeln.

Geben Sie bei Codeänderungen den entsprechenden Test-, Build- oder Lint-Befehl sowie das zu prüfende Verhalten an. Fordern Sie für Recherchezwecke Dateireferenzen oder Commit-IDs an. Stellen Sie bei der Arbeit an der Benutzeroberfläche ein Referenzbild sowie eine konfigurierte Methode bereit, um die Implementierung im gleichen Ansichtsbereich zu erfassen.

Bitten Sie Claude, einen Bericht über das zu erstellen, was tatsächlich geprüft wurde, einschließlich Fehlern und übersprungenen Prüfungen. Überprüfen Sie, ob die Nachweise die Anforderung abdecken; ein erfolgreicher Build bedeutet nicht, dass jedes geforderte Verhalten funktioniert.

Für umfangreichere Aufgaben bietet Claude Code außerdem eine /goal-Bedingung und Stop-Hooks. Der Zielauswerter bewertet die in der Unterhaltung zutage getretenen Hinweise, anstatt Dateien eigenständig zu überprüfen oder Tests auszuführen. Ein konfigurierter Stop-Hook kann die Fertigstellung blockieren, unterliegt jedoch Limiten hinsichtlich wiederholter Blockierungen. Beides ersetzt jedoch keine angemessenen Tests und keine Überprüfung durch Menschen.

Wenn wiederholte Korrekturen ein Problem nicht beheben, halten Sie inne und ermitteln Sie, was in der ursprünglichen Anfrage unklar geblieben ist. Speichern Sie die nützlichen Erkenntnisse, den aktuellen Git-Status und die verbleibende Arbeit, bevor Sie die Unterhaltung löschen.

Der Leitfaden für Best Practices von Anthropic empfiehlt, nach zwei erfolglosen Korrekturversuchen zum selben Problem von vorne zu beginnen. Verwenden Sie den Befehl /clear und geben Sie anschließend eine überarbeitete Eingabe an, die Ihre gewonnenen Erkenntnisse berücksichtigt. Das Löschen der Unterhaltung macht Dateiänderungen nicht rückgängig.

Drücken Sie die Esc-Taste, um eine laufende Antwort zu unterbrechen. Wenn das Eingabefeld leer ist, drücken Sie zweimal die Esc-Taste, um das Rückspulen-Menü zu öffnen und auszuwählen, was wiederhergestellt werden soll. Das Rückspulen macht nicht alle externen Auswirkungen rückgängig. Verwenden Sie daher Git-Checkpoints und separate Wiederherstellungsverfahren für Änderungen an Datenbanken oder Remote-Diensten.

Speichern Sie projektweite Richtlinien in „CLAUDE.md“, wiederholbare Abläufe in „Skills“ und Anweisungen für bestimmte Dateien in pfadbezogenen Regeln. Verwenden Sie Hooks für Aktionen, die an bestimmte Ereignisse geknüpft sind, wie beispielsweise das Ausführen eines Formatierers nach einer Bearbeitung.

Wählen Sie je nachdem aus, wann die Anweisung gelten soll:

Eine Anforderung für ein Feature gehört in der Regel in die entsprechende Aufgabe oder Spezifikation und nicht in die Datei „CLAUDE.md“. Das Hinzufügen temporärer Anweisungen zu einer projektweiten Datei erschwert es, diese von Konventionen zu unterscheiden, die im gesamten Repository gelten sollten.

Speichern Sie beispielsweise den Testbefehl des Projekts in der Datei „CLAUDE.md“, legen Sie komponentenbezogene Konventionen in einer pfadbezogenen Regel fest und speichern Sie ein wiederkehrendes Überprüfungsverfahren als „Skill“. Überprüfen Sie diese Dateien bei Änderungen an Befehlen oder Konventionen, genau wie Sie es auch bei anderer Projektdokumentation tun würden.

Prompts, CLAUDE.md und Skills steuern das Verhalten von Claude; sie garantieren jedoch nicht, dass eine Anweisung befolgt wird. Hooks können bei konfigurierten Ereignissen Prüfungen durchführen, ihre Zuverlässigkeit hängt jedoch vom Hook-Typ und der Implementierung ab.

Ein Befehlshook führt ein Skript aus. Ein Prompt- oder Agent-Hook stützt sich auf die Entscheidung eines Modells. Wie im Leitfaden zu Best Practices von Anthropic erläutert wird: „Ein Prompt- oder Agent-Hook bittet ein anderes Modell um eine Entscheidung, ist also ebenfalls nicht deterministisch.“ Verwenden Sie für eine Regel, die durchgesetzt werden muss, geeignete Berechtigungskontrollen und testen Sie den entsprechenden Befehls- oder HTTP-Hook, einschließlich der Art und Weise, wie er mit Fehlern umgeht.

Benutzerdefinierte Unteragenten sind eine weitere Möglichkeit, wiederkehrende Aufgaben zu organisieren. Definieren Sie einen Spezialisten unter „in.claude/agents/“, wenn eine spezifische Überprüfungsrolle oder ein bestimmter Tool-Umfang erforderlich ist, anstatt jede Spezialistenanweisung zur Hauptsitzung hinzuzufügen. Diese Leitfäden zum besten Claude-Modell für die Arbeit und zu den Arten von KI-Agenten bieten zusätzlichen Kontext.

Wenn Ihr Team Prompts für mehrere KI-Produkte verwaltet, sehen Sie sich diese Prompt-Engineering-Tools an, mit denen Sie Bibliotheken über Claude Code hinaus verwalten können.

Wenn eine Sitzung ein unvollständiges oder ungeeignetes Ergebnis liefert, prüfen Sie, ob in der Anforderung wichtige Entscheidungen offen geblieben sind. Diese fünf Fehler können die Diagnose und Überprüfung der Arbeit erschweren.

„Untersuche das Repository“ gibt Claude kaum Anhaltspunkte dafür, welche Dateien relevant sind oder wann es aufhören soll. Möglicherweise erhalten Sie eine allgemeine Zusammenfassung ohne Antwort auf das Problem, das Anlass für die Anfrage war.

Benennen Sie das Verhalten oder die Entscheidung, die Sie verstehen müssen, legen Sie einen Startpunkt fest und definieren Sie die erwartete Ausgabe. Beispiel: „Verfolgen Sie nach, wie dieser Endpunkt Berechtigungen prüft, und nennen Sie die entsprechenden Funktionen.“ Wenn Sie Unteragenten einsetzen, geben Sie jedem einzelnen eine abgegrenzte Frage vor, anstatt dieselbe uneingeschränkte Suche zu delegieren.

Der Wechsel zwischen einem Feature, einem nicht damit zusammenhängenden Fehler und einer Dokumentationsanfrage führt dazu, dass die Unterhaltung einen Kontext enthält, der möglicherweise nicht auf die aktuelle Aufgabe zutrifft. Verweise wie „diese Datei“ oder „der frühere Ansatz“ werden dadurch mehrdeutig.

Verwenden Sie separate Sitzungen für nicht miteinander in Zusammenhang stehende Aufgaben. Wenn mehrere Sitzungen das Repository bearbeiten, verwenden Sie separate Git-Worktrees, damit nicht dasselbe Arbeitsverzeichnis geändert wird. Eine kurze Nebenbemerkung: Der Befehl /btw von Claude Code hält den Austausch aus dem Hauptverlauf der Unterhaltung heraus.

Ein Build kann erfolgreich sein, obwohl sich ein Feature fehlerhaft verhält. Eine Testsuite kann erfolgreich sein, weil sie die fehlerhafte Eingabe nie getestet hat. Wenn man Claude auffordert, „die Tests auszuführen“, wird dadurch nicht klar, welche Anforderung diese Tests überprüfen.

Ordnen Sie die Akzeptanzkriterien bestimmten Prüfungen zu. Fordern Sie bei einer Fehlerbehebung den Nachweis an, dass der Reproduktionstest vor der Änderung fehlgeschlagen ist und danach erfolgreich war. Halten Sie ungetestete Kriterien in Sichtbarkeit, anstatt einen erfolgreichen Befehl als Überprüfung für die gesamte Änderung zu betrachten.

Eine ständig wachsende CLAUDE.md-Datei kann veraltete Befehle, doppelte Regeln und Anweisungen enthalten, die im Widerspruch zu aufgabenspezifischen Anforderungen stehen. Eine strengere Formulierung löst diese Konflikte nicht.

Überprüfen Sie die Datei anhand des aktuellen Repositorys. Entfernen Sie veraltete Anleitungen, klären Sie widersprüchliche Regeln und verschieben Sie nur in engen Anwendungsfällen gültige Anweisungen in Regeln oder Fähigkeiten, die auf den Pfad beschränkt sind. Wenn eine Anforderung durchgesetzt werden muss, konfigurieren und testen Sie die entsprechenden Kontrollen, anstatt sich auf wiederholte Erinnerungen zu verlassen.

Eine Überprüfung kann echte Fehler, unklare Probleme und optionale Refactoring-Vorschläge gleichzeitig aufzeigen. Die Umsetzung aller Vorschläge kann den Änderungsumfang vergrößern, ohne das gewünschte Verhalten zu verbessern.

Fragen Sie nach den Belegen und den Auswirkungen hinter jedem Befund. Priorisieren Sie Korrektheitsprobleme und nicht erfüllte Anforderungen, untersuchen Sie unklare Behauptungen und halten Sie nicht relevante Verbesserungen aus dem aktuellen Diff heraus. Ein Prüfer sollte in der Lage sein, keine umsetzbaren Befunde zu melden, wenn die Belege diese Schlussfolgerung unterstützen.

Um eine Vorlage anzupassen, ersetzen Sie deren Platzhalter durch Angaben aus Ihrem Projekt und legen Sie fest, was Claude zu erledigen hat, bevor Sie Änderungen vornehmen. Befolgen Sie diese Schritte, um die Anfrage vorzubereiten und das Ergebnis zu überprüfen.

Bei einer kleinen, klar definierten Änderung können Sie Claude bitten, diese direkt umzusetzen. Bei unbekanntem Code, Änderungen, die mehrere Dateien betreffen, oder ungeklärten Anforderungen sollten Sie zunächst einen Plan erstellen.

Drücken Sie „Umschalt+Tab“, bis der Plan-Modus angezeigt wird, oder starten Sie Claude Code mit dem Befehl „claude --permission-mode plan“. In diesem Modus kann Claude Dateien überprüfen und schreibgeschützte Befehle ausführen, ohne Ihre Code-Bearbeitung durchzuführen. Überprüfen Sie die vorgeschlagenen Dateien, Abhängigkeiten und Tests, bevor Sie die Umsetzung genehmigen. Drücken Sie „Strg+G“, um den vorgeschlagenen Plan in Ihrem Editor zu öffnen.

Geben Sie Claude die Informationen, die zum Verständnis der Aufgabe erforderlich sind: einen Dateiverweis, ein bereinigtes Fehlerprotokoll, einen Screenshot oder ein Anforderungsdokument. Verwenden Sie „@“, gefolgt von einem Dateipfad, um den Inhalt dieser Datei einzufügen.

Wählen Sie die kleinste sinnvolle Auswahl an Quellen aus. Das Einbeziehen eines gesamten Protokolls oder Verzeichnisses kann irrelevantes Material hinzufügen und den Kontext überfrachten. Entfernen Sie Anmeldedaten und sensible Informationen, bevor Sie Protokolle freigeben, und stellen Sie sicher, dass Claude über die erforderlichen Tools verfügt, um die von Ihnen angegebenen Dokumentations-URLs abzurufen.

Beispielsweise übermittelt der Befehl „cat Fehler.log | claude -p ‚Explain this Fehler‘“ ein Protokoll mit einer nicht-interaktiven Anfrage. Verwenden Sie ihn erst, nachdem Sie den Inhalt der Datei überprüft haben. Darin liegt der praktische Wert kontextbezogener KI: dem Modell relevante Informationen für die jeweilige Aufgabe zur Verfügung zu stellen.

Wenn Sie ein neues Feature hinzufügen, identifizieren Sie eine ähnliche Komponente oder Funktion im Repository. Teilen Sie Claude mit, welche Konventionen zu befolgen sind, beispielsweise hinsichtlich des API-Clients, der Validierungslogik, der Fehlerbehandlung oder der Teststruktur.

„Verfolgen Sie, wie @src/widgets/Weather.tsx Daten abruft und zwischenspeichert“ gibt Claude einen konkreten Anhaltspunkt. Nennen Sie außerdem alle Unterschiede, die das neue Feature erfordert, damit kein Verhalten kopiert wird, das nicht mehr passt. Diese Konventionen sollten den Softwareentwicklungs-Workflow Ihres Teams widerspiegeln.

Geben Sie bei Codeänderungen den entsprechenden Test-, Build- oder Lint-Befehl sowie das zu prüfende Verhalten an. Fordern Sie für Recherchezwecke Dateireferenzen oder Commit-IDs an. Stellen Sie bei der Arbeit an der Benutzeroberfläche ein Referenzbild sowie eine konfigurierte Methode bereit, um die Implementierung im gleichen Ansichtsbereich zu erfassen.

Bitten Sie Claude, einen Bericht über das zu erstellen, was tatsächlich geprüft wurde, einschließlich Fehlern und übersprungenen Prüfungen. Überprüfen Sie, ob die Nachweise die Anforderung abdecken; ein erfolgreicher Build bedeutet nicht, dass jedes geforderte Verhalten funktioniert.

Für umfangreichere Aufgaben bietet Claude Code außerdem eine /goal-Bedingung und Stop-Hooks. Der Zielauswerter bewertet die während der Unterhaltung zutage getretenen Hinweise, anstatt Dateien eigenständig zu überprüfen oder Tests auszuführen. Ein konfigurierter Stop-Hook kann die Fertigstellung blockieren, unterliegt jedoch Limiten hinsichtlich wiederholter Blockierungen. Beides ersetzt jedoch keine angemessenen Tests und keine Überprüfung durch Menschen.

Wenn wiederholte Korrekturen ein Problem nicht beheben, halten Sie inne und ermitteln Sie, was in der ursprünglichen Anfrage unklar geblieben ist. Speichern Sie die nützlichen Erkenntnisse, den aktuellen Git-Status und die verbleibenden Arbeiten, bevor Sie die Unterhaltung löschen.

Der Leitfaden für Best Practices von Anthropic empfiehlt, nach zwei erfolglosen Korrekturversuchen zum selben Problem von vorne zu beginnen. Verwenden Sie den Befehl /clear und geben Sie anschließend eine überarbeitete Eingabe an, die Ihre gewonnenen Erkenntnisse berücksichtigt. Das Löschen der Unterhaltung macht Dateiänderungen nicht rückgängig.

Drücken Sie die Esc-Taste, um eine laufende Antwort zu unterbrechen. Wenn das Eingabefeld leer ist, drücken Sie zweimal die Esc-Taste, um das Rückspulen-Menü zu öffnen und auszuwählen, was wiederhergestellt werden soll. Das Rückspulen macht nicht alle externen Auswirkungen rückgängig. Verwenden Sie daher Git-Checkpoints und separate Wiederherstellungsverfahren für Änderungen an Datenbanken oder Remote-Diensten.

Speichern Sie projektweite Richtlinien in „CLAUDE.md“, wiederholbare Abläufe in „Skills“ und Anweisungen für bestimmte Dateien in pfadbezogenen Regeln. Verwenden Sie Hooks für Aktionen, die an bestimmte Ereignisse geknüpft sind, wie beispielsweise das Ausführen eines Formatierers nach einer Bearbeitung.

Wählen Sie je nachdem aus, wann die Anweisung gelten soll:

Eine Anforderung für ein Feature gehört in der Regel in die entsprechende Aufgabe oder Spezifikation und nicht in die Datei „CLAUDE.md“. Das Hinzufügen temporärer Anweisungen zu einer projektweiten Datei erschwert es, diese von Konventionen zu unterscheiden, die im gesamten Repository gelten sollten.

Beispiel: Speichern Sie den Testbefehl des Projekts in der Datei „CLAUDE.md“, legen Sie komponentenbezogene Konventionen in einer pfadbezogenen Regel fest und speichern Sie ein wiederkehrendes Überprüfungsverfahren als „Skill“. Überprüfen Sie diese Dateien bei Änderungen an Befehlen oder Konventionen, genau wie Sie es auch bei anderer Projektdokumentation tun würden.

Prompts, CLAUDE.md und Skills steuern das Verhalten von Claude; sie garantieren jedoch nicht, dass eine Anweisung befolgt wird. Hooks können bei konfigurierten Ereignissen Prüfungen durchführen, ihre Zuverlässigkeit hängt jedoch vom Hook-Typ und der Implementierung ab.

Ein Befehlshook führt ein Skript aus. Ein Prompt- oder Agent-Hook stützt sich auf die Entscheidung eines Modells. Wie im Leitfaden zu Best Practices von Anthropic erläutert wird: „Ein Prompt- oder Agent-Hook bittet ein anderes Modell um eine Entscheidung, ist also ebenfalls nicht deterministisch.“ Verwenden Sie für eine Regel, die durchgesetzt werden muss, geeignete Berechtigungskontrollen und testen Sie den entsprechenden Befehls- oder HTTP-Hook, einschließlich der Art und Weise, wie er mit Fehlern umgeht.

Benutzerdefinierte Unteragenten sind eine weitere Möglichkeit, wiederkehrende Aufgaben zu organisieren. Definieren Sie einen Spezialisten unter „in.claude/agents/“, wenn eine spezifische Überprüfungsrolle oder ein bestimmter Tool-Umfang erforderlich ist, anstatt jede Spezialistenanweisung zur Hauptsitzung hinzuzufügen. Diese Leitfäden zum besten Claude-Modell für die Arbeit und zu den Arten von KI-Agenten bieten zusätzlichen Kontext.

Wenn Ihr Team Prompts für mehrere KI-Produkte verwaltet, sehen Sie sich diese Prompt-Engineering-Tools an, mit denen Sie Bibliotheken über Claude Code hinaus verwalten können.

Wenn eine Sitzung ein unvollständiges oder ungeeignetes Ergebnis liefert, prüfen Sie, ob in der Anforderung wichtige Entscheidungen offen geblieben sind. Diese fünf Fehler können die Diagnose und Überprüfung der Arbeit erschweren.

„Untersuche das Repository“ gibt Claude kaum Anhaltspunkte dafür, welche Dateien relevant sind oder wann es aufhören soll. Möglicherweise erhalten Sie eine allgemeine Zusammenfassung ohne Antwort auf das Problem, das Anlass für die Anfrage war.

Benennen Sie das Verhalten oder die Entscheidung, die Sie verstehen müssen, legen Sie einen Startpunkt fest und definieren Sie die erwartete Ausgabe. Beispiel: „Verfolgen Sie nach, wie dieser Endpunkt Berechtigungen prüft, und nennen Sie die entsprechenden Funktionen.“ Wenn Sie Unteragenten einsetzen, geben Sie jedem einzelnen eine abgegrenzte Frage vor, anstatt dieselbe uneingeschränkte Suche zu delegieren.

Der Wechsel zwischen einem Feature, einem nicht damit zusammenhängenden Fehler und einer Dokumentationsanfrage führt dazu, dass die Unterhaltung einen Kontext enthält, der möglicherweise nicht auf die aktuelle Aufgabe zutrifft. Verweise wie „diese Datei“ oder „der frühere Ansatz“ werden dadurch mehrdeutig.

Verwenden Sie separate Sitzungen für nicht miteinander in Zusammenhang stehende Aufgaben. Wenn mehrere Sitzungen das Repository bearbeiten, verwenden Sie separate Git-Worktrees, damit nicht dasselbe Arbeitsverzeichnis geändert wird. Eine kurze Nebenbemerkung: Der Befehl /btw von Claude Code hält den Austausch aus dem Hauptverlauf der Unterhaltung heraus.

Ein Build kann erfolgreich sein, obwohl sich ein Feature falsch verhält. Eine Testsuite kann erfolgreich sein, weil sie die fehlerhafte Eingabe nie getestet hat. Wenn man Claude auffordert, „die Tests auszuführen“, wird dadurch nicht festgestellt, welche Anforderung diese Tests überprüfen.

Ordnen Sie die Akzeptanzkriterien bestimmten Prüfungen zu. Fordern Sie bei einer Fehlerbehebung den Nachweis an, dass der Reproduktionstest vor der Änderung fehlgeschlagen ist und danach erfolgreich war. Halten Sie ungetestete Kriterien in Sichtbarkeit, anstatt einen erfolgreichen Befehl als Überprüfung für die gesamte Änderung zu betrachten.

Eine ständig wachsende CLAUDE.md-Datei kann veraltete Befehle, doppelte Regeln und Anweisungen enthalten, die im Widerspruch zu aufgabenspezifischen Anforderungen stehen. Eine strengere Formulierung löst diese Konflikte nicht.

Überprüfen Sie die Datei anhand des aktuellen Repositorys. Entfernen Sie veraltete Anleitungen, klären Sie widersprüchliche Regeln und verschieben Sie nur in engen Anwendungsfällen gültige Anweisungen in Regeln oder Fähigkeiten mit Pfadgültigkeit. Wenn eine Anforderung durchgesetzt werden muss, konfigurieren und testen Sie die entsprechenden Kontrollen, anstatt sich auf wiederholte Erinnerungen zu verlassen.

Eine Überprüfung kann echte Fehler, unklare Probleme und optionale Refactoring-Vorschläge gleichzeitig aufzeigen. Die Umsetzung aller Vorschläge kann den Änderungsumfang vergrößern, ohne das gewünschte Verhalten zu verbessern.

Fragen Sie nach den Belegen und den Auswirkungen hinter jedem Befund. Priorisieren Sie Korrektheitsprobleme und nicht erfüllte Anforderungen, untersuchen Sie unklare Behauptungen und halten Sie nicht relevante Verbesserungen aus dem aktuellen Diff heraus. Ein Prüfer sollte in der Lage sein, keine umsetzbaren Befunde zu melden, wenn die Belege diese Schlussfolgerung unterstützen.

Um eine Vorlage anzupassen, ersetzen Sie deren Platzhalter durch Angaben aus Ihrem Projekt und legen Sie fest, was Claude tun soll, bevor Sie Änderungen vornehmen. Befolgen Sie diese Schritte, um die Anfrage vorzubereiten und das Ergebnis zu überprüfen.

Bei einer kleinen, klar definierten Änderung können Sie Claude bitten, diese direkt umzusetzen. Bei unbekanntem Code, Änderungen, die mehrere Dateien betreffen, oder ungeklärten Anforderungen sollten Sie zunächst einen Plan erstellen.

Drücken Sie „Umschalt+Tab“, bis der Plan-Modus angezeigt wird, oder starten Sie Claude Code mit dem Befehl „claude --permission-mode plan“. In diesem Modus kann Claude Dateien überprüfen und schreibgeschützte Befehle ausführen, ohne Ihre Code-Bearbeitung durchzuführen. Überprüfen Sie die vorgeschlagenen Dateien, Abhängigkeiten und Tests, bevor Sie die Umsetzung genehmigen. Drücken Sie „Strg+G“, um den vorgeschlagenen Plan in Ihrem Editor zu öffnen.

Geben Sie Claude die Informationen, die zum Verständnis der Aufgabe erforderlich sind: einen Dateiverweis, ein bereinigtes Fehlerprotokoll, einen Screenshot oder ein Anforderungsdokument. Verwenden Sie „@“, gefolgt von einem Dateipfad, um den Inhalt dieser Datei einzufügen.

Wählen Sie die kleinste sinnvolle Auswahl an Quellen aus. Das Einbeziehen eines gesamten Protokolls oder Verzeichnisses kann irrelevantes Material hinzufügen und den Kontext überfrachten. Entfernen Sie Anmeldedaten und sensible Informationen, bevor Sie Protokolle freigeben, und stellen Sie sicher, dass Claude über die erforderlichen Tools verfügt, um die von Ihnen angegebenen Dokumentations-URLs abzurufen.

Beispielsweise übermittelt der Befehl „cat error.log | claude -p ‚Explain this Fehler‘“ ein Protokoll mit einer nicht-interaktiven Anfrage. Verwenden Sie ihn erst, nachdem Sie den Inhalt der Datei überprüft haben. Darin liegt der praktische Wert kontextbezogener KI: dem Modell relevante Informationen für die jeweilige Aufgabe zur Verfügung zu stellen.

Wenn Sie ein neues Feature hinzufügen, identifizieren Sie eine ähnliche Komponente oder Funktion im Repository. Teilen Sie Claude mit, welche Konventionen zu befolgen sind, beispielsweise hinsichtlich des API-Clients, der Validierungslogik, der Fehlerbehandlung oder der Teststruktur.

„Verfolgen Sie, wie @src/widgets/Weather.tsx Daten abruft und zwischenspeichert“ gibt Claude einen konkreten Anhaltspunkt. Nennen Sie außerdem alle Unterschiede, die das neue Feature erfordert, damit kein Verhalten kopiert wird, das nicht mehr passt. Diese Konventionen sollten den Softwareentwicklungs-Workflow Ihres Teams widerspiegeln.

Geben Sie bei Codeänderungen den entsprechenden Test-, Build- oder Lint-Befehl sowie das zu prüfende Verhalten an. Fordern Sie für Recherchezwecke Dateireferenzen oder Commit-IDs an. Stellen Sie bei der Arbeit an der Benutzeroberfläche ein Referenzbild sowie eine konfigurierte Methode zur Verfügung, um die Implementierung im gleichen Ansichtsbereich zu erfassen.

Bitten Sie Claude, einen Bericht über das zu erstellen, was tatsächlich geprüft wurde, einschließlich Fehlern und übersprungenen Prüfungen. Überprüfen Sie, ob die Nachweise die Anforderung abdecken; ein erfolgreicher Build bedeutet nicht, dass jedes geforderte Verhalten funktioniert.

Für umfangreichere Aufgaben bietet Claude Code außerdem eine /goal-Bedingung und Stop-Hooks. Der Zielauswerter bewertet die während der Unterhaltung zutage getretenen Hinweise, anstatt Dateien eigenständig zu überprüfen oder Tests auszuführen. Ein konfigurierter Stop-Hook kann die Fertigstellung blockieren, unterliegt jedoch Limiten hinsichtlich wiederholter Blockierungen. Beides ersetzt jedoch keine angemessenen Tests und keine Überprüfung durch Menschen.

Wenn wiederholte Korrekturen ein Problem nicht beheben, halten Sie inne und ermitteln Sie, was in der ursprünglichen Anfrage unklar geblieben ist. Speichern Sie die nützlichen Erkenntnisse, den aktuellen Git-Status und die verbleibende Arbeit, bevor Sie die Unterhaltung löschen.

Der Leitfaden für Best Practices von Anthropic empfiehlt, nach zwei erfolglosen Korrekturversuchen zum selben Problem von vorne zu beginnen. Verwenden Sie den Befehl /clear und geben Sie anschließend eine überarbeitete Eingabe an, die Ihre gewonnenen Erkenntnisse berücksichtigt. Das Löschen der Unterhaltung macht Dateiänderungen nicht rückgängig.

Drücken Sie die Esc-Taste, um eine laufende Antwort zu unterbrechen. Wenn das Eingabefeld leer ist, drücken Sie zweimal die Esc-Taste, um das Rückspulen-Menü zu öffnen und auszuwählen, was wiederhergestellt werden soll. Das Rückspulen macht nicht alle externen Auswirkungen rückgängig. Verwenden Sie daher Git-Checkpoints und separate Wiederherstellungsverfahren für Änderungen an Datenbanken oder Remote-Diensten.

Speichern Sie projektweite Richtlinien in „CLAUDE.md“, wiederholbare Abläufe in „Skills“ und Anweisungen für bestimmte Dateien in pfadbezogenen Regeln. Verwenden Sie Hooks für Aktionen, die an bestimmte Ereignisse geknüpft sind, wie beispielsweise das Ausführen eines Formatierers nach einer Bearbeitung.

Wählen Sie je nachdem aus, wann die Anweisung gelten soll:

Eine Anforderung für ein Feature gehört in der Regel in die entsprechende Aufgabe oder Spezifikation und nicht in die Datei „CLAUDE.md“. Das Hinzufügen temporärer Anweisungen zu einer projektweiten Datei erschwert es, diese von Konventionen zu unterscheiden, die im gesamten Repository gelten sollten.

Speichern Sie beispielsweise den Testbefehl des Projekts in der Datei „CLAUDE.md“, legen Sie komponentenbezogene Konventionen in einer pfadbezogenen Regel fest und speichern Sie ein wiederkehrendes Überprüfungsverfahren als „Skill“. Überprüfen Sie diese Dateien bei Änderungen an Befehlen oder Konventionen, genau wie Sie es auch bei anderer Projektdokumentation tun würden.

Prompts, CLAUDE.md und Skills steuern das Verhalten von Claude; sie garantieren jedoch nicht, dass eine Anweisung befolgt wird. Hooks können bei konfigurierten Ereignissen Prüfungen durchführen, ihre Zuverlässigkeit hängt jedoch vom Hook-Typ und der Implementierung ab.

Ein Befehlshook führt ein Skript aus. Ein Prompt- oder Agent-Hook stützt sich auf die Entscheidung eines Modells. Wie im Leitfaden zu Best Practices von Anthropic erläutert wird: „Ein Prompt- oder Agent-Hook bittet ein anderes Modell um eine Entscheidung, ist also ebenfalls nicht deterministisch.“ Verwenden Sie für eine Regel, die durchgesetzt werden muss, geeignete Berechtigungskontrollen und testen Sie den entsprechenden Befehls- oder HTTP-Hook, einschließlich der Art und Weise, wie er mit Fehlern umgeht.

Benutzerdefinierte Unteragenten sind eine weitere Möglichkeit, wiederkehrende Aufgaben zu organisieren. Definieren Sie einen Spezialisten unter „in.claude/agents/“, wenn eine eigene Überprüfungsrolle oder ein eigener Tool-Umfang erforderlich ist, anstatt jede Spezialistenanweisung zur Hauptsitzung hinzuzufügen. Diese Leitfäden zum besten Claude-Modell für die Arbeit und zu den Arten von KI-Agenten bieten zusätzlichen Kontext.

Wenn Ihr Team Prompts für mehrere KI-Produkte verwaltet, sehen Sie sich diese Prompt-Engineering-Tools an, mit denen Sie Bibliotheken über Claude Code hinaus verwalten können.

Wenn eine Sitzung ein unvollständiges oder ungeeignetes Ergebnis liefert, prüfen Sie, ob in der Anforderung wichtige Entscheidungen offen geblieben sind. Diese fünf Fehler können die Diagnose und Überprüfung der Arbeit erschweren.

„Untersuche das Repository“ gibt Claude kaum Anhaltspunkte dafür, welche Dateien relevant sind oder wann es aufhören soll. Möglicherweise erhalten Sie eine allgemeine Zusammenfassung ohne Antwort auf das Problem, das Anlass für die Anfrage war.

Benennen Sie das Verhalten oder die Entscheidung, die Sie verstehen müssen, legen Sie einen Startpunkt fest und definieren Sie die erwartete Ausgabe. Beispiel: „Verfolgen Sie nach, wie dieser Endpunkt Berechtigungen prüft, und nennen Sie die entsprechenden Funktionen.“ Wenn Sie Unteragenten einsetzen, geben Sie jedem einzelnen eine abgegrenzte Frage vor, anstatt dieselbe uneingeschränkte Suche zu delegieren.

Der Wechsel zwischen einem Feature, einem nicht damit zusammenhängenden Fehler und einer Dokumentationsanfrage führt dazu, dass die Unterhaltung einen Kontext enthält, der möglicherweise nicht auf die aktuelle Aufgabe zutrifft. Verweise wie „diese Datei“ oder „der frühere Ansatz“ werden dadurch mehrdeutig.

Verwenden Sie separate Sitzungen für nicht miteinander in Zusammenhang stehende Aufgaben. Wenn mehrere Sitzungen das Repository bearbeiten, verwenden Sie separate Git-Worktrees, damit nicht dasselbe Arbeitsverzeichnis geändert wird. Eine kurze Nebenbemerkung: Der Befehl /btw von Claude Code hält den Austausch aus dem Hauptverlauf der Unterhaltung heraus.

Ein Build kann erfolgreich sein, obwohl sich ein Feature fehlerhaft verhält. Eine Testsuite kann erfolgreich sein, weil sie die fehlerhafte Eingabe nie getestet hat. Wenn man Claude auffordert, „die Tests auszuführen“, wird dadurch nicht klar, welche Anforderung diese Tests überprüfen.

Ordnen Sie die Akzeptanzkriterien bestimmten Prüfungen zu. Fordern Sie bei einer Fehlerbehebung den Nachweis an, dass der Reproduktionstest vor der Änderung fehlgeschlagen ist und danach erfolgreich war. Behalten Sie ungetestete Kriterien im Blick, anstatt einen erfolgreichen Befehl als Überprüfung für die gesamte Änderung zu betrachten.

Eine ständig wachsende CLAUDE.md-Datei kann veraltete Befehle, doppelte Regeln und Anweisungen enthalten, die im Widerspruch zu aufgabenspezifischen Anforderungen stehen. Eine strengere Formulierung löst diese Konflikte nicht.

Überprüfen Sie die Datei anhand des aktuellen Repositorys. Entfernen Sie veraltete Anleitungen, klären Sie widersprüchliche Regeln und verschieben Sie nur in engen Anwendungsfällen gültige Anweisungen in Regeln oder Fähigkeiten, die auf den Pfad beschränkt sind. Wenn eine Anforderung durchgesetzt werden muss, konfigurieren und testen Sie die entsprechenden Kontrollen, anstatt sich auf wiederholte Erinnerungen zu verlassen.

Eine Überprüfung kann echte Fehler, unklare Probleme und optionale Refactoring-Vorschläge gleichzeitig aufzeigen. Die Umsetzung aller Vorschläge kann den Änderungsumfang vergrößern, ohne das gewünschte Verhalten zu verbessern.

Fragen Sie nach den Belegen und den Auswirkungen hinter jedem Befund. Priorisieren Sie Korrektheitsprobleme und nicht erfüllte Anforderungen, untersuchen Sie unklare Behauptungen und halten Sie nicht relevante Verbesserungen aus dem aktuellen Diff heraus. Ein Prüfer sollte in der Lage sein, keine umsetzbaren Befunde zu melden, wenn die Belege diese Schlussfolgerung unterstützen.

Um eine Vorlage anzupassen, ersetzen Sie deren Platzhalter durch Angaben aus Ihrem Projekt und legen Sie fest, was Claude zu erledigen hat, bevor Sie Änderungen vornehmen. Befolgen Sie diese Schritte, um die Anfrage vorzubereiten und das Ergebnis zu überprüfen.

Bei einer kleinen, klar definierten Änderung können Sie Claude bitten, diese direkt umzusetzen. Bei unbekanntem Code, Änderungen, die mehrere Dateien betreffen, oder ungeklärten Anforderungen sollten Sie zunächst einen Plan erstellen.

Drücken Sie „Umschalt+Tab“, bis der Plan-Modus angezeigt wird, oder starten Sie Claude Code mit dem Befehl „claude --permission-mode plan“. In diesem Modus kann Claude Dateien überprüfen und schreibgeschützte Befehle ausführen, ohne Ihre Code-Bearbeitung durchzuführen. Überprüfen Sie die vorgeschlagenen Dateien, Abhängigkeiten und Tests, bevor Sie die Umsetzung genehmigen. Drücken Sie „Strg+G“, um den vorgeschlagenen Plan in Ihrem Editor zu öffnen.

Geben Sie Claude die Informationen, die zum Verständnis der Aufgabe erforderlich sind: einen Dateiverweis, ein bereinigtes Fehlerprotokoll, einen Screenshot oder ein Anforderungsdokument. Verwenden Sie „@“, gefolgt von einem Dateipfad, um den Inhalt dieser Datei einzufügen.

Wählen Sie die kleinste sinnvolle Auswahl an Quellen aus. Das Einbeziehen eines gesamten Protokolls oder Verzeichnisses kann irrelevantes Material hinzufügen und den Kontext überfrachten. Entfernen Sie Anmeldedaten und sensible Informationen, bevor Sie Protokolle freigeben, und stellen Sie sicher, dass Claude über die erforderlichen tools verfügt, um die von Ihnen angegebenen Dokumentations-URLs abzurufen.

Beispielsweise übermittelt der Befehl „cat error.log | claude -p ‚Explain this Fehler‘“ ein Protokoll mit einer nicht-interaktiven Anfrage. Verwenden Sie ihn erst, nachdem Sie den Inhalt der Datei überprüft haben. Darin liegt der praktische Wert kontextbezogener KI: dem Modell relevante Informationen für die jeweilige Aufgabe zur Verfügung zu stellen.

Wenn Sie ein neues Feature hinzufügen, identifizieren Sie eine ähnliche Komponente oder Funktion im Repository. Teilen Sie Claude mit, welche Konventionen zu befolgen sind, beispielsweise hinsichtlich des API-Clients, der Validierungslogik, der Fehlerbehandlung oder der Teststruktur.

„Verfolgen Sie, wie @src/widgets/Weather.tsx Daten abruft und zwischenspeichert“ gibt Claude einen konkreten Anhaltspunkt. Nennen Sie außerdem alle Unterschiede, die das neue Feature erfordert, damit kein Verhalten kopiert wird, das nicht mehr passt. Diese Konventionen sollten den Softwareentwicklungs-Workflow Ihres Teams widerspiegeln.

Geben Sie bei Codeänderungen den entsprechenden Test-, Build- oder Lint-Befehl sowie das zu prüfende Verhalten an. Fordern Sie für Recherchezwecke Dateireferenzen oder Commit-IDs an. Stellen Sie bei der Arbeit an der Benutzeroberfläche ein Referenzbild sowie eine konfigurierte Methode zur Verfügung, um die Implementierung im gleichen Ansichtsbereich zu erfassen.

Bitten Sie Claude, einen Bericht über das zu erstellen, was tatsächlich geprüft wurde, einschließlich Fehlern und übersprungenen Prüfungen. Überprüfen Sie, ob die Nachweise die Anforderung abdecken; ein erfolgreicher Build bedeutet nicht, dass jedes geforderte Verhalten funktioniert.

Für umfangreichere Aufgaben bietet Claude Code außerdem eine /goal-Bedingung und Stop-Hooks. Der Zielauswerter bewertet die in der Unterhaltung zutage getretenen Hinweise, anstatt Dateien eigenständig zu überprüfen oder Tests auszuführen. Ein konfigurierter Stop-Hook kann die Fertigstellung blockieren, unterliegt jedoch Limiten hinsichtlich wiederholter Blockierungen. Beides ersetzt jedoch keine angemessenen Tests und keine Überprüfung durch Menschen.

Wenn wiederholte Korrekturen ein Problem nicht beheben, halten Sie inne und ermitteln Sie, was in der ursprünglichen Anfrage unklar geblieben ist. Speichern Sie die nützlichen Erkenntnisse, den aktuellen Git-Status und die verbleibende Arbeit, bevor Sie die Unterhaltung löschen.

Der Leitfaden für Best Practices von Anthropic empfiehlt, nach zwei erfolglosen Korrekturversuchen zum selben Problem von vorne zu beginnen. Verwenden Sie den Befehl /clear und geben Sie anschließend eine überarbeitete Eingabe an, die Ihre gewonnenen Erkenntnisse berücksichtigt. Das Löschen der Unterhaltung macht Dateiänderungen nicht rückgängig.

Drücken Sie die Esc-Taste, um eine laufende Antwort zu unterbrechen. Wenn das Eingabefeld leer ist, drücken Sie zweimal die Esc-Taste, um das Rückspulmenü zu öffnen und auszuwählen, was wiederhergestellt werden soll. Das Zurückspulen macht nicht alle externen Auswirkungen rückgängig. Verwenden Sie daher Git-Checkpoints und separate Wiederherstellungsverfahren für Änderungen an Datenbanken oder Remote-Diensten.

Speichern Sie projektweite Richtlinien in „CLAUDE.md“, wiederholbare Abläufe in „Skills“ und Anweisungen für bestimmte Dateien in pfadbezogenen Regeln. Verwenden Sie Hooks für Aktionen, die an bestimmte Ereignisse geknüpft sind, wie beispielsweise das Ausführen eines Formatierers nach einer Bearbeitung.

Wählen Sie je nachdem aus, wann die Anweisung gelten soll:

Eine Anforderung für ein Feature gehört in der Regel in die entsprechende Aufgabe oder Spezifikation und nicht in die Datei „CLAUDE.md“. Das Hinzufügen temporärer Anweisungen zu einer projektweiten Datei erschwert es, diese von Konventionen zu unterscheiden, die im gesamten Repository gelten sollten.

Speichern Sie beispielsweise den Testbefehl des Projekts in der Datei „CLAUDE.md“, legen Sie komponentenbezogene Konventionen in einer pfadbezogenen Regel fest und speichern Sie ein wiederkehrendes Überprüfungsverfahren als „Skill“. Überprüfen Sie diese Dateien bei Änderungen an Befehlen oder Konventionen, genau wie Sie es auch bei anderer Projektdokumentation tun würden.

Prompts, CLAUDE.md und Skills steuern das Verhalten von Claude; sie garantieren jedoch nicht, dass eine Anweisung befolgt wird. Hooks können bei konfigurierten Ereignissen Prüfungen durchführen, ihre Zuverlässigkeit hängt jedoch vom Hook-Typ und der Implementierung ab.

Ein Befehlshook führt ein Skript aus. Ein Prompt- oder Agent-Hook stützt sich auf die Entscheidung eines Modells. Wie im Leitfaden zu Best Practices von Anthropic erläutert wird: „Ein Prompt- oder Agent-Hook bittet ein anderes Modell um eine Entscheidung, ist also ebenfalls nicht deterministisch.“ Verwenden Sie für eine Regel, die durchgesetzt werden muss, geeignete Berechtigungskontrollen und testen Sie den entsprechenden Befehls- oder HTTP-Hook, einschließlich der Art und Weise, wie er mit Fehlern umgeht.

Benutzerdefinierte Unteragenten sind eine weitere Möglichkeit, wiederkehrende Aufgaben zu organisieren. Definieren Sie einen Spezialisten unter „in.claude/agents/“, wenn eine spezifische Überprüfungsrolle oder ein bestimmter Tool-Umfang erforderlich ist, anstatt jede Spezialistenanweisung zur Hauptsitzung hinzuzufügen. Diese Leitfäden zum besten Claude-Modell für die Arbeit und zu den Arten von KI-Agenten bieten zusätzlichen Kontext.

Wenn Ihr Team Prompts für mehrere KI-Produkte verwaltet, sehen Sie sich diese Prompt-Engineering-Tools an, mit denen Sie Bibliotheken über Claude Code hinaus verwalten können.

Wenn eine Sitzung ein unvollständiges oder ungeeignetes Ergebnis liefert, prüfen Sie, ob in der Anforderung wichtige Entscheidungen offen geblieben sind. Diese fünf Fehler können die Diagnose und Überprüfung der Arbeit erschweren.

„Untersuche das Repository“ gibt Claude kaum Anhaltspunkte dafür, welche Dateien relevant sind oder wann es aufhören soll. Möglicherweise erhalten Sie eine allgemeine Zusammenfassung ohne Antwort auf das Problem, das Anlass für die Anfrage war.

Benennen Sie das Verhalten oder die Entscheidung, die Sie verstehen müssen, legen Sie einen Startpunkt fest und definieren Sie die erwartete Ausgabe. Beispiel: „Verfolgen Sie nach, wie dieser Endpunkt Berechtigungen überprüft, und nennen Sie die entsprechenden Funktionen.“ Wenn Sie Unteragenten einsetzen, geben Sie jedem einzelnen eine abgegrenzte Frage vor, anstatt dieselbe uneingeschränkte Suche zu delegieren.

Der Wechsel zwischen einem Feature, einem nicht damit zusammenhängenden Fehler und einer Dokumentationsanfrage führt dazu, dass die Unterhaltung einen Kontext enthält, der möglicherweise nicht auf die aktuelle Aufgabe zutrifft. Verweise wie „diese Datei“ oder „der frühere Ansatz“ werden dadurch mehrdeutig.

Verwenden Sie separate Sitzungen für nicht miteinander in Zusammenhang stehende Aufgaben. Wenn mehrere Sitzungen das Repository bearbeiten, verwenden Sie separate Git-Worktrees, damit nicht dasselbe Arbeitsverzeichnis geändert wird. Eine kurze Nebenbemerkung: Der Befehl /btw von Claude Code hält den Austausch aus dem Hauptverlauf der Unterhaltung heraus.

Ein Build kann erfolgreich sein, obwohl sich ein Feature falsch verhält. Eine Testsuite kann erfolgreich sein, weil sie die fehlerhafte Eingabe nie getestet hat. Wenn man Claude auffordert, „die Tests auszuführen“, wird dadurch nicht festgestellt, welche Anforderung diese Tests überprüfen.

Ordnen Sie die Akzeptanzkriterien bestimmten Prüfungen zu. Fordern Sie bei einer Fehlerbehebung den Nachweis an, dass der Reproduktionstest vor der Änderung fehlgeschlagen ist und danach erfolgreich war. Behalten Sie ungetestete Kriterien im Blick, anstatt einen erfolgreichen Befehl als Überprüfung für die gesamte Änderung zu betrachten.

Eine ständig wachsende CLAUDE.md-Datei kann veraltete Befehle, doppelte Regeln und Anweisungen enthalten, die im Widerspruch zu aufgabenspezifischen Anforderungen stehen. Eine strengere Formulierung löst diese Konflikte nicht.

Überprüfen Sie die Datei anhand des aktuellen Repositorys. Entfernen Sie veraltete Anleitungen, klären Sie widersprüchliche Regeln und verschieben Sie nur in engen Anwendungsfällen gültige Anweisungen in Regeln oder Fähigkeiten, die auf den Pfad beschränkt sind. Wenn eine Anforderung durchgesetzt werden muss, konfigurieren und testen Sie die entsprechenden Kontrollen, anstatt sich auf wiederholte Erinnerungen zu verlassen.

Eine Überprüfung kann echte Fehler, unklare Probleme und optionale Refactoring-Vorschläge gleichzeitig aufzeigen. Die Umsetzung aller Vorschläge kann den Änderungsumfang vergrößern, ohne das gewünschte Verhalten zu verbessern.

Fragen Sie nach den Belegen und den Auswirkungen hinter jedem Befund. Priorisieren Sie Korrektheitsprobleme und nicht erfüllte Anforderungen, untersuchen Sie unklare Behauptungen und halten Sie nicht relevante Verbesserungen aus dem aktuellen Diff heraus. Ein Prüfer sollte in der Lage sein, keine umsetzbaren Befunde zu melden, wenn die Belege diese Schlussfolgerung unterstützen.