Claude Entwickler-Prompts

Stand: Juli 2026 · Geprüft gegen die offiziellen Anthropic-Dokumentationen (platform.claude.com/docs, code.claude.com/docs). Zehn generische Entwickler-Prompts – neu gedacht für Claude und Claude Code.

Vorab: Was Claude anders macht

Rollen- und Strukturprompts funktionieren mit jedem LLM. Die Prompts auf dieser Seite gehen einen Schritt weiter: Sie nutzen gezielt die Stärken, die Anthropic für Claude offiziell dokumentiert. Die sieben wichtigsten Prinzipien im Überblick:

1. 1

   XML-Tags

   Claude ist darauf trainiert, mit XML-Tags strukturierte Prompts besonders zuverlässig zu verarbeiten (<context>, <task>, <constraints>, <output_format>).

2. 2

   Rollenzuweisung

   Schon ein einzelner Rollensatz verbessert laut Anthropic Fokus und Tonalität der Antwort spürbar.

3. 3

   Lange Inhalte oben, Frage unten

   Bei großen Eingaben (Code, Logs, Dokumente) gehören die Daten an den Anfang, die eigentliche Aufgabe ans Ende. Das verbessert die Antwortqualität in Anthropic-Tests um bis zu 30 %.

4. 4

   Verifikation

   Die wirksamste Einzelmaßnahme in Claude Code ist, Claude eine überprüfbare Erfolgsbedingung zu geben (Tests, Build, Linter, Screenshot-Vergleich). Claude arbeitet dann selbstständig, bis die Prüfung besteht – statt dass du jede Änderung manuell kontrollierst.

5. 5

   Plan Mode & Phasentrennung

   Claude Code hat einen Plan-Modus (Shift+Tab). Recherche und Planung von der Implementierung zu trennen verhindert, dass das falsche Problem gelöst wird.

6. 6

   CLAUDE.md

   Projektkonventionen (Test-Befehle, Formatierung, Verbote) gehören in eine CLAUDE.md im Projektroot – sie wird jede Session automatisch geladen, du musst sie nicht wiederholen.

7. 7

   Kontextmanagement

   Claudes Kontextfenster füllt sich schnell; die Leistung sinkt, wenn es voll ist. Kleine Aufgaben, /clear zwischen unabhängigen Tasks, Subagenten für Reviews.

Aufbau: Jeder Abschnitt enthält den fertigen Prompt für claude.ai, eine Claude-Code-Variante (wo sinnvoll), einen Faktencheck mit der Einordnung, warum das so funktioniert, sowie – direkt nebeneinander – Hinweise für Einsteiger und für Profis.

1. Entwickler für produktionsreife Features

Du bist ein Senior Software Engineer für [Stack, z. B. Astro 5 + TypeScript].

<context>
Projekt: [Kurzbeschreibung]
Stack: [Sprachen, Frameworks, DB, Hosting]
Bestehende Struktur: [Verzeichnisbaum oder relevante Dateien hier einfügen]
Konventionen: [z. B. SCSS mit @use/@forward, ESLint-Regeln]
</context>

<task>
Entwickle das Feature: [präzise Beschreibung mit konkreten Ein- und Ausgaben].
</task>

<constraints>
- Keine neuen Abhängigkeiten ohne Begründung
- Bestehende Ordnerstruktur beibehalten
- [weitere technische Einschränkungen]
</constraints>

<workflow>
Arbeite in zwei Phasen:
Phase 1 – Plan: Anforderungen analysieren, Edge Cases auflisten, Architektur
skizzieren (Ordnerstruktur, Datenfluss). Stelle mir Rückfragen, wenn
Anforderungen unklar sind, statt Annahmen zu treffen.
Phase 2 – erst nach meiner Freigabe: vollständige Implementierung inkl.
Fehlerbehandlung, Validierung ungültiger Eingaben und kurzer Performance-
Einschätzung mit Begründung.
</workflow>

<verification>
Definiere, wie ich das Feature testen kann: konkrete Testfälle inkl.
Edge Cases und erwarteter Ergebnisse.
</verification>

