So erzielst du bessere Ergebnisse mit Claude Code

Du erzielst bessere Ergebnisse mit Claude Code, wenn du jede Anfrage wie ein Engineering-Briefing behandelst: Gib den relevanten Kontext, bitte ihn, vor Codeänderungen zu prüfen, grenze die Lösung ein und verlange Belege dafür, dass das Ergebnis funktioniert. Derselbe Ansatz verbessert Bugfixes, Refactorings, Tests und Dokumentation.

Die aktuelle Dokumentation von Claude Code enthält Workflows zum Erkunden von Codebases, Debuggen, Refaktorieren, Testen und Planen vor Änderungen. Nutze diese Fähigkeiten, um Unsicherheit zu reduzieren, nicht um die Begründung zu überspringen, die ein Teammitglied benötigen würde.

„Ersetze diesen Hook durch einen globalen Store“ ist ein implementierungsorientierter Prompt. Er legt eine Lösung fest, bevor der Assistent Zuständigkeit und Fehlermodus untersucht hat.

Beginne so:

Problem: Ein Indikator für den Abschluss einer Lektion verschwindet nach dem Navigieren
manchmal.

Beobachtet: Das Abschlussereignis wird aufgezeichnet, aber der nächste Bildschirm startet
ohne den Feierzustand.
Erwartet: Ein Abschlussereignis bleibt über die anschließende Navigation hinweg verfügbar
und wird dann an der passenden Grenze gelöscht.

Umfang: Prüfe den Lektions-Store, den Handler für den Abschluss und den Übergang zum
nächsten Bildschirm. Ändere keinen nicht zusammenhängenden Code zum Fortschritt im Dashboard.

Verfolge vor der Bearbeitung das Ereignis vom Schreiben bis zum Rendern. Nenne den aktuellen
Besitzer des Flags, die wahrscheinlichen Rücksetzpunkte und die Belege für jede Hypothese.

Die Anfrage verlangt ein Modell des bestehenden Verhaltens, bevor sie nach einer Änderung fragt.

Füge bei einer fokussierten Aufgabe Folgendes hinzu:

• den fehlschlagenden Befehl, Test, Screenshot oder Fehler;
• die Dateien oder das Subsystem, die zuerst geprüft werden sollen;
• relevante Projektregeln oder Architektureinschränkungen;
• kürzliche Änderungen, die die Regression eingeführt haben könnten;
• Verhalten, das unverändert bleiben muss.

Kopiere nicht ein ganzes Repository in den Prompt. Falls mehr Kontext nötig wird, bitte den Assistenten, die nächste Datei oder Grenze zu benennen, die er braucht, und zu erklären, warum.

Bitte bei Arbeit mit nicht offensichtlichem Risiko vor der Implementierung um eine schreibgeschützte Analyse:

Prüfe den aktuellen Ablauf zur Abo-Sperre und beantworte diese Fragen vor der Bearbeitung:

1. Wo wird der Zugriff entschieden?
2. Welcher Ladezustand verhindert eine vorzeitige Umleitung?
3. Welche Route und CTA-Aufrufstellen nutzen die Entscheidung?
4. Welcher Regressionstest würde beweisen, dass ein zahlender Nutzer nicht zur Preisseite
   gesendet wird?

Schreibe noch keinen Code. Trenne beobachtetes Verhalten von Annahmen.

Ein Analyse-Checkpoint ist bei Berechtigungen, Zahlungen, Datenmigrationen, Navigation und gemeinsamem Zustand wertvoll. Er gibt dir außerdem ein kleines Dokument zur Überprüfung, bevor ein großer Diff entsteht.

Der Assistent kann nicht jeden Vertrag zuverlässig aus dem umgebenden Code ableiten. Nenne die wichtigen:

Einschränkungen:
- halte die Anwendung mit statischem Export kompatibel;
- bewahre die aktive Locale bei interner Navigation;
- füge kein reines Serverlaufzeitverhalten hinzu;
- behalte den bestehenden Client Writer als einzige Quelle der Wahrheit;
- ändere keine öffentlichen Routen- oder Ereignisnamen;
- erweitere die Änderung nicht über dieses Feature hinaus, ohne zu erklären, warum.

Konkrete Einschränkungen machen Reviews präziser, weil sich eine vorgeschlagene Änderung mit einer schriftlichen Grenze vergleichen lässt.

Teile ein riskantes Refactoring in kleine, testbare Schritte auf:

Schritt 1: Ermittle den duplizierten Zustandsübergang und erkläre die aktuellen Tests.
Schritt 2: Extrahiere nur den gemeinsamen Übergang hinter derselben öffentlichen API.
Schritt 3: Führe die fokussierten Tests aus und zeige das geänderte Verhalten.
Schritt 4: Schlage eine umfassendere Bereinigung vor, implementiere sie aber nicht.

Schrittweise Arbeit schützt dich vor einem Patch, der Rendering, Zuständigkeit für Zustand und Tests gleichzeitig ändert. Falls Schritt 2 scheitert, lässt sich die Ursache leichter isolieren.

Nutze eine Belegkette:

Belege: [Logs, Stack Trace, fehlschlagender Test, Befehlsausgabe oder Nutzerschritte]
Hypothesen: Liste die kleinsten plausiblen Ursachen in Prioritätsreihenfolge auf.
Überprüfung: Nenne die Beobachtung, die jede Ursache bestätigen oder ausschließen würde.
Korrektur: Schlage die kleinste durch die Belege gestützte Änderung vor.
Validierung: Füge einen Regressionstest und bei Bedarf eine manuelle Prüfung hinzu.

Bitte einen Assistenten nicht, Produktionsverhalten anhand eines vagen Symptoms zu patchen. Eine selbstsicher wirkende Korrektur ist kein Beleg.

Akzeptanzkriterien:
- der gemeldete Fehler wird durch einen fokussierten Regressionstest abgedeckt;
- der erfolgreiche bestehende Workflow besteht weiterhin;
- Typprüfung und der relevante Testbefehl bestehen;
- der Diff bleibt innerhalb des vereinbarten Umfangs;
- die abschließende Erklärung benennt Verhalten, das nicht lokal überprüft werden konnte.

Das hilft Claude Code, an einem überprüfbaren Endpunkt zu stoppen, statt Kompilierung als einziges Korrektheitssignal zu behandeln.

Für den breiteren Prompt-Rahmen beginne mit wie man bessere KI-Prompts schreibt. Für aufgabenorientierte Muster nutze Prompt Engineering für Entwickler und die Prompt-Vorlagen zum Debuggen von Produktionsproblemen.

Wenn die Aufgabe ein Skript oder einen befehlsbasierten Workflow ändert, reproduziere die relevante Eingabe und Ausgabe, bevor du nach einer Korrektur fragst. Übe Terminal-Workflows im Browser, um die Validierung konkret zu machen.