Claude Code Masterkurs – KI-gestuetztes Programmieren lernen mit Anthropics Coding-Agent

Advanced Prompting Techniques

Level 3 | 45 Minuten

Kommunikations-Patterns, Task-Templates und fortgeschrittene Prompting-Strategien für Claude Code

Lernziele

Die Psychologie des Promptings

Effektives Prompting ist keine Geheimwissenschaft — es ist angewandte Kommunikationspsychologie. Claude Code ist ein extrem leistungsfähiges Werkzeug, aber wie jedes Werkzeug produziert es nur dann gute Ergebnisse wenn der Bediener weiß was er tut. Die Art wie du Prompts formulierst, bestimmt direkt die Qualität der Antworten. Das wichtigste Prinzip: Claude ist kein Gedankenleser. Es arbeitet ausschließlich mit den Informationen die du ihm gibst — dem sogenannten Kontext. Wenn du sagst 'Fix den Bug', muss Claude raten welchen Bug du meinst, in welcher Datei, und was das erwartete Verhalten sein sollte. Wenn du sagst 'In src/auth/login.ts gibt der Login-Handler für deaktivierte Accounts einen 200-Status statt 403 zurück. Fixe das und stelle sicher dass ein beschreibender Fehlertext zurückgegeben wird', hat Claude alles was es braucht. Das zweite Prinzip: Positive Anweisungen sind besser als negative. 'Schreibe keine langen Funktionen' ist weniger hilfreich als 'Halte Funktionen unter 30 Zeilen und extrahiere komplexe Logik in separate Hilfsfunktionen'. Claude reagiert besser auf klare Vorgaben als auf Verbote. Das dritte Prinzip: Kontext vor Aufgabe. Gib Claude erst den Rahmen, dann die Aufgabe. 'Wir arbeiten an einer B2B SaaS App für Rechnungsverarbeitung mit React und PostgreSQL. Die User sind Buchhalter die keine technischen Kenntnisse haben. Implementiere eine Filterfunktion für die Rechnungsliste.' Dieser Kontext verändert wie Claude die Aufgabe angeht — von der UI-Gestaltung bis zur Fehlerbehandlung. Das vierte Prinzip: Ein Task pro Prompt. Claude arbeitet fokussierter und liefert bessere Ergebnisse wenn es einen klar definierten Auftrag hat. Statt drei Aufgaben gleichzeitig, lieber drei separate Prompts nacheinander. Die Ergebnisse sind konsistent besser. Diese Prinzipien gelten universell — für einfache Fragen genauso wie für komplexe Implementierungsaufgaben.

💡 Goldene Regel Kontext schlägt Cleverness. Statt einen "schlauen" Prompt zu schreiben, liefere Claude ALLE Informationen die es braucht: Was existiert, was du willst, warum du es willst, und welche Constraints gelten. Ein einfacher Prompt mit reichem Kontext schlägt immer einen cleveren Prompt ohne Kontext.

Kommunikations-Patterns etablieren

Kommunikations-Patterns sind vordefinierte Interaktionsmodi die du mit Claude vereinbarst. Statt bei jedem Prompt aufs Neue zu erklären welche Art von Antwort du erwartest, etablierst du feste Modes die du per Schlüsselwort aktivierst. Stell dir vor, du hast zwei Modi bei der Arbeit: Im 'Brainstorming-Modus' wirfst du Ideen an die Wand, experimentierst, und Qualität ist erstmal egal. Im 'Produktions-Modus' arbeitest du sorgfältig, prüfst jeden Schritt, und alles muss perfekt sein. Genau diese Modi definierst du für Claude. Das Quick-and-Dirty Pattern: 'Wenn ich sage quick-fix: Implementiere den schnellsten Weg zum Ziel. Keine Tests, keine Error-Handling, keine Doku. Nutze Shortcuts und Hacks. Ich will einen funktionierenden Prototypen in unter 5 Minuten.' Das Production-Ready Pattern: 'Wenn ich sage production: Implementiere mit vollständiger Fehlerbehandlung, Input-Validierung, Logging, Unit + Integration Tests und JSDoc-Kommentaren. Jeder Edge Case muss behandelt werden.' Das Teach-Me Pattern: 'Wenn ich sage explain: Erkläre jeden Schritt ausführlich. Zeige Alternativen mit Vor- und Nachteilen. Ich will lernen, nicht nur Code haben.' Das Autonomous Pattern: 'Wenn ich sage auto: Triff eigenständig Entscheidungen. Dokumentiere Annahmen als Kommentare. Frage nur bei irreversiblen Architektur-Änderungen nach.' Diese Patterns gehören in die CLAUDE.md damit sie bei JEDER Session aktiv sind. Du wechselst dann per Schlüsselwort: 'production: Implementiere die Payment-Validierung' oder 'quick-fix: Beheb den Null-Pointer in line 42'. Der Vorteil: Konsistenz und Effizienz. Statt 30 Wörter pro Prompt für den Qualitätsgrad zu verschwenden, sagst du ein Wort. Das spart Tokens und verhindert Missverständnisse.