Lies zuerst [relevante Dateien/Ordner] und fasse die bestehende Architektur
zusammen. Erstelle dann im Plan-Modus einen Implementierungsplan für
[Feature] inkl. Edge Cases. Warte auf meine Freigabe.
Nach Freigabe: implementiere, schreibe Tests, führe [Testbefehl] aus und
iteriere, bis alle Tests grün sind. Zeige mir am Ende die Testausgabe.

Faktencheck

Der Prompt verbessert die Struktur der Zusammenarbeit – Produktionsreife garantiert er allein nicht. Zwei Dinge sind durch Anthropic gedeckt: Rollenprompts fokussieren das Modell, und „Plan vor Code” (Plan Mode) ist offizielle Best Practice. Der wichtigste Hebel steckt im <verification>-Block: „Produktionsreif” wird Code nicht durch ein Wort im Prompt, sondern durch Tests, die Claude selbst ausführen und bestehen muss.

2. Komplette App von Grund auf neu

Du bist ein erfahrener Full-Stack-Engineer und baust ein MVP wie für ein
echtes Startup: klein, nutzbar, erweiterbar.

<product>
[Produktbeschreibung: Was tut die App? Für wen? Kernfunktionen als Liste.]
</product>

<requirements>
Stack: [z. B. Astro SSR + Node, oder Next.js]
Datenbank: [z. B. PostgreSQL + Prisma]
Auth: [z. B. Session-basiert / OAuth]
Rollen: [z. B. Admin, Redakteur, Gast]
Hosting: [z. B. VPS mit Docker]
Erwartete Nutzerzahl: [Größenordnung]
</requirements>

<workflow>
Phase 1: Systemarchitektur, Ordnerstruktur, DB-Schema (als SQL oder
Prisma-Schema), API-Endpunkte (Tabelle: Methode, Route, Zweck, Auth),
UI-Struktur (Seiten + Komponenten). KEIN Code in dieser Phase.
Phase 2 (nach meiner Freigabe): Implementierung Modul für Modul in dieser
Reihenfolge: [z. B. 1. DB-Schema, 2. Auth, 3. Kern-CRUD, 4. UI].
Liefere pro Antwort genau EIN Modul vollständig – ich sage jeweils „weiter".
</workflow>

Interviewe mich zuerst: Stelle mir alle Fragen, die du brauchst, um
[App-Idee] als MVP zu planen (Stack, Auth, Rollen, Umfang). Erstelle danach
im Plan-Modus die Architektur und ein PLAN.md mit Modulen als Checkliste.
Implementiere anschließend Modul für Modul, committe nach jedem Modul mit
aussagekräftiger Message und führe nach jedem Schritt [Build-/Testbefehl]
aus. Hake erledigte Module in PLAN.md ab.

Faktencheck

„Vollständiger Code in einer Antwort” ist bei größeren Apps unrealistisch – genau deshalb empfiehlt Anthropic, Aufgaben klein zu halten, weil die Leistung sinkt, wenn das Kontextfenster voll läuft. Die modulweise Umsetzung mit Commits pro Schritt ist in Claude Code der dokumentierte Weg: Commits dienen als Checkpoints, zu denen man zurückkehren kann. Das „Interview zuerst”-Muster (Claude stellt dir Fragen) ist eine etablierte Praxis für größere Projekte.

3. Code-Repository verstehen und refaktorieren

Du bist ein Senior Engineer, der neu in dieses Repository einsteigt.

<repository>
[Verzeichnisbaum]
[Zentrale Konfigurationsdateien]
[Einstiegspunkte, package.json/composer.json]
[Relevanter Code – bei großen Repos: modulweise in mehreren Nachrichten]
</repository>

<known_issues>
[Bekannte Probleme, langsame Stellen, Bug-Historie – falls vorhanden]
</known_issues>

<task>
Analysiere ausschließlich – ändere noch nichts:
1. Architektur-Zusammenfassung: Module, Verantwortlichkeiten, Datenfluss
2. Problembereiche: Duplikate, enge Kopplung, Wartbarkeitsrisiken –
 jeweils mit Datei- und Zeilenverweis als Beleg
