Prompt-Bibliothek

Wenn du bestehenden Code umbauen willst, ohne das Verhalten zu verändern.

Refactor <DATEI/MODUL>, um <ZIEL, z.B. Lesbarkeit/Struktur> zu verbessern.
Regeln:
- Ändere NICHT das äußere Verhalten (Input/Output, API, Seiteneffekte bleiben identisch)
- Arbeite in kleinen, einzeln nachvollziehbaren Schritten
- Führe nach jedem Schritt die Tests aus (<TESTBEFEHL>) und zeig mir das Ergebnis
- Stopp und frag nach, falls ein Schritt das Verhalten verändern würde
Fasse am Ende alle Schritte und die Testergebnisse als Beleg zusammen.

💡 Halte die Diffs klein — ein Review pro Schritt ist einfacher als ein Review für alles auf einmal.

Claude Code: Best practices ↗

Wenn eine Funktion/Methode zu groß oder verschachtelt ist und du einen Teil sauber auslagern willst.

In <DATEI>, Funktion <FUNKTIONSNAME>: Extrahiere den Codeblock, der <BESCHREIBUNG DES TEILS> macht, in eine eigene, klar benannte Funktion.
- Verhalten muss exakt gleich bleiben (gleiche Inputs -> gleiche Outputs, gleiche Fehlerfälle)
- Folge den bestehenden Namens-/Stil-Konventionen der Datei
- Falls kein Test existiert: schreib zuerst einen Test, der das aktuelle Verhalten absichert, dann refactore
- Führe die Tests danach aus und zeig mir das Ergebnis
Erklär kurz, warum die neue Struktur klarer ist.

💡 Kein Test vorhanden? Erst einen Characterization-Test schreiben (siehe Testing-Vorlagen), dann refactoren.

Claude Code: Best practices ↗

Wenn du eine Library, ein Pattern oder eine API-Version über mehrere Dateien hinweg migrierst.

Migriere <ALT-PATTERN/LIBRARY> zu <NEU-PATTERN/LIBRARY> in <SCOPE, z.B. Ordner/Modul>.
- Liste zuerst ALLE betroffenen Dateien auf, bevor du etwas änderst
- Migriere eine Datei nach der anderen (voneinander abhängige Dateien als kleine Gruppe), zeig jede Änderung einzeln
- Führe nach jeder Datei die Tests/den Build aus (<TESTBEFEHL>) und zeig das Ergebnis
- Bei Unsicherheit (z.B. unklares altes Verhalten): stoppen und fragen statt zu raten
Am Ende: Liste der migrierten Dateien plus verbleibende offene Fälle.

💡 Bei sehr vielen Dateien: erst an 2-3 testen, Prompt verfeinern, dann auf den Rest anwenden.

Claude Code: Best practices ↗ · Anthropic: Building Effective Agents ↗

Wenn ein Bug auftritt und die Ursache nicht offensichtlich ist.

Bug: <FEHLERBESCHREIBUNG / FEHLERMELDUNG>
Vermutlicher Bereich: <DATEI/MODUL, falls bekannt>
Geh so vor:
1. Formuliere 2-3 konkrete Hypothesen, was die Ursache sein könnte
2. Prüfe jede Hypothese gezielt (Code lesen, Logs, kleiner Test) — nicht raten
3. Schreib einen Test, der den Bug reproduziert, BEVOR du fixt
4. Behebe die Root Cause, nicht nur das Symptom (keine try/catch-Unterdrückung)
5. Zeig den Test vorher fehlschlagend und nachher grün
Stopp und frag nach, wenn keine Hypothese den Bug erklärt.

💡 "Root cause, not symptom" — nicht einfach den Fehler wegfangen, sondern die Ursache beheben.

Claude Code: Best practices ↗

Wenn ein Test manchmal fehlschlägt und du die Ursache (Timing, Reihenfolge, State) finden willst.

Test <TESTNAME/DATEI> ist flaky (schlägt gelegentlich fehl).
- Führe den Test <N, z.B. 20> mal isoliert aus (<TESTBEFEHL>) und notiere Erfolg/Fehlschlag
- Prüfe typische Ursachen: geteilter State zwischen Tests, Race Conditions, Zeit-/Reihenfolge-Abhängigkeit, ungemockte externe Calls
- Formuliere eine Hypothese zur Ursache und belege sie mit einem gezielten Reproduktions-Test
- Schlage einen Fix vor, der die Ursache behebt (nicht nur Retry/Skip)
- Nach dem Fix: Test mehrfach erneut laufen lassen, Ergebnis zeigen
Falls keine klare Ursache gefunden wird: fass zusammen, was ausgeschlossen wurde und was als Nächstes zu prüfen wäre.

💡 Retry-Logik oder @skip ist kein Fix — nur ein Pflaster, das der Prompt bewusst ausschließt.

Claude Code: Best practices ↗

Wenn ein Nutzer/Report einen Bug meldet, du aber noch keinen sicheren Reproduktionsweg hast.