KOMMUNIKATIONS-MODI — Was sie für Claude bedeuten
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

"quick and dirty" / "schnell und pragmatisch"
→ Kein Error Handling nötig
→ Keine Tests
→ Einfachste Lösung die funktioniert
→ console.log statt Logger
→ Hardcoded Werte OK

"production-ready" / "für Production"
→ Vollständiges Error Handling (Result-Pattern)
→ Input Validation (Zod/Joi)
→ Unit Tests für Business Logic
→ Logging statt console.log
→ Environment Variables statt Hardcoded Werte
→ Security Headers, Rate Limiting

"analysiere erst" / "noch nicht implementieren"
→ Claude analysiert und zeigt Optionen
→ Keine Code-Änderungen
→ Pro/Con-Liste für Alternativen
→ Wartet auf deine Entscheidung

"wie in [datei]" / "folge dem Pattern in..."
→ Claude orientiert sich am bestehenden Code
→ Naming, Style, Patterns werden übernommen
→ Konsistenz mit Bestehendem
💡 In der CLAUDE.md festhalten Du kannst deine bevorzugte Arbeitsweise dauerhaft definieren: ## Für Claude - Bei unklaren Anforderungen: NACHFRAGEN statt Annahmen treffen - Bei Architektur-Entscheidungen: Pro/Con-Liste zeigen - Bei Code-Änderungen: Erklären WARUM, nicht nur WAS - Standard-Modus: production-ready (außer ich sage "quick and dirty") - TODO-Comments im Code bedeuten: Bitte implementiere das - Bevorzuge kleine, fokussierte PRs statt einer großen Änderung

Deep Thinking Levels

Claude Code bietet vier Stufen der Analyse-Tiefe, die unterschiedlich viele Tokens für das interne Reasoning investieren. Die Wahl der richtigen Stufe ist einer der wichtigsten Hebel für die Qualität deiner Ergebnisse — und gleichzeitig für die Kosten. Die Basis-Stufe (Standard) aktiviert kein erweitertes Reasoning. Claude liest deinen Prompt und antwortet direkt. Perfekt für einfache Aufgaben: eine Funktion erklären, einen kleinen Bug fixen, eine Konfiguration ändern. Schnell und günstig. Die 'think' Stufe reserviert ein moderates Token-Budget für internes Nachdenken. Claude erstellt vor der Antwort eine interne Analyse: Was ist das Problem? Welche Ansätze gibt es? Was sind die Trade-offs? Das verbessert die Qualität bei mittelkomplexen Aufgaben deutlich — zum Beispiel beim Design einer neuen API oder beim Refactoring eines Moduls. Die 'think hard' Stufe investiert deutlich mehr Tokens ins Reasoning. Claude durchdenkt das Problem aus mehreren Perspektiven, wägt Alternativen ab, und berücksichtigt Edge Cases. Ideal für komplexe Architekturentscheidungen, Performance-Optimierung oder Multi-Datei-Refactorings. Die 'ultrathink' Stufe nutzt das Maximum an Reasoning-Tokens. Claude führt eine tiefgreifende, mehrstufige Analyse durch — fast wie ein menschlicher Experte der sich einen Tag lang mit dem Problem beschäftigt. Reserviere diese Stufe für wirklich schwierige Probleme: System-Design, komplexe Algorithmen, kritische Security-Entscheidungen. Die Faustregel für die Wahl: Je komplexer und folgenreicher die Aufgabe, desto höher die Stufe. Ein Tippfehler braucht kein ultrathink. Eine Datenbankschema-Migration die alle Services betrifft, braucht es sehr wohl. Kostenimpact: Jede Stufe verbraucht mehr Tokens. Standard kostet fast nichts extra, ultrathink kann mehrere Dollar pro Anfrage kosten. Investiere das Budget dort wo es den größten Qualitätsunterschied macht.