3. Refactoring-Strategie: priorisiert nach Risiko und Nutzen,
 in Schritten, die einzeln testbar sind
Triff keine Aussagen über Code, den du nicht gesehen hast – sage
explizit, welche Teile dir fehlen.
</task>

Verschaffe dir selbstständig einen Überblick über dieses Repository:
Einstiegspunkte, Modulstruktur, Datenfluss, Abhängigkeiten. Beantworte
danach: Wo gibt es Duplikate, enge Kopplung, Wartbarkeitsrisiken?
Belege jede Aussage mit Datei:Zeile.
Erstelle dann im Plan-Modus eine priorisierte Refactoring-Strategie.
Vor jedem Refactoring-Schritt: Schreibe Charakterisierungs-Tests, die das
aktuelle Verhalten festhalten. Refaktoriere dann in kleinen Commits und
führe nach jedem Commit die Tests aus. Verhalten darf sich nicht ändern.

Faktencheck

Refactoring heißt: Struktur verbessern, Verhalten erhalten – und die Qualität hängt davon ab, wie vollständig der Code vorliegt. Genau hier trennen sich claude.ai und Claude Code: In Claude Code entfällt das Kopieren des Repos komplett – Claude liest die Dateien selbst und navigiert agentisch durch den Code. Anthropic dokumentiert das Onboarding in fremde Codebasen ausdrücklich als Kern-Use-Case („Ask Claude questions you’d ask a senior engineer”). Charakterisierungs-Tests vor dem Umbau sind die fachlich saubere Absicherung, dass „Verhalten unverändert” keine Behauptung bleibt, sondern geprüft wird.

4. Senior Debugging Engineer

Du bist ein Senior Engineer und untersuchst einen Fehler in Produktion.
Ziel ist die Ursache, nicht ein Workaround.

<error>
Fehlermeldung: [exakter Wortlaut]
Stacktrace: [vollständig]
Logs: [relevante Auszüge]
</error>

<code>
[Betroffener Code – großzügig, inkl. aufrufender Stellen]
</code>

<environment>
[Versionen, OS, Server, Konfiguration]
</environment>

<behavior>
Erwartet: [was passieren sollte]
Tatsächlich: [was passiert]
Reproduktion: [Schritte]
</behavior>

<task>
1. Stelle mehrere Hypothesen zur Ursache auf und bewerte jede gegen die
 vorliegenden Belege (Logs, Stacktrace).
2. Nenne die wahrscheinlichste Ursache und WIE ich sie verifizieren kann,
 BEVOR wir etwas ändern (z. B. Log-Statement, Testabfrage).
3. Erst danach: minimale, robuste Korrektur mit Begründung + ein Test,
 der die Regression künftig verhindert.
Behaupte nichts über Code oder Zustände, die du nicht belegen kannst.
</task>

Bug: [Beschreibung]. Reproduziere den Fehler zuerst selbst mit
[Befehl/Testfall] und zeige mir die Ausgabe. Analysiere dann die Ursache –
bilde Hypothesen und prüfe sie gegen Logs/Code, bevor du etwas änderst.
Implementiere anschließend die kleinste sichere Korrektur, schreibe einen
Regressionstest und führe die gesamte Testsuite aus. Zeige mir als Beleg
die Testausgabe vorher (rot) und nachher (grün).

Faktencheck

„Denke Schritt für Schritt” garantiert keine richtige Schlussfolgerung – entscheidend sind Logs und reproduzierbare Tests. Die wirksame Claude-Code-Praxis geht noch weiter: Claude soll den Fehler zuerst absichtlich reproduzieren, bevor er ihn fixt. Ein Rot-Grün-Nachweis (fehlschlagender Test → Fix → bestehender Test) ist der stärkste Beleg, dass wirklich die Ursache getroffen wurde und nicht nur ein Symptom. Anthropic empfiehlt generell, Claude Evidenz zeigen zu lassen statt Erfolg zu behaupten.

5. Systemdesign und Implementierung

Du bist ein erfahrener Systemarchitekt.