Gemeldeter Bug: <BESCHREIBUNG, z.B. aus Ticket/Support>
Erwartetes Verhalten: <WAS SOLLTE PASSIEREN>
Tatsächliches Verhalten: <WAS PASSIERT STATTDESSEN>
1. Finde den relevanten Code-Pfad (Startpunkt: <RELEVANTER BEREICH, z.B. src/auth/>)
2. Schreib einen fehlschlagenden Test, der den Bug exakt reproduziert
3. Zeig mir den fehlschlagenden Test, BEVOR du den Fix schreibst — ich bestätige, dass das der richtige Bug ist
Falls du den Bug nicht reproduzieren kannst: stopp und berichte, was du geprüft und ausgeschlossen hast.
4. Erst danach: Fix implementieren, der neue Test muss grün werden, die gesamte Testsuite muss weiter grün bleiben

💡 Der Bestätigungs-Stopp vor dem Fix verhindert, dass der falsche Bug behoben wird.

Claude Code: Best practices ↗

Bevor du eine Änderung als fertig markierst — lass eine frische Instanz kritisch draufschauen.

Nutze einen Subagent/eine frische Session, um den Diff von <SCOPE, z.B. PR/Branch/Datei> gegen <PLAN/ANFORDERUNG, z.B. PLAN.md oder Ticket-Beschreibung> zu prüfen.
Der Reviewer bekommt NUR den Diff und die Anforderung — nicht die Begründung, warum die Änderung so gebaut wurde.
Prüfe:
- Ist jede Anforderung tatsächlich umgesetzt?
- Gibt es Edge Cases aus der Anforderung ohne Test?
- Wurde etwas außerhalb des Scopes verändert?
Melde nur Lücken, die Korrektheit oder Anforderungen betreffen — keine reinen Stilpräferenzen.

💡 Ein Reviewer, der gezielt nach Lücken sucht, findet fast immer welche — jage nicht jeden Fund, nur die mit echter Korrektheits-Relevanz.

Claude Code: Best practices ↗

Wenn du einen Pull Request/Diff strukturiert reviewen willst statt mit einer langen unsortierten Liste.

Review den Diff in <SCOPE, z.B. PR #123 / Branch-Name>.
Sortiere jeden Fund in genau eine Stufe:
- CRITICAL: Bug, Sicherheitslücke oder Datenverlust-Risiko
- MAJOR: falsches Verhalten in einem realistischen Fall, fehlende Fehlerbehandlung
- MINOR: Stil, Naming, kleine Verbesserungen
Für jeden Fund: Datei:Zeile, was ist das Problem, konkreter Fix-Vorschlag.
Keine allgemeinen Lob-Kommentare. Wenn nichts gefunden wird, sag das explizit statt Findings zu erfinden.

💡 Explizite Stufen verhindern, dass ein Nitpick genauso viel Gewicht bekommt wie ein echter Bug.

Claude Code: Best practices ↗

Nach der Implementierung einer geplanten Aufgabe — prüfen, ob wirklich alles aus dem Plan umgesetzt wurde.

Vergleiche die aktuelle Implementierung in <SCOPE> mit dem Plan in <PLAN-QUELLE, z.B. PLAN.md oder Ticket>.
Erstelle eine Checkliste aus dem Plan und geh sie Punkt für Punkt durch:
- Umgesetzt und getestet
- Umgesetzt, aber ohne Test
- Nicht umgesetzt
- Zusätzlich gemacht (nicht im Plan, aber im Diff)
Belege jeden Punkt mit Datei-/Zeilenverweis oder Testergebnis, keine Vermutungen.

💡 Nutze das als Stopp-Kriterium — erst wenn alle Punkte 'umgesetzt und getestet' sind, gilt die Aufgabe als fertig.

Claude Code: Best practices ↗

Bei Aufgaben, die mehrere Dateien betreffen, einen unklaren Ansatz haben, oder wenn dir das Modul unbekannt ist.

Bevor du irgendetwas änderst: Lies <RELEVANTER BEREICH, z.B. src/auth/> und verstehe, wie <THEMA, z.B. Login/Sessions> aktuell funktioniert.
Erstelle danach einen Plan für <ZIEL/FEATURE>:
- Welche Dateien müssen sich ändern?
- Welche Reihenfolge der Schritte ergibt Sinn?
- Welche Edge Cases/Risiken siehst du?
- Wie wird am Ende verifiziert (welche Tests/Checks)?
Zeig mir den Plan zuerst. Fang erst mit dem Code an, nachdem ich den Plan bestätigt habe.

💡 Für kleine, offensichtliche Änderungen (Tippfehler, eine Zeile) lohnt sich der Plan-Schritt nicht — direkt umsetzen lassen.

Claude Code: Best practices ↗

Wenn ein Feature zu groß für einen Durchgang ist und in überprüfbare Stücke zerlegt werden soll.