THINKING LEVELS IN CLAUDE CODE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Level 1: STANDARD
"Implementiere Rate Limiting"
→ Schnelle Antwort, gut für einfache Tasks

Level 2: THINK
"think about how to implement rate limiting"
→ ~1.000 Tokens für Reasoning
→ Gut für mittlere Probleme

Level 3: THINK HARD
"think hard about the microservices architecture"
→ ~5.000 Tokens für Reasoning
→ Ideal für komplexe Architektur-Entscheidungen

Level 4: ULTRATHINK
"ultrathink about optimizing our database for scale"
→ Maximale Tokens für Reasoning
→ Für kritische Design-Entscheidungen

WANN WELCHES LEVEL?
━━━━━━━━━━━━━━━━━━
Einfacher Bug Fix      → Standard
Neues Feature          → Think
Architektur-Refactoring → Think Hard
System Design          → Ultrathink
Security Audit         → Ultrathink

Das Think-Plan-Execute Pattern

Das Think-Plan-Execute Pattern ist die strukturierteste und zuverlässigste Methode für komplexe Aufgaben. Statt Claude direkt implementieren zu lassen, teilst du den Prozess in drei klar getrennte Phasen auf — mit Kontrollpunkten dazwischen wo du eingreifen kannst. Phase 1 — Think: Claude analysiert das Problem ohne etwas zu ändern. 'Denke gründlich über folgendes Problem nach: [Beschreibung]. Analysiere die betroffenen Dateien, identifiziere Abhängigkeiten, und liste potenzielle Risiken auf. Mache KEINE Code-Änderungen.' Das Ergebnis ist eine fundierte Problemanalyse. Phase 2 — Plan: Basierend auf der Analyse erstellt Claude einen konkreten Implementierungsplan. 'Erstelle einen detaillierten Plan mit: 1) Welche Dateien müssen geändert werden, 2) In welcher Reihenfolge, 3) Welche Tests müssen geschrieben werden, 4) Welche Risiken bestehen.' Du prüfst den Plan und gibst Feedback oder Korrekturen. Phase 3 — Execute: Claude setzt den genehmigten Plan um. 'Setze den Plan Schritt für Schritt um. Nach jedem Schritt: kurzer Status-Report.' Weil der Plan bereits genehmigt ist, gibt es weniger Überraschungen und die Implementierung verläuft strukturiert. Warum ist dieses Pattern so wirkungsvoll? Weil es das häufigste Problem vermeidet: Claude springt direkt in die Implementierung und merkt mittendrin dass der Ansatz falsch war. Mit dem Plan-Schritt werden Probleme BEVOR sie Code werden identifiziert. Das Pattern funktioniert besonders gut für: Multi-Datei-Änderungen, Architektur-Refactorings, Feature-Implementierungen die bestehenden Code berühren, und Migrationen. Für einfache Einzel-Datei-Änderungen ist es Overhead. Ein Profi-Tipp: Du kannst die Phasen auch verkürzen. Statt drei separate Prompts kannst du sagen: 'Think hard: Analysiere das Problem und erstelle einen Plan. Wenn der Plan weniger als 5 Dateien betrifft, setze ihn direkt um. Wenn mehr, zeige mir den Plan zuerst.'

# SCHRITT 1: Denken — Claude analysiert das Problem
> ultrathink about the best approach to refactor
> our authentication system

# SCHRITT 2: Planen — Strukturierter Plan
> Create a detailed plan. Don't implement yet.
> Just outline the steps.

# SCHRITT 3: Review — Plan prüfen
> Review your plan. What could go wrong?
> What edge cases are we missing?

# SCHRITT 4: Ausführen — Schritt für Schritt
> Now implement step 1 of the plan.
> After each step, verify it works.

# KOMBINIERT (Power-Prompt):
> ultrathink + plan mode:
> 1. Analyze the current auth system
> 2. Identify security issues
> 3. Propose migration strategy
> 4. Create implementation plan
> 5. Critique the plan for edge cases

Task-spezifische Kontext-Templates