<requirements>
Produkt: [Beschreibung]
Nutzer: [erwartete Anzahl, gleichzeitige Zugriffe]
Daten: [Menge, Wachstum, Lese-/Schreibverhältnis]
Antwortzeiten: [Ziel, z. B. p95 < 300 ms]
Verfügbarkeit: [z. B. 99,9 %]
Sicherheit: [Auth, DSGVO, sensible Daten?]
Budget/Betrieb: [z. B. ein VPS, kein Kubernetes, kleines Team]
</requirements>

<task>
Phase 1 – Design: Komponentendiagramm (als Text/Mermaid), Datenfluss,
API-Design, DB-Schema, Caching-Strategie. Begründe jede wesentliche
Entscheidung gegen die Anforderungen oben und nenne je eine verworfene
Alternative mit Grund. Dimensioniere für die GENANNTEN Zahlen – keine
Hyperscaler-Architektur für ein 1.000-Nutzer-Projekt.
Phase 2 (nach Freigabe): minimale Produktionsversion, Modul für Modul.
</task>

Faktencheck

Ohne konkrete Anforderungen (Nutzerzahlen, Datenmengen, Antwortzeiten) lässt sich „skalierbar” nur generisch beantworten. Zwei Verstärker sind entscheidend. Erstens: Entscheidungen gegen die Anforderungen begründen lassen – sonst liefert das Modell Lehrbuch-Architektur statt passender Architektur. Zweitens: je eine verworfene Alternative verlangen. Sie zwingt zu echter Abwägung und macht die Antwort überprüfbar. Der explizite Anti-Overengineering-Satz ist wichtig, weil LLMs bei „skalierbar” zu Microservices, Queues und Kubernetes tendieren, auch wenn ein Monolith auf einem VPS die richtige Antwort wäre.

6. Vorschläge zur Performance-Optimierung

Du bist Performance-Engineer. Regel Nr. 1: Erst messen, dann optimieren.

<measurements>
[Lighthouse-Report / Core Web Vitals]
[Server-Timings, langsame Requests]
[DB-Query-Pläne (EXPLAIN ANALYZE)]
[Profiler-Ausgaben, Speicherverbrauch – was vorhanden ist]
</measurements>

<code>
[Relevanter Code]
</code>

<task>
1. Identifiziere aus den MESSDATEN die 3 größten Engpässe, geordnet nach
 erwartetem Nutzen. Nenne pro Engpass den Beleg aus den Messungen.
2. Schlage nur für diese Engpässe Optimierungen vor – mit geschätztem
 Effekt und Risiko. Verändere keinen Code ohne nachvollziehbare
 Begründung aus den Daten.
3. Liefere den optimierten Code und beschreibe, mit welcher Messung ich
 den Erfolg verifiziere (Vorher-/Nachher-Vergleich).
Falls die Messdaten für eine sichere Diagnose nicht ausreichen: Sage mir
zuerst, WELCHE Messung ich nachliefern soll und wie ich sie erhebe.
</task>

Führe [Benchmark-/Profiling-Befehl] aus und analysiere das Ergebnis.
Identifiziere die 3 größten Engpässe mit Beleg. Optimiere dann NUR den
größten, führe den Benchmark erneut aus und zeige mir den
Vorher-/Nachher-Vergleich. Erst nach messbarem Erfolg: nächster Engpass.

Faktencheck

Ohne Messdaten drohen theoretische Optimierungen – klassische Premature Optimization. Deshalb macht der Prompt daraus ein hartes Protokoll: Messdaten sind Pflicht, nicht Option, und Claude soll fehlende Messungen aktiv anfordern statt zu raten. In Claude Code wird der Benchmark selbst zur Verifikationsschleife – Claude misst, ändert, misst erneut. Das entspricht exakt Anthropics „give Claude a check it can run”-Prinzip. Einen Engpass nach dem anderen zu optimieren hält die Ursache-Wirkung-Zuordnung sauber.

7. Neuaufbau mit Clean Architecture

Du bist Staff-Level-Engineer. Aufgabe: Struktur verbessern, Verhalten
exakt erhalten.

<code>
[Bestehender Code + Verzeichnisbaum]
</code>

<tests>
[Vorhandene Tests – falls keine existieren, sage es]
</tests>

<task>
1. Prüfe zuerst: Rechtfertigt die Projektgröße eine volle Clean
 Architecture (domain/application/infrastructure/presentation) – oder
 genügt eine leichtere Trennung? Begründe und schlage die passende
 Zielstruktur vor. Keine Architektur-Zeremonie für kleine Projekte.
2. Falls Tests fehlen: Schreibe ZUERST Charakterisierungs-Tests, die das
 Ist-Verhalten festhalten.
3. Refaktoriere dann in kleinen, einzeln nachvollziehbaren Schritten:
 Zuständigkeiten trennen, Kopplung reduzieren, Fachlogik von
 Framework-/Infrastrukturcode lösen.
4. Liefere: neue Ordnerstruktur, Architektur-Begründung, refaktorierten
 Code, und pro Schritt den Hinweis, welche Tests ihn absichern.
</task>

Refaktoriere [Modul/Ordner] Richtung sauberer Schichtentrennung – Verhalten
bleibt identisch. Vorgehen: 1) Falls keine Tests existieren, schreibe
Charakterisierungs-Tests und führe sie aus (müssen grün sein). 2) Schlage
im Plan-Modus die Zielstruktur vor, angemessen zur Projektgröße. 3) Nach
Freigabe: refaktoriere in kleinen Commits, führe nach JEDEM Commit die
Tests aus. Bricht ein Test: stoppe und berichte, statt den Test anzupassen.

Faktencheck

Clean Architecture kann kleine Projekte aufblähen, und Tests sind die Voraussetzung, um „Verhalten unverändert” überhaupt zu prüfen. Daraus folgen zwei harte Konsequenzen. Erstens: Die Angemessenheitsprüfung steht bewusst als Schritt 1 – Claude muss die Architekturentscheidung begründen, statt reflexhaft vier Schichten zu bauen. Zweitens die kritische Regel „Test bricht → stoppen, nicht den Test anpassen”: LLMs neigen dazu, bei roten Tests den Test zu „reparieren” statt den Code – genau das würde hier unbemerkt Verhalten ändern.

8. Multi-Agenten-Workflow für Claude

Wir arbeiten die Aufgabe in vier getrennten Phasen ab. Bearbeite immer nur
die Phase, die ich aufrufe – nicht vorgreifen.

Aufgabe: [Beschreibung]
Kontext: [Stack, Code, Anforderungen]

Phase 1 „Architect": Entwirf die Lösung (Architektur, Datenfluss,
Schnittstellen). Keine Implementierung.
Phase 2 „Engineer": Implementiere exakt den freigegebenen Entwurf.
Phase 3 „Reviewer": Prüfe die Implementierung kritisch, als hättest du
sie NICHT selbst geschrieben: Korrektheit, Edge Cases, Sicherheit,
Wartbarkeit. Finde mindestens 3 konkrete Schwachstellen mit Beleg –
„sieht gut aus" ist keine zulässige Antwort.
Phase 4 „Optimizer": Überarbeite den Code nur auf Basis der
Review-Befunde. Liste am Ende: Befund → Änderung.

Starte jetzt mit Phase 1.

In Claude Code lässt sich das Muster mit ECHTER Trennung umsetzen:
- Implementierung in der Hauptsession (Plan-Modus für Phase 1+2)
- Review durch einen Subagenten mit frischem Kontext:
„Starte einen Review-Subagenten, der die Änderungen in [Dateien] prüft,
ohne meine bisherige Session zu kennen. Er soll versuchen, die Lösung
zu widerlegen: Edge Cases, Sicherheitslücken, Regressionen."
- Alternativ: Review in einer zweiten, frischen Session (/clear) oder als
definierter Subagent unter .claude/agents/reviewer.md.

Faktencheck