Ich will <FEATURE-BESCHREIBUNG> bauen.
Zerlege das Feature in einzelne Etappen, wobei jede Etappe:
- für sich lauffähig/testbar ist (kein halb-kaputter Zwischenzustand)
- eine klare Verifikation hat (Test, Build, manueller Check)
Liste die Etappen in Reihenfolge mit jeweils 1-2 Sätzen Beschreibung.
Setze NUR Etappe 1 um, führe die Verifikation aus und zeig mir das Ergebnis, bevor du zur nächsten Etappe gehst.

💡 So bleibt jede Etappe reviewbar, statt am Ende einen riesigen Diff zu bekommen.

Claude Code: Best practices ↗ · Anthropic: Building Effective Agents ↗

Bei größeren/neuen Features, wo du selbst noch nicht alle Details durchdacht hast.

Ich will <KURZE FEATURE-IDEE> bauen. Interview mich im Detail dazu, bevor irgendetwas gebaut wird.
Frag nach technischer Umsetzung, UX, Edge Cases, Tradeoffs — keine offensichtlichen Fragen, sondern die schwierigen Punkte, die ich vielleicht übersehen habe.
Frag so lange weiter, bis alles Wichtige geklärt ist.
Schreib danach eine vollständige Spec (Dateien/Schnittstellen, was explizit NICHT im Scope ist, Verifikationsschritt am Ende) nach <SPEC-DATEI, z.B. SPEC.md>.

💡 Starte für die eigentliche Umsetzung eine neue, saubere Session mit der fertigen Spec als Kontext.

Claude Code: Best practices ↗

Wenn du unbekannten/ungetesteten Legacy-Code anfassen musst und erst das aktuelle Verhalten absichern willst.

Datei/Modul <DATEI/MODUL> hat aktuell keine (ausreichenden) Tests und ich muss es bald ändern.
Schreib zuerst Characterization-Tests: Tests, die das AKTUELLE Verhalten dokumentieren und absichern — inklusive Kanten- und Fehlerfällen, auch wenn das Verhalten seltsam wirkt.
- Keine Verhaltensänderung am Code selbst in diesem Schritt
- Führe die Tests aus und zeig, dass sie grün sind
- Liste kurz auf, welches Verhalten überraschend/fragwürdig war (für spätere Klärung)

💡 Diese Tests sind dein Sicherheitsnetz für den nächsten Refactoring-Schritt — nicht löschen, auch wenn das Verhalten später bewusst geändert wird.

Claude Code: Best practices ↗

Wenn du einen konkreten Bug fixt und sicherstellen willst, dass er nicht wiederkommt.

Bug: <BESCHREIBUNG/FEHLERMELDUNG> in <DATEI/MODUL>
1. Schreib zuerst einen Test, der aktuell fehlschlägt und genau diesen Bug reproduziert
2. Zeig mir den fehlschlagenden Test
3. Implementiere erst danach den Fix
4. Der neue Test muss grün werden, alle bestehenden Tests müssen grün bleiben
Beispiel-Fälle, die der Test abdecken soll: <TESTFÄLLE, z.B. Eingabe X ergibt Y>

💡 Der Test bleibt nach dem Fix im Repo — er verhindert, dass derselbe Bug still zurückkommt (Regression).

Claude Code: Best practices ↗

Beim Einstieg in eine neue/unbekannte Codebase oder ein unbekanntes Modul.

Gib mir einen Überblick über <SCOPE, z.B. dieses Repo / den Ordner src/payments> auf 3 Ebenen:
1. Big Picture: Was macht das System, welche Hauptbausteine gibt es (1 Absatz + Liste)
2. Struktur: Wichtigste Ordner/Module und ihre Verantwortung
3. Details: Für <SPEZIFISCHER TEIL, z.B. den Request-Flow einer Anfrage>: Schritt für Schritt, welche Dateien/Funktionen beteiligt sind
Nutze nur, was im Code tatsächlich zu finden ist, keine Vermutungen — wo etwas unklar ist, sag das explizit.

💡 Frag danach gezielt nach, statt gleich alles auf einmal zu verlangen — hält den Kontext klein.

Claude Code: Best practices ↗

Wenn du verstehen willst, woher Daten kommen und wohin sie in einem bestimmten Ablauf fließen.

Zeichne den Datenfluss von <STARTPUNKT, z.B. Funktion/Endpoint X> nach.
- Woher kommen die Eingabedaten (Aufrufer, Request, DB, etc.)?
- Welche Funktionen/Module verarbeiten die Daten in welcher Reihenfolge?
- Wo wird der Zustand verändert (State, DB-Writes, Seiteneffekte)?
- Wo endet der Fluss (Response, Speicherung, Weitergabe)?
Stell das als nummerierte Schritt-für-Schritt-Liste mit Datei:Zeile-Verweisen dar. Wenn ein Schritt unklar/mehrdeutig ist, markiere das statt zu raten.

💡 Bei komplexeren Flüssen lass dir das zusätzlich als kurzes Mermaid-Diagramm zeigen.

Claude Code: Best practices ↗