Task-spezifische Kontext-Templates sind vordefinierte Prompt-Strukturen für verschiedene Aufgabentypen. Statt bei jedem Bug-Fix, Feature oder Refactoring den Prompt von Grund auf zu formulieren, nutzt du ein Template das die wichtigsten Informationen strukturiert abfragt. Das Feature-Template: 'Feature: [Name]. User Story: Als [Rolle] möchte ich [Funktion] damit [Nutzen]. Acceptance Criteria: [Liste]. Tech-Approach: [Beschreibung]. Betroffene Dateien: [Liste]. Tests: [Welche Tests braucht es].' Das Bug-Fix-Template: 'Bug: [Beschreibung]. Reproduzierbar in: [Datei/Zeile/Bedingung]. Erwartet: [Verhalten]. Tatsächlich: [Verhalten]. Vermutete Ursache: [Deine Vermutung oder 'Unbekannt']. Constraints: [Was darf nicht geändert werden].' Das Refactoring-Template: 'Scope: [Welche Dateien/Module]. Ziel: [Warum refactoren]. Grenzen: [Was darf NICHT geändert werden]. Test-Strategie: [Wie sichergestellt wird dass nichts bricht]. Pattern: [Welches Pattern soll angewendet werden].' Das Review-Template: 'Scope: [Welche Dateien/PRs]. Fokus: [Was besonders geprüft werden soll]. Standards: [Welche Checkliste]. Output: [Erwartetes Format des Reviews].' Diese Templates kannst du als Slash-Commands umsetzen: /project:feature, /project:bugfix, /project:refactor, /project:review. Beim Aufruf füllst du die Felder aus und Claude hat alles was es braucht. Der Wert von Templates: Sie zwingen dich, BEVOR du anfängst nachzudenken was Claude wirklich wissen muss. Das verbessert die Ergebnisse dramatisch — nicht weil Claude schlauer wird, sondern weil du ihm besseren Input gibst.

TEMPLATE 1: FEATURE DEVELOPMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

> Implementiere: [Feature-Beschreibung]
>
> User Story: Als [Rolle] möchte ich [Funktion],
>   damit [Nutzen].
>
> Acceptance Criteria:
> - [Kriterium 1]
> - [Kriterium 2]
> - [Edge Case]
>
> Technischer Kontext:
> - Relevante Dateien: [Pfade]
> - Bestehende Patterns folgen in: [Referenz-Datei]
> - DB-Migration nötig: Ja/Nein
>
> Definition of Done:
> - [ ] Implementation
> - [ ] Unit Tests
> - [ ] Error Handling
> - [ ] Dokumentation aktualisiert
TEMPLATE 2: BUG FIXING
━━━━━━━━━━━━━━━━━━━━━━

> Bug: [Kurzbeschreibung]
>
> Symptom: [Was passiert?]
> Erwartung: [Was sollte passieren?]
> Seit wann: [Commit/Datum/Release]
>
> Reproduktion:
> 1. [Schritt 1]
> 2. [Schritt 2]
> → [Fehlverhalten]
>
> Bereits geprüft:
> - [Was du schon untersucht hast]
> - [Was du ausschließen kannst]
>
> Relevante Dateien: [Pfade]
> Logs/Fehlermeldung: [Error-Output]
>
> Bekannte Gotchas in diesem Bereich:
> - [z.B. "Race Condition bei gleichzeitigen Requests"]
> - [z.B. "Cache invalidiert nicht bei DB-Updates"]
TEMPLATE 3: REFACTORING
━━━━━━━━━━━━━━━━━━━━━━━

> Refactoring: [Was soll verbessert werden?]
>
> Motivation: [Warum jetzt? Was ist das Problem?]
>
> Scope:
> - Dateien die geändert werden dürfen: [Pfade]
> - Dateien die NICHT angefasst werden dürfen: [Pfade]
> - Öffentliche API darf sich ändern: Ja/Nein
>
> Ziel-Zustand:
> - [Wie soll der Code nachher aussehen?]
> - [Welche Patterns sollen genutzt werden?]
>
> Constraints:
> - Alle bestehenden Tests müssen weiter grün sein
> - Keine neuen Dependencies
> - Backward-compatible (keine Breaking Changes)
>
> Test-Strategie:
> - Bestehende Tests laufen lassen: [Befehl]
> - Neue Tests nötig: Ja/Nein
> - Manuell prüfen: [Was?]

Häufige Prompting-Fehler