Ein einzelnes Modell, das alle vier Rollen simuliert, ist kein echtes Vier-Augen-Prinzip – getrennte Anfragen sind besser. Genau das ist heute offizielle Claude-Code-Praxis: Anthropic beschreibt Verifikation „by a second opinion” durch einen Subagenten mit frischem Kontext, damit nicht derselbe Agent seine eigene Arbeit benotet. Die Formulierung „versuche die Lösung zu widerlegen” ist dabei wichtig – ein Reviewer mit Bestätigungsauftrag findet nichts. Der sequenzielle Phasen-Prompt für claude.ai ist die bestmögliche Annäherung ohne Subagenten: Phasentrennung plus erzwungene Mindestbefunde.

9. Bau produktionsreifer UI-Komponenten

Du bist Senior Frontend Engineer und baust eine wiederverwendbare,
barrierefreie Komponente.

<setup>
Framework: [z. B. Astro / React / Vue + Version]
Styling: [z. B. SCSS mit Design-Tokens / Tailwind]
Designsystem: [vorhandene Tokens, Farben, Spacing – hier einfügen]
Browser-Support: [Zielbrowser]
A11y-Ziel: WCAG 2.1 AA
</setup>

<component>
Komponente: [z. B. Modal-Dialog]
Varianten: [z. B. Größe sm/md/lg, mit/ohne Footer]
Zustände: normal, laden, leer, Fehler, deaktiviert, Erfolg
Verhalten: [z. B. schließt bei Escape und Klick außerhalb]
</component>

<task>
1. Props-/API-Design zuerst: Name, Typ, Default, Pflicht/Optional,
 Events/Callbacks – als Tabelle. Kurz begründen.
2. Implementierung inkl. ALLER genannten Zustände, responsivem Verhalten
 und Tastaturbedienung (Fokusreihenfolge, Fokusfalle wo nötig,
 sichtbarer Fokus, korrekte ARIA-Attribute mit Begründung – keine
 ARIA-Dekoration ohne Funktion).
3. Liefere eine manuelle Prüfliste: Was teste ich mit Tastatur, was mit
 Screenreader, was bei 200 % Zoom und auf schmalen Viewports?
</task>

Baue die Komponente [Name] gemäß [Spez/Design]. Verifiziere selbst:
Führe [Lint-/Test-/axe-Befehl] aus und iteriere bis grün. Falls die
Claude-Chrome-Extension/Browser-Tools verfügbar sind: Öffne die
Komponente im Browser, prüfe Tastaturbedienung und Responsivität per
Screenshot bei 375 px und 1440 px Breite und vergleiche mit dem Design.

Faktencheck

Ob eine Komponente wirklich barrierefrei ist, zeigt erst der Test mit Tastatur, Screenreader und Prüfwerkzeugen – nicht der Prompt. Zwei Verschärfungen lohnen sich. Erstens „keine ARIA-Dekoration ohne Funktion”: LLMs streuen gern ARIA-Attribute als Barrierefreiheits-Kosmetik ein; falsches ARIA ist schlechter als keins. Zweitens die visuelle Verifikationsschleife: Anthropic dokumentiert den Screenshot-Vergleich gegen ein Design-Mock als etablierten Claude-Code-Workflow – nach zwei bis drei Iterationen ist das Ergebnis typischerweise deutlich besser als der erste Wurf. Automatisierte A11y-Checks (axe) fangen dabei nur einen Teil ab; die manuelle Prüfliste bleibt Pflicht.

10. Entwicklung veröffentlichungsfertiger APIs

Du bist erfahrener Backend-Engineer und baust eine produktionsreife API.

<setup>
Stil: [REST / GraphQL / RPC] + Versionierung: [z. B. /api/v1]
Stack: [Sprache, Framework, DB]
Auth: [z. B. Bearer-Token / Session] · Rollen: [Liste]
Datenmodell: [Entitäten + Beziehungen]
</setup>

<endpoints>
[Gewünschte Endpunkte oder: „Leite sie aus dem Datenmodell ab und lege
mir die Liste zur Freigabe vor"]
</endpoints>

<task>
Phase 1 – Design (zur Freigabe): Routen-Tabelle (Methode, Pfad, Zweck,
Auth/Rolle, Statuscodes), einheitliches Fehlerformat (Struktur + Beispiel),
Validierungsregeln pro Endpunkt.
Phase 2 – Implementierung: Schichten getrennt (Routen → Validierung →
Controller → Service → Datenzugriff), Fehlerbehandlung für: ungültige
Eingaben (400/422), fehlende Auth (401), fehlende Rechte (403), nicht
gefunden (404), Konflikte (409), interne Fehler (500, ohne interne
Details im Response). Logging an sinnvollen Stellen.
Phase 3 – Betriebsreife: Nenne explizit, was für den echten Go-Live noch
fehlt und liefere davon: Integrationstests für die kritischen Endpunkte
und eine OpenAPI-Spezifikation. Benenne offen, was danach noch offen
bleibt (Rate Limiting, Monitoring, Backup/Migrationen, Security-Audit).
</task>

Baue die API gemäß PLAN.md / obiger Spezifikation. Nach jedem Endpunkt:
führe die Integrationstests aus ([Testbefehl]) und iteriere bis grün.
Halte die OpenAPI-Spec parallel aktuell. Am Ende: führe die komplette
Suite aus und zeige mir die Testausgabe sowie einen curl-Smoke-Test pro
Endpunkt (Happy Path + ein Fehlerfall).

Faktencheck

Für einen echten Go-Live fehlt oft mehr, als man denkt: Tests, Rate Limiting, Monitoring, Doku, Deployment, Backups. Dieser Prompt schließt zwei dieser Lücken direkt (Integrationstests und OpenAPI-Doku sind von Claude gut lieferbar) und macht den Rest explizit sichtbar, statt ihn stillschweigend wegzulassen. Das strukturierte Fehlerformat samt konkreter Statuscode-Zuordnung gehört in Phase 1, weil es nachträglich alle Endpunkte betrifft. Der curl-Smoke-Test als Abschlussbeleg folgt dem Anthropic-Prinzip, Erfolg durch gezeigte Evidenz statt Behauptung nachzuweisen.

Gemeinsame Einordnung

Wichtig zum Schluss: Diese Prompts sind keine Spezialbefehle und aktivieren keine verborgenen Funktionen. Es sind Rollen- und Strukturprompts, die Perspektive, Arbeitsschritte, Bestandteile und Qualitätsmerkmale der Antwort festlegen – und vor allem die Struktur verbessern, nicht die Faktenlage ersetzen.

Drei Punkte sind 2026 besonders wichtig:

1. Der größte Hebel ist Verifikation, nicht Formulierung. Anthropic nennt es die wirksamste Einzelmaßnahme, Claude eine ausführbare Prüfung zu geben (Tests, Build, Linter, Screenshot-Vergleich) und iterieren zu lassen, bis sie besteht. Ein mittelmäßiger Prompt mit Testschleife schlägt einen perfekten Prompt ohne.
2. Claude Code verändert die Prompt-Ökonomie. Vieles, was in claude.ai in den Prompt kopiert werden muss (Repo, Struktur, Konventionen), liest Claude Code selbst – Konventionen wandern einmalig in die CLAUDE.md, Rollen und Prüfroutinen in Subagenten und Skills. Die Prompts werden dadurch kürzer, nicht länger.
3. Kontext ist die knappe Ressource. Kleine Aufgaben, Phasentrennung, /clear zwischen unabhängigen Tasks und Pläne in Dateien (PLAN.md) statt im Chatverlauf – das sind die Praktiken, die bei allen zehn Prompts über die Ergebnisqualität entscheiden.

Unverändert gilt: Code muss getestet, gereviewt und an das reale Projekt angepasst werden. Die Prompts strukturieren die Zusammenarbeit – die Verantwortung für das Ergebnis bleibt beim Menschen, dessen Name am Commit steht.

Quellen: Anthropic Prompt Engineering Docs (platform.claude.com/docs/en/build-with-claude/prompt-engineering), Claude Code Best Practices (code.claude.com/docs/en/best-practices), Anthropic Engineering Blog zu agentischem Coding und Kontext-Engineering.