Die besten ChatGPT- und Claude-prompts für Entwickler geben dem Modell drei Dinge: den echten Code, eine klare Aufgabe und ein definiertes Ausgabeformat. Das ist der ganze Trick hinter einer nützlichen Coding-GPT- oder AI-Softwareentwickler-Sitzung. „Prüfe meinen Code“ führt zu einer höflichen Zusammenfassung. „Prüfe diesen Diff auf Fehler und Sicherheitsprobleme, liste die Befunde nach Schweregrad mit Zeilennummern auf und schreibe die Datei nicht neu“ liefert dir etwas, mit dem du arbeiten kannst. Unten findest du 30 prompts für Entwickler, gegliedert in sechs Gruppen: Code-Review und Qualität, Tests, Refactoring und Performance, Dokumentation und PR-Beschreibungen, Frontend sowie Backend und DevOps. Sie sind sprachunabhängig und enthalten Platzhalter für [language], mit einigen Python- und TypeScript-Versionen, wenn die Details eine Rolle spielen.
Code-Review, einmal konfiguriert
Yuri - AI Skill für Code-Reviews
Yuri lädt deine Review-Standards, die Skala für Schweregrade und deinen Stack einmal, sodass jedes Review denselben Regeln folgt, statt jedes Mal mit einem neuen prompt zu beginnen.
$19
Skill abrufen →
So verwendest du diese prompts
Kopiere einen prompt, ersetze die [brackets] und füge den Code oder Diff direkt danach ein. Zwei Gewohnheiten machen einen großen Unterschied. Füge erstens immer das tatsächliche Artefakt ein: die Funktion, den Stacktrace, den Diff, das Schema. Eine Beschreibung des Codes ist nicht der Code. Sage zweitens, was du zurückhaben möchtest: einen Diff, eine Tabelle, eine nummerierte Liste, eine Datei. Modelle liefern standardmäßig Fließtext; den möchtest du nur selten.
Wenn du Claude Code verwendest, funktionieren die prompts weiterhin wie eingegeben, aber viele davon lassen sich besser als Slash-Befehl oder Skill speichern, damit du sie nicht immer wieder eingeben musst. Weiter unten gibt es dazu einen kurzen Abschnitt und in unserem Leitfaden zu Claude Code Skills einen ausführlicheren.
Code-Review und Qualität (prompts 1 bis 5)
Review-prompts funktionieren am besten mit einem Diff, nicht mit einer vollständigen Datei. Bitte um Befunde, die nach Schweregrad gruppiert sind, damit du die Stilhinweise überspringen kannst, wenn du wenig Zeit hast.
Prompt 1: Senior-Review nach Schweregrad
Prüfe diesen [language]-Diff als Senior Engineer. Gruppiere die Befunde in: Fehler, Sicherheit, Performance, Wartbarkeit, Stil. Gib für jeden Befund die Zeilenreferenz, das Problem in einem Satz und die Lösung an. Schreibe nicht die gesamte Datei neu. Wenn du in einer Kategorie nichts findest, sag das. Diff: [paste diff]
Prompt 2: Sicherheitsprüfung
Prüfe diesen [language]-Code ausschließlich auf Sicherheitsprobleme: Injection, unsichere Deserialisierung, fehlende Eingabevalidierung, Geheimnisse im Code, unsichere Standardeinstellungen und Abhängigkeitsrisiken. Gib für jeden Befund in einer Zeile das Risiko, wie es ausgenutzt werden könnte, und die sicherere Version an. Code: [paste code]
Prompt 3: Die Änderung für einen Reviewer erklären
Ich bin der Autor dieses Diffs. Schreibe die Review-Hinweise, die ich anhängen sollte, damit ein Reviewer es schnell versteht: Was wurde geändert, warum, worauf sollte zuerst geachtet werden, was liegt bewusst außerhalb des Umfangs und wie habe ich es getestet? Halte dich unter 150 Wörtern. Diff: [paste diff]
Prompt 4: Latenten Fehler finden
Dieser [language]-Code funktioniert im Happy Path, aber ich vermute einen Fehler in Grenzfällen. Gehe ihn mit diesen Eingaben durch: leere Eingabe, null oder None, sehr große Eingabe, nebenläufige Aufrufe und eine fehlschlagende Abhängigkeit. Sage für jede Eingabe, was passiert und ob das korrekt ist. Code: [paste code]
Prompt 5: Überprüfung von Python-Typen und Linting
Überprüfe dieses Python-Modul hinsichtlich Typisierung und Korrektheit. Ergänze oder korrigiere Typannotationen, weise auf alles hin, was mypy im Strict-Modus ablehnen würde, und nenne veränderliche Standardargumente, nackte except-Blöcke und nicht geschlossene Ressourcen. Gib das korrigierte Modul und eine Aufzählung der Änderungen zurück. Code: [paste code]
Tests (Prompts 6 bis 10)
Bitte das Modell, die Fälle aufzulisten, bevor es die Tests schreibt. Eine fehlende Fallkonstellation lässt sich in einer fünfzeiligen Liste viel leichter erkennen als in 200 Zeilen Testcode.
Prompt 6: Unit-Tests mit vorheriger Fallliste
Schreibe Unit-Tests für diese [language]-Funktion mit [test framework]. Liste vor dem Code jeden abzudeckenden Fall auf: Happy Path, Grenzfälle, Fehlerpfade und ungültige Eingaben. Schreibe anschließend die Tests. Verwende aussagekräftige Testnamen, die wie Sätze formuliert sind. Funktion: [paste code]
Prompt 7: Regressionstest aus einem Fehlerbericht
Hier sind ein Fehlerbericht und die Behebung. Schreibe einen Regressionstest, der mit dem alten Code fehlschlägt und mit dem neuen Code erfolgreich ist, unter Verwendung von [test framework]. Benenne den Test nach dem Fehler. Fehler: [describe bug]. Diff der Behebung: [paste diff]
Prompt 8: Tests vor einer riskanten Änderung
Ich bin dabei, [what you are changing] in [file or module] zu ändern. Liste die Tests auf, die vor der Änderung vorhanden sein sollten, sortiert danach, wie wahrscheinlich sie einen Fehler entdecken. Markiere anhand dieser Testdatei, welche bereits vorhanden sind: [paste test file]
Prompt 9: TypeScript-Integrationstest
Schreibe einen Integrationstest in TypeScript mit [Vitest or Jest] für diesen API-Handler. Mocke nur die externe Grenze ([database, HTTP client, queue]), nicht interne Module. Decke einen erfolgreichen Aufruf, einen Validierungsfehler und ein Timeout des Upstream-Dienstes ab. Handler: [paste code]
Prompt 10: Testüberprüfung
Überprüfe diese Tests. Sage mir, welche Assertions schwach sind (Wahrheitswerte prüfen, nur Snapshots erstellen oder statt des Codes den Mock testen), welche Fälle fehlen und welche Tests redundant sind. Schlage die drei wertvollsten Ergänzungen vor. Tests: [paste tests]
Refactoring und Performance (Prompts 11 bis 15)
Für Refactoring-prompts ist eine harte Einschränkung erforderlich: Das Verhalten darf sich nicht ändern. Sage dies ausdrücklich und fordere die Änderungen als Liste an, damit du sie einzeln überprüfen kannst.
Prompt 11: Verhaltenserhaltendes Refactoring
Überarbeite diesen [language]-Code zur besseren Lesbarkeit, ohne das Verhalten zu ändern. Behalte die öffentliche Schnittstelle unverändert bei. Liste vor dem Code jede Änderung in einer Zeile mit ihrer Begründung auf. Weise auf alles hin, was wie ein Fehler aussieht, aber behebe es nicht stillschweigend, sondern vermerke es separat. Code: [paste code]
Prompt 12: Eine lange Funktion aufteilen
Diese Funktion ist zu lang. Teile sie in kleinere Funktionen mit klaren Namen auf, von denen jede genau eine Aufgabe erfüllt. Zeige zuerst die neue Struktur als Gliederung (Funktionsnamen und einzeiliger Zweck), dann den Code. Führe keine neuen Abstraktionen ein, außer sie werden mindestens zweimal verwendet. Code: [paste code]
Prompt 13: Performanceproblem finden
Dieser [language]-Code ist bei [size of input] langsam. Identifiziere den wahrscheinlichen Engpass, schätze seine Komplexität und schlage eine Lösung vor. Erkläre die Kompromisse der Lösung (Speicher, Lesbarkeit, Korrektheitsrisiko). Führe keine Mikrooptimierung durch; finde den entscheidenden Engpass. Code: [paste code]. Profiling-Ausgabe, falls vorhanden: [paste]
Prompt 14: Python-Performance-Umschreibung
Schreibe diese Python-Funktion für bessere Performance um. Bevorzuge Built-ins, Comprehensions, Generatoren und die Standardbibliothek gegenüber selbst geschriebenen Schleifen. Behalte dieselbe Signatur und denselben Rückgabetyp bei. Zeige die Version vorher und nachher und beschreibe, wie du sie mit timeit benchmarken würdest. Code: [paste code]
Prompt 15: Duplikate entfernen
Hier sind zwei oder mehr Codeabschnitte, die ähnlich aussehen. Sag mir, ob sie eine Implementierung gemeinsam nutzen oder getrennt bleiben sollten (und warum). Wenn sie eine gemeinsame Implementierung nutzen sollten, schreibe sie und zeige, wie sich die einzelnen Aufrufstellen ändern. Code A: [paste]. Code B: [paste]
Dokumentation und PR-Beschreibungen (prompts 16 bis 20)
Dokumentation wird am häufigsten ausgelassen. Diese prompts benötigen zehn Sekunden und ergeben etwas, das ein neues Teammitglied tatsächlich verwenden kann.
Prompt 16: PR-Beschreibung
Verfasse eine Beschreibung für einen Pull Request zu diesem Diff. Abschnitte: Zusammenfassung (zwei Sätze), Änderungen (Aufzählung), Warum, Testanleitung (Schritte), Risiken und Rollback. Klare Sprache, kein Marketington. Erfinde keinen Kontext, den ich nicht angegeben habe. Diff: [paste diff]. Ticket: [ticket link or summary]
Prompt 17: Docstrings und Kommentare
Füge jeder öffentlichen Funktion und Klasse in dieser [language]-Datei Docstrings nach dem Stil [Google, NumPy, JSDoc oder deinem Standard] hinzu. Dokumentiere Parameter, Rückgabewerte, ausgelöste Fehler und jeweils ein Beispiel. Füge keine Kommentare hinzu, die den Code lediglich wiederholen. Datei: [paste code]
Prompt 18: README für ein Modul
Schreibe einen README-Abschnitt für dieses Modul: wofür es da ist, wann es verwendet werden sollte, ein minimales funktionierendes Beispiel, Konfigurationsoptionen als Tabelle und häufige Fehler. Halte ihn unter 300 Wörtern. Code: [paste code or public API]
Prompt 19: Dokumentation des API-Endpunkts
Erstelle eine Referenzdokumentation für diesen Endpunkt: Methode, Pfad, Authentifizierungsanforderung, Anfrageparameter mit Typen und Angabe, ob sie erforderlich sind, ein Beispiel für eine Anfrage, ein Beispiel für eine erfolgreiche Antwort und jede Fehlerantwort mit ihrer Ursache. Quelle: [paste route or controller]
Prompt 20: Architektur-Entscheidungsprotokoll
Verfasse einen ADR für diese Entscheidung. Abschnitte: Kontext, Entscheidung, erwogene Alternativen (mit Begründung, warum jede abgelehnt wurde), Konsequenzen. Maximal eine Seite. Entscheidung: [describe]. Alternativen: [list]. Einschränkungen: [list]
Frontend (prompts 21 bis 25)
Frontend-prompts sollten das Framework und das Rendering-Modell nennen. „React“ allein reicht nicht aus, wenn sich die Antwort zwischen einer Client-Komponente und einer Server-Komponente unterscheidet.
Prompt 21: Komponentenprüfung
Prüfe diese [React, Vue, Svelte]-Komponente auf: unnötige erneute Renderings, Zustände, die abgeleitet werden sollten, fehlende Keys, Effekte, die Event-Handler sein sollten, und Props, die Implementierungsdetails nach außen geben. Nenne für jedes Problem eine Lösung. Komponente: [paste code]
Prompt 22: Barrierefreiheitsprüfung
Prüfe dieses Markup und den Komponentencode auf Barrierefreiheit: semantische Elemente, Beschriftungen, Fokusreihenfolge, Tastaturbedienbarkeit, Farbkontrast-Token und falsche ARIA-Verwendung. Liste die Probleme mit dem jeweiligen WCAG-Kriterium, gegen das sie verstoßen, sowie den korrigierten Code auf. Code: [paste code]
Prompt 23: TypeScript-Typen für eine API-Antwort
Hier ist eine Beispiel-JSON-Antwort von [endpoint]. Schreibe TypeScript-Typen dafür. Verwende diskriminierte Unions, wenn ein Feld seine Form ändert, kennzeichne optionale Felder korrekt und füge mit [Zod or your library] einen Laufzeit-Validator hinzu, der zu den Typen passt. JSON: [paste sample]
Prompt 24: CSS-Layout-Debugging
Dieses Layout bricht bei [viewport or condition] zusammen. Hier sind HTML und CSS. Erkläre in einfachen Worten, was die Ursache ist, und gib dann die minimale CSS-Änderung zur Behebung an. Bevorzuge moderne Layouts (Grid, Flexbox, Container Queries) gegenüber Hacks. Code: [paste code]
Prompt 25: Entscheidung zur Zustandsverwaltung
Ich muss [describe state] in einer [framework]-App der Größe [size] verwalten. Vergleiche, den Zustand lokal zu halten, ihn in den Kontext zu heben und [store library] zu verwenden. Empfiehl für diesen Fall eine Option mit Begründung und zeige das Grundgerüst des empfohlenen Ansatzes.
Backend und DevOps (prompts 26 bis 30)
Backend- und Infrastruktur-prompts profitieren davon, wenn die Umgebung angegeben wird: die Datenbank, die Runtime-Version, der Cloud-Anbieter und was nicht ausfallen darf.
Prompt 26: Überprüfung des API-Designs
Überprüfe dieses API-Design auf Konsistenz und Korrektheit: Ressourcenbenennung, HTTP-Methoden und Statuscodes, Paginierung, Fehlerformat, Idempotenz von Schreibvorgängen und Versionierung. Gib eine Tabelle mit Problem, Bedeutung und Lösung zurück. Spezifikation oder Routen: [paste]
Prompt 27: Überprüfung von Datenbankabfragen und Schema
Überprüfe dieses [database]-Schema und diese Abfragen. Markiere fehlende Indizes, N+1-Muster, nullable Spalten, die nicht nullable sein sollten, sowie Abfragen, die über [rows] hinaus nicht skalieren. Schlage für jede Schemaänderung eine Migration vor. Schema: [paste]. Abfragen: [paste]
Prompt 28: Absicherung einer Dockerfile
Überprüfe diese Dockerfile. Verkleinere das Image, pinne Versionen, verwende einen Benutzer ohne Root-Rechte, trenne Build- und Laufzeitphasen und sorge für effektives Layer-Caching. Gib die verbesserte Dockerfile mit einem Kommentar zu jeder geänderten Zeile zurück. Dockerfile: [paste]
Prompt 29: Debugging einer CI-Pipeline
Diese [GitHub Actions, GitLab CI, other]-Pipeline schlägt sporadisch fehl. Hier sind die Konfiguration und ein fehlgeschlagenes Protokoll. Ermittle die wahrscheinlichste Ursache, sage mir, wie ich sie bestätigen kann, und nenne die Lösung. Falls es sich statt um die Pipeline um einen instabilen Test handelt, sage das. Konfiguration: [paste]. Protokoll: [paste]
Prompt 30: Nachbesprechung eines Vorfalls
Verfasse anhand dieser Notizen eine sachliche Nachbesprechung des Vorfalls. Abschnitte: Zusammenfassung, Auswirkungen, Zeitlicher Ablauf, Grundursache, Was gut lief, Was schlecht lief, Maßnahmen mit Verantwortlichen. Bleibe sachlich und spekuliere nicht über das hinaus, was die Notizen stützen. Notizen: [paste incident notes]
Wo diese in Claude Code hingehören
Wenn du Claude Code verwendest, ist es Zeitverschwendung, Prompt 1 bei jeder Überprüfung erneut einzugeben. Claude Code bietet dir drei Orte zum Speichern von Anweisungen, und jeder eignet sich für eine andere Art von Prompt.
-
CLAUDE.md ist für Regeln gedacht, die für jede Sitzung in einem Repository gelten sollen: die Sprache, das Test-Framework, der Styleguide, „niemals Geheimnisse committen“. Kurz, immer aktiv, ohne Argumente.
-
Slash-Befehle (Dateien in
.claude/commands/) sind für wiederholbare Aufgaben gedacht, die du bei Bedarf auslöst: /review, /pr-description, /tests. Die Prompts 1, 6 und 16 eignen sich natürlich als Slash-Befehle.
-
Skills dienen dem vollständigen Rollenverhalten: wie ein Code-Reviewer denkt, welche Schweregradskala er verwendet und wie ein QA-Ingenieur einen Testplan strukturiert. Ein Skill ist eine .md-Datei mit einem Workflow, Standards und Beispielen, die das Modell lädt, wenn die Aufgabe dazu passt. Sieh dir die Claude Code Skills-Sammlung und unsere Claude Skill-Beispiele an, um zu sehen, wie ein guter Skill aussieht.
Als Faustregel gilt: Wenn es eine Zeile ist, füge sie in CLAUDE.md ein. Wenn es ein prompt ist, den du häufig ausführst, mache daraus einen Slash-Befehl. Wenn es eine Rolle mit Ermessensentscheidungen ist, mache daraus einen Skill.
Aufgabe zu prompt zu Skill
| Aufgabe |
Obiger prompt |
Skill, der dies als Rolle übernimmt |
| Code-Review bei jedem PR |
1, 3, 4 |
Yuri - Code-Reviewer ($19) |
| Sicherheits- und Abhängigkeitsaudit |
2, 28 |
Soren - Code-Auditor ($19) |
| Testpläne und Test-Review |
6 bis 10 |
Mira - QA-Ingenieurin ($19) |
| Refactorings im gesamten Stack |
11 bis 15 |
Max - Full-Stack-Entwickler ($19) |
| Dokumentation, READMEs, ADRs |
17 bis 20 |
Saoirse - Technische Redakteurin ($19) |
| Frontend-Komponenten und Barrierefreiheit |
21 bis 25 |
Lena - Frontend-Entwicklerin ($19) |
| API- und Datenbankdesign |
26, 27 |
Niko - Backend-Entwickler ($19) |
| Docker, CI, Vorfälle |
28 bis 30 |
Rami - DevOps-Ingenieur ($19) |
| Autonomer Review-Agent für ein gesamtes Repository |
1, 2, 10 |
Albert - AI-Code-Review-Agent ($39) |
Wenn du die prompts als Paket möchtest
Alles oben kannst du kostenlos kopieren. Wenn du lieber eine größere, organisierte Sammlung mit Varianten pro Sprache und Rolle hättest, gibt es zwei Optionen:
Tech- & Dev-Prompt-Bibliothek ($21): eine strukturierte Bibliothek mit Entwickler-prompts für Review, Tests, Debugging, Dokumentation und Architektur, nach Aufgaben geordnet, damit du in Sekundenschnelle den richtigen findest. Teil des größeren ChatGPT-prompts-Katalogs.
Coding-Agent-Bundle - alle 5 AI-Coding-Agents ($99): fünf Coding-Agent-Skills in einem Kauf, für Review, Entwicklung, Tests, Backend und Infrastruktur - für Teams, die den gesamten Workflow statt nur eine Rolle konfigurieren möchten.
Alle Skills sind einmalige Käufe, werden als .md-Skill-Datei mit einer README geliefert und funktionieren in Claude (einschließlich Claude Code), in ChatGPT als benutzerdefiniertes GPT, in Gemini als Gem und in Copilot. Es gibt eine 30-tägige Geld-zurück-Garantie, ohne Wenn und Aber.
Häufig gestellte Fragen
Funktionieren diese prompts in ChatGPT und Claude auf die gleiche Weise?
Ja. Jeder prompt hier ist reiner Text ohne modellspezifische Syntax. Claude verarbeitet lange eingefügte Dateien und mehrstufige Refactorings meist gut, ChatGPT ist schnell bei isolierten Funktionen und kleinen Tests. Die Formulierung ändert sich nicht; was sich ändert, ist, wie viel Kontext du auf einmal einfügen kannst.
Soll ich meine gesamte Datei oder nur die Funktion einfügen?
Füge die kleinste Einheit ein, die das vollständige Problem enthält. Bei einem Bug sind das die Funktion sowie die Aufrufstelle und der Stacktrace. Bei einem Review ist es der Diff. Bei einem Refactoring ist es das Modul. Wenn du ein gesamtes Repository ohne konkrete Frage einfügst, erhältst du allgemeines Feedback.
Was ist der Unterschied zwischen einem prompt und einem Skill?
Ein prompt ist eine einmalige Anweisung, die du jedes Mal eingibst. Ein Skill ist eine .md-Datei mit deiner Rolle, deinen Standards und deinem Workflow, die das Modell einmal lädt, sodass jede Antwort bereits deinen Konventionen folgt. Skills von KissMySkills funktionieren in Claude und Claude Code, als benutzerdefiniertes ChatGPT-GPT, als Gemini Gem oder in Copilot und beinhalten eine 30-tägige Geld-zurück-Garantie.
Sind diese Python-prompts nur für Python?
Nein. Jeder prompt verwendet einen [language]-Platzhalter. Einige Beispiele nennen Python oder TypeScript, weil dies die häufigsten Anfragen sind, aber du kannst Go, Rust, Java, C# oder etwas anderes einsetzen, und die Struktur bleibt erhalten.
Kann ich diese prompts direkt in Claude Code einfügen?
Ja. Kurze, immer geltende Regeln gehören in CLAUDE.md, wiederholbare Aufgaben in einen Slash-Befehl unter .claude/commands, und vollständiges Rollenverhalten gehört in ein Skill. Im obigen Abschnitt darüber, wo prompts in Claude Code hingehören, wird erklärt, was wohin gehört.
Das Fazit
Gute prompts für Entwickler sind langweilig: echte Eingaben, eine Aufgabe, eine klar angegebene Ausgabe. Die 30 oben decken die tägliche Arbeit in den Bereichen Review, Tests, Refactoring, Dokumentation, Frontend, Backend und DevOps ab und funktionieren in ChatGPT und Claude auf die gleiche Weise. Verwende sie unverändert oder verschiebe die täglich genutzten in einen Slash-Befehl oder ein Skill, damit du sie nicht immer wieder eingeben musst.
Der gesamte Workflow, ein Kauf
Coding-Agent-Bundle - Alle 5 AI-Coding-Agents
Review-, Build-, Test-, Backend- und DevOps-Agents, die deine Standards einmal laden und bei jeder Aufgabe in Claude Code, ChatGPT, Gemini oder Copilot anwenden.
$99
Jetzt erhalten →
Durchsuche alle Claude Code Skills bei KissMySkills.