Diese Fehler sind die Hauptursache für schlechte Ergebnisse mit Claude Code. Der rote Faden: Zu wenig Kontext, zu viel auf einmal und zu unspezifische Anweisungen. Wenn du diese Fehler kennst und vermeidest, verbessern sich deine Ergebnisse dramatisch. Fehler 1 — Der Kontext-Mangel: 'Implementiere eine Login-Seite.' Was fehlt? Welches Framework? Welches Design? Welche Validierung? Welche Fehlerbehandlung? Welche Accessibility-Anforderungen? Ohne Kontext rät Claude — und rät oft falsch. Besser: Alles relevante Wissen bereitstellen. Fehler 2 — Der Mega-Prompt: 'Refactore die gesamte App, schreib Tests für alles, aktualisiere die Docs, fixe alle Bugs und optimiere die Performance.' Das ist kein Prompt, das ist ein Quartalsziel. Claude kann nicht fünf große Aufgaben gleichzeitig gut erledigen. Besser: Eine Aufgabe nach der anderen. Fehler 3 — Die negative Formulierung: 'Mach es nicht wie beim letzten Mal falsch' oder 'Vermeide schlechten Code.' Claude braucht POSITIVE Anweisungen — was es TUN soll, nicht was es NICHT tun soll. Besser: Konkrete Qualitätskriterien definieren. Fehler 4 — Der fehlende Qualitätsstandard: 'Implementiere die API.' Soll das ein Quick-Prototype sein oder Production-Ready? Der Unterschied in Claude's Output ist enorm. Besser: Explizit angeben welches Qualitätsniveau erwartet wird. Fehler 5 — Der Kontextwechsel: Mitten in einer Aufgabe plötzlich über ein anderes Thema sprechen. Claude verliert den Faden und die Qualität beider Aufgaben leidet. Besser: Eine Aufgabe abschließen, dann die nächste beginnen. Fehler 6 — Keine Beispiele geben: Bei komplexen Aufgaben (Code-Style, Output-Format, Test-Struktur) sind Beispiele Gold wert. 'Schreib Tests wie in src/auth/__tests__/login.test.ts' gibt Claude ein konkretes Muster zum Folgen. Die gute Nachricht: Alle diese Fehler sind einfach zu vermeiden sobald du sie kennst.

SCHLECHT vs. GUT — Konkrete Beispiele
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

❌ "Build a complete e-commerce platform"
→ Zu viel auf einmal, kein Kontext

✅ "Lass uns E-Commerce Features bauen. Starte mit einer
    Analyse der bestehenden Codebasis und schlage eine
    Architektur vor die zu unseren Patterns passt."
→ Schrittweise, aufbauend, kontextbewusst

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

❌ "Add caching"
→ Welche Art? Wo? Wie lange? Invalidierung?

✅ "Füge Redis Caching für /api/products hinzu.
    Cache für 5 Minuten. Invalidiere bei Product-Updates.
    Folge dem Pattern in src/middleware/cache.ts"
→ Spezifisch, mit Kontext und Referenz

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

❌ "Fix the bug"
→ Welcher Bug? Wo? Seit wann?

✅ "Der Login-Endpoint gibt 401 zurück trotz gültiger
    Credentials. Das Problem startete nach Commit abc123.
    Prüfe src/auth/login.ts und die JWT-Validierung."
→ Symptom, Zeitpunkt, Dateien — alles da

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

❌ "Make it faster"
→ Was genau? Wo messen? Was ist "schnell genug"?

✅ "Die /api/invoices Route braucht 3s statt der
    gewünschten 200ms. Das Problem ist vermutlich
    ein N+1 Query in src/services/invoiceService.ts.
    Optimiere mit Eager Loading."
→ Messbar, lokalisiert, Lösungsrichtung angegeben

Das Persona-Pattern

Das Persona-Pattern ist eine fortgeschrittene Prompting-Technik bei der du Claude bittest, aus einer spezifischen Expertenperspektive zu analysieren oder zu handeln. Statt generisches KI-Feedback zu bekommen, aktivierst du gezielt das Wissen und die Denkweise eines bestimmten Fachexperten. Die Grundidee: Claude hat Wissen aus vielen Fachgebieten. Wenn du sagst 'Analysiere den Code', bekommst du eine allgemeine Analyse. Wenn du sagst 'Analysiere den Code als erfahrener Security-Auditor mit 15 Jahren Erfahrung in Finanzanwendungen', bekommst du eine deutlich fokussiertere und tiefere Analyse — weil Claude das relevante Security-Wissen in den Vordergrund stellt. Praktische Persona-Beispiele: 'Als Performance-Ingenieur bei Netflix: Analysiere die API-Response-Zeiten und identifiziere Bottlenecks.' 'Als UX-Designer bei Apple: Bewerte die Benutzerführung dieses Formulars.' 'Als DevOps-Engineer: Prüfe die Docker-Konfiguration auf Best Practices.' 'Als Datenbank-Architekt: Optimiere dieses Schema für Lesezugriffe bei 100K+ Einträgen.' Das Persona-Pattern funktioniert besonders gut in Kombination mit Deep Thinking: 'Think hard als Security-Auditor...' aktiviert sowohl das Security-Wissen als auch das erweiterte Reasoning. Die Ergebnisse sind oft bemerkenswert nah an dem was ein menschlicher Experte liefern würde. Wichtig: Die Persona sollte zur Aufgabe passen. Ein 'SEO-Experte' der Code-Reviews macht liefert schlechtere Ergebnisse als ein 'Senior Backend-Engineer'. Die Persona lenkt Claude's Fokus — stell sicher dass sie in die richtige Richtung lenkt. Du kannst Personas auch für Custom Agents nutzen: Der System-Prompt eines Agents definiert dauerhaft seine Persona. So musst du nicht bei jedem Prompt die Rolle neu definieren — der Agent IST der Experte. Ein häufiger Fehler: Zu spezifische oder unrealistische Personas. 'Du bist Linus Torvalds persönlich' führt zu Rollenspiel statt zu besserem Code. Fokussiere auf Expertise und Erfahrung, nicht auf Persönlichkeit.

# Spezifische Expertise aufrufen:
> As a database performance expert,
> analyze our query patterns and suggest indexes

> As a security researcher,
> attempt to find vulnerabilities in our auth system

# Multi-Perspektiven Analyse:
> Analyze this API design from the perspectives of:
> - Performance engineer (Response times, caching)
> - Security auditor (Input validation, auth)
> - Frontend developer (API ergonomics, error codes)
> - DevOps engineer (Monitoring, scaling, deployment)
> Each perspective should highlight different concerns.

Das Iterative Refinement Pattern

Das Iterative Refinement Pattern nutzt eine fundamentale Stärke von Claude: die Fähigkeit zur Selbstkritik. Statt den perfekten Prompt zu suchen, erstellst du eine erste Version, lässt Claude sie kritisieren, und verbesserst dann iterativ. Jede Runde verbessert die Qualität. Der Ablauf in drei Schritten: Schritt 1 — Erste Implementation: 'Implementiere [Aufgabe].' Claude erstellt eine erste Version. Schritt 2 — Self-Review: 'Reviewe deine eigene Implementation. Finde Schwachstellen, fehlende Edge Cases und Verbesserungsmöglichkeiten.' Claude analysiert kritisch was es gerade geschrieben hat. Schritt 3 — Verbesserung: 'Setze die Verbesserungen aus deinem Review um.' Claude fixet die identifizierten Probleme. Warum ist das so effektiv? Weil verschiedene Denkprozesse beteiligt sind: Implementierung ist kreativer, generierender Natur. Review ist analytischer, kritischer Natur. Durch die Trennung nutzt du beides. Das Ergebnis ist fast immer besser als der erste Versuch. Fortgeschrittene Variante: Nutze unterschiedliche Perspektiven für den Review. 'Reviewe als Security-Auditor.' Dann: 'Reviewe als Performance-Engineer.' Dann: 'Reviewe als Junior-Developer der den Code verstehen muss.' Jede Perspektive findet andere Probleme. Du kannst beliebig viele Iterationen machen, aber in der Praxis bringen die ersten 2-3 Runden den größten Qualitätsgewinn. Danach werden die Verbesserungen marginal und du verschwendest Tokens. Das Pattern eignet sich besonders für: Kritischen Code (Payment, Auth, Datenmigration), öffentlich sichtbaren Code (Open Source, API-Design), und komplexe Algorithmen. Für einfache Utility-Funktionen ist es Overhead. Ein Profi-Tipp: Du kannst alle drei Schritte in einen einzigen Prompt packen: 'Implementiere [Aufgabe]. Dann reviewe deine Implementation auf Schwachstellen. Dann fixe alle gefundenen Probleme. Zeige mir die finale Version.' Das spart Prompts und funktioniert erstaunlich gut.

# "Ask for Everything" — Lass Claude nachfragen
> Create a PRD for our new feature.
> Ask me everything you need to prepare the best PRD.

# Claude wird fragen:
# "Was ist das Ziel? Wer ist die Zielgruppe?
#  Welche Constraints? Welche bestehenden Patterns?"
# → Bessere Ergebnisse durch Dialog statt Monolog

# Self-Critique Engine:
> Implement the authentication system.
> Then critique your own implementation for:
> - Security flaws
> - Performance issues
> - Missing edge cases
> Fix anything you find.

# Mehrere Revisionsrunden:
> Round 1: Implement
> Round 2: Critique and fix
> Round 3: Final review with checklist

Fortgeschrittene Steuerung

Fortgeschrittene Steuerungsmuster gehen über einfache Prompts hinaus und geben dir feingranulare Kontrolle über Claude's Verhalten. Diese Patterns sind für Power-User die das Maximum aus Claude Code herausholen wollen. Das SCOPE CONTROL Pattern: 'Dein Scope ist AUSSCHLIESSLICH das Auth-Modul in src/auth/. Ändere KEINE Dateien außerhalb dieses Verzeichnisses. Wenn du Änderungen außerhalb brauchst, beschreibe sie als TODO-Kommentare.' Das verhindert dass Claude bei einer fokussierten Aufgabe auf Abwege gerät. Das EXPLICIT CONSTRAINTS Pattern: 'Die Funktion MUSS synchron sein (kein async). Sie MUSS in unter 10ms ausführbar sein. Sie DARF keine externen Dependencies nutzen. Sie MUSS mit Node.js 18 kompatibel sein.' Klare, explizite Grenzen die Claude als harte Anforderungen behandelt. Das REFERENCE FIRST Pattern: 'Bevor du implementierst, lies @src/auth/login.ts und nutze die gleichen Patterns. Insbesondere: gleiches Error-Format, gleiche Validierungs-Library, gleiche Namenskonvention.' Das stellt Konsistenz mit bestehendem Code sicher. Das CHECKPOINT Pattern: 'Implementiere Schritt für Schritt. Nach jedem Schritt: Kurze Zusammenfassung was getan wurde, was als nächstes kommt. Warte auf mein OK bevor du weitermachst.' Das gibt dir Kontrollpunkte bei komplexen Aufgaben. Das TEACH ME Pattern: 'Implementiere die Lösung, aber erkläre nach jeder Entscheidung WARUM du dich so entschieden hast. Welche Alternativen gab es? Warum diese und nicht die anderen?' Perfekt zum Lernen und für Architektur-Dokumentation. Diese Patterns lassen sich kombinieren: SCOPE CONTROL + REFERENCE FIRST + CHECKPOINT für ein kontrolliertes Feature-Development. Oder TEACH ME + EXPLICIT CONSTRAINTS für eine Lern-Session mit klaren Grenzen.

PATTERN: SCOPE CONTROL
━━━━━━━━━━━━━━━━━━━━━
"Ändere NUR die Funktion getUser() in userService.ts.
Keine anderen Dateien anfassen."
→ Verhindert ungewollte Seiteneffekte

PATTERN: EXPLICIT CONSTRAINTS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
"Nutze keine neuen Dependencies.
Löse das mit Standard-Library Mitteln."
→ Verhindert Dependency Bloat

PATTERN: REFERENCE FIRST
━━━━━━━━━━━━━━━━━━━━━━━━
"Schau dir erst src/services/orderService.ts an.
Implementiere den neuen Service im gleichen Pattern."
→ Konsistenz mit bestehendem Code

PATTERN: CHECKPOINT
━━━━━━━━━━━━━━━━━━
"Implementiere den ersten Teil.
Zeige mir den Code BEVOR du weiter machst."
→ Frühe Korrekturmöglichkeit, spart Tokens

PATTERN: TEACH ME
━━━━━━━━━━━━━━━━━
"Erkläre mir die Vor- und Nachteile beider Ansätze.
Ich entscheide dann welchen wir nehmen."
→ Lernen + kontrollierte Entscheidung

Zusammenfassung