Claude Code/Codex Prompts für Einsteiger: 5 praktische Muster

Einstieg: Ein guter Prompt ist ein klares Arbeitsbriefing

Wenn Claude Code oder Codex ein chaotisches Ergebnis liefert, liegt es oft nicht daran, dass der Agent “schlecht codet”. Der Prompt hat zu wenig Arbeitsgrenzen gesetzt. Ein Prompt ist kein Zaubersatz. Er ist ein Arbeitsbriefing für einen Coding-Agenten: was geändert werden soll, was nicht berührt werden darf, was als fertig gilt, welche Nachweise gesammelt werden sollen und was die nächste Person wissen muss.

Dieser Einsteigerleitfaden macht daraus 5 praktische Muster: Scope, Repository-Kontext, Akzeptanzkriterien, Prüfnachweis und Handoff. Sie funktionieren für Bugfixes, kleine Features, Artikelgenerierung, Repository-Audits und Reviews. Ziel ist nicht geschickte KI-Rhetorik, sondern weniger Ratespiel.

Produktdetails ändern sich, daher sollten offizielle Dokumente verlinkt bleiben. Starten Sie mit Claude Code overview, Claude Code memory und Claude Code settings. Für Codex und OpenAI-Code-Workflows ist der OpenAI code generation guide ein guter Einstieg. Wenn Sie das Tool selbst noch kennenlernen, lesen Sie zusätzlich den Claude Code Einstiegsguide und die CLAUDE.md Best Practices.

Die 5 Muster im Überblick

Muster	Einfache Bedeutung	Was fehlt, wenn es fehlt
Scope	Grenze der Aufgabe	Der Agent ändert fremde Dateien
Repo-Kontext	Bestehende Regeln und Beispiele	Die Ausgabe passt nicht zum Projektstil
Akzeptanzkriterien	Definition von fertig	“Fertig” bedeutet für Sie und den Agenten Unterschiedliches
Prüfnachweis	Beleg, dass geprüft wurde	Die Arbeit endet bei “implementiert”
Handoff	Kurze Notiz für die nächste Session	Später ist unklar, warum etwas geändert wurde

Akzeptanzkriterien sind konkrete Bedingungen, die erfüllt sein müssen, bevor Sie eine Änderung akzeptieren. Prüfnachweise sind die Quittung: ausgeführte Befehle, geprüfte Screens, manuelle Tests oder explizit nicht geprüfte Punkte. Handoff bedeutet, dass Sie morgen, ein Teammitglied oder ein anderer Agent ohne erneute Spurensuche weitermachen kann.

Muster 1: Scope eng setzen

Ein schwacher Prompt startet zu breit.

Verbessere diese App und mach sie besser.

Dieser Prompt sagt nicht, ob UI, API, Tests, Copy, Datenbankschema, Dependencies oder Deployment geändert werden dürfen. Claude Code und Codex können raten, aber jede Vermutung erhöht das Risiko.

Besser:

Bearbeite nur site/src/content/blog-de/5-tips-for-better-prompts.mdx.
Ziel: Den Artikel für Claude-Code/Codex-Einsteiger praktischer machen.

Erlaubt:
- title, description, updatedDate und tags im Frontmatter
- Artikeltext

Nicht ändern:
- heroImage
- slug
- andere Artikel
- Build-Konfiguration

Das ist bei monetarisierten Websites besonders wichtig. Ein breiter Rewrite kann interne Links, Produkt-CTAs oder Analytics-Attribute versehentlich entfernen. Ein klarer Scope gibt dem Agenten genug Bewegungsfreiheit, ohne eine Artikelkorrektur in ein Gesamtrefactoring zu verwandeln.

Für reine Recherche formulieren Sie noch enger:

Lies die relevanten Dateien und schlage nur einen Plan vor. Noch nichts bearbeiten.
Liste Dateien, Änderungsgrund und Prüfkommando für jede vorgeschlagene Änderung.

Ein häufiger Fehler ist “schau erst einmal” zu sagen und gleichzeitig Änderungen zu erlauben. Trennen Sie Analyse und Implementierung, wenn das Repository unbekannt ist.

Muster 2: Repository-Kontext geben

Claude Code/Codex kann Dateien lesen, kennt aber nicht automatisch Ihre Business-Priorität, Stilentscheidungen oder frühere Fehler. Repository-Kontext erklärt, wie dieses Projekt funktioniert.

Diese Website nutzt Astro content collections für lokalisierte MDX-Artikel.
Nutze site/src/content/blog-de/claude-code-productivity-tips.mdx als Qualitätsreferenz.

Projektkontext:
- Artikel sollen praktische Evergreen-Tutorials sein, keine dünnen KI-Zusammenfassungen.
- Mindestens 3 konkrete Use Cases einbauen.
- Offizielle externe Links und interne Links einfügen.
- Conversion-Pfad erhalten: /de/thanks/, /en/products/, /en/training/.
- Frontmatter gültig halten.

Ohne diesen Kontext entsteht vielleicht ein sauberer Text, aber nicht unbedingt ein ClaudeCodeLab-Artikel. Hier braucht der Leser kopierbare Prompts, Fehlerbeispiele, Prüfgewohnheiten und einen natürlichen nächsten Schritt zu Cheatsheet, Produkten oder Training.

Wenn Sie denselben Kontext oft wiederholen, legen Sie den stabilen Teil in CLAUDE.md ab. Die Claude Code Produktivitätstipps zeigen, wie Projektregeln, sichere Befehle und Prüfgewohnheiten wiederholte Erklärungen reduzieren.

Muster 3: Akzeptanzkriterien vorab schreiben

Akzeptanzkriterien verhindern die Schleife “mach es besser”. Ein schwacher Prompt wäre:

Mach diesen Artikel lesbarer und besser für SEO.

Lesbarkeit und SEO sind wichtig, aber so nicht gut prüfbar. Zerlegen Sie es:

Akzeptanzkriterien:
- Nur die Zieldatei wird geändert.
- Die description hat höchstens 120 Zeichen.
- Jedes der 5 Muster enthält ein Before/After-Promptbeispiel.
- Templates für Bugfix, Feature und Artikelgenerierung sind enthalten.
- Konkrete Fehlerfälle und Vermeidung sind enthalten.
- Offizielle Links, interne Links und klare CTA sind enthalten.
- Am Ende werden Prüfung und Restrisiken berichtet.

Bei einem Feature sollten die Kriterien technischer sein:

Akzeptanzkriterien:
- Bestehendes UI-Layout bleibt erhalten.
- Keine TypeScript-Typfehler.
- Validierung und sichtbare Fehlerzustände werden ergänzt.
- Mindestens ein relevanter Test wird ergänzt oder aktualisiert.
- Ergebnis von npm test und npm run build wird berichtet.

Der Punkt ist: Jeder Eintrag muss prüfbar sein. Wenn der Agent etwas nicht beweisen kann, soll er es offen sagen, statt es als erledigt darzustellen.

Muster 4: Prüfnachweise verlangen

“Implementiert” reicht nicht. Bitten Sie um einen verification receipt.

Gib am Ende einen verification receipt zurück:

- Geänderte Dateien:
- Ausgeführte Befehle:
- Ergebnisse:
- Manuelle Checks:
- Nicht geprüft:
- Restrisiken:

Diese Gewohnheit verhindert viele Einsteigerfehler. Sie macht auch sichtbar, wenn ein Befehl nicht laufen konnte, weil Dependencies fehlen, Tests zu langsam sind oder ein lokaler Service nicht verfügbar ist. Danach können Sie das Risiko bewusst akzeptieren oder nacharbeiten lassen.

Fehler sollten nicht zu stark zusammengefasst werden. Das ist schwach:

Der Build ist kaputt. Repariere ihn.

Das ist nützlich:

Befehl:
npm run build

Fehler:
Type error: Property 'name' does not exist on type 'User | undefined'.
File: src/components/Profile.tsx:15:22

Aufgabe:
Erkläre die wahrscheinliche Ursache, mache den kleinsten sicheren Fix und führe npm run build erneut aus.

Für einen kompletten Ablauf lesen Sie den Verification-Receipt-Workflow. Das Format ist zweitrangig. Wichtig ist, dass Arbeit nicht ohne Beleg endet.

Muster 5: Handoff-Notiz anfordern

Agentenarbeit endet oft nicht in einer Session. Eine Handoff-Notiz verhindert, dass die nächste Session alles neu erschließt.

Schreibe am Ende eine handoff note mit:
- Ziel
- Was geändert wurde
- Was nicht geändert wurde
- Prüfergebnisse
- Dateien für die nächste Prüfung
- Offene Risiken oder Entscheidungen

Das hilft bei Artikeln, SEO, Checkout-Flows und Team-Repositories. Ein Diff zeigt, was geändert wurde, erklärt aber selten, warum eine CTA an einer bestimmten Stelle steht oder warum ein kleiner Fix statt eines großen Refactorings gewählt wurde.

Für Teams passt das gut zu Claude Code Team-Handoff-Regeln. Ein stabiles Format macht KI-Sessions reviewbar.

Kopierbare Templates

Bugfix-Template

Ziel:
  Den Bug mit dem kleinsten sicheren Diff beheben.

Symptom:
  Was passiert:
  Erwartetes Verhalten:
  Tatsächliches Verhalten:

Reproduktion:
  1.
  2.
  3.

Scope:
  Dateien, die geändert werden dürfen:
  Dateien, die nicht geändert werden dürfen:

Repository-Kontext:
  Ähnliche Implementierung:
  Lokale Regeln:

Akzeptanzkriterien:
  Vor dem Editieren wahrscheinliche Ursachen erklären.
  Root Cause beheben, nicht nur Symptom verstecken.
  Wenn möglich relevanten Test ergänzen oder aktualisieren.
  Prüfnachweis und Restrisiko berichten.

Feature-Template

Ziel:
  Ein kleines Feature sicher hinzufügen.

Feature:
  Sichtbare Änderung für Nutzer:
  API/DB/Konfigurationsänderungen:

Einschränkungen:
  Bestehenden UI-Stil erhalten.
  Aktuelle Namens- und Dateimuster befolgen.
  Größere Designänderungen vor der Implementierung erklären.

Akzeptanzkriterien:
  Implementierung, Typen, Fehlerzustände, Tests und verification receipt enthalten.

Artikel-Template

Ziel:
  Dies zu einem einsteigerfreundlichen Evergreen-Artikel verbessern.

Leser:
  Solo-Entwickler oder kleines Team, das mit Claude Code/Codex startet.

Pflichtbestandteile:
  3 oder mehr konkrete Use Cases.
  Before/After-Promptbeispiele.
  Konkrete Fehlerfälle und Lösungen.
  Kopierbare Templates.
  Offizielle Links, interne Links und CTA.

Akzeptanzkriterien:
  Description höchstens 120 Zeichen.
  Frontmatter bleibt gültig.
  Code fences sind geschlossen.
  Am Ende kurze Selbstprüfung.

Drei praktische Use Cases

Der erste Use Case ist ein weißer Bildschirm nach dem Login. Schreiben Sie nicht nur “Dashboard reparieren”. Geben Sie Reproduktionsschritte, erwartetes Ergebnis, echten Console-Fehler, editierbare Dateien und Prüfkommandos an. So arbeitet der Agent eher an der Ursache statt nur am Symptom.

Der zweite Use Case ist ein Feld “Anfragetyp” in einem Lead-Formular. Ein guter Prompt nennt Optionen wie training, consulting und other, Validierungsregel, API-Vertrag, Analytics-Event und Testerwartung. So bleibt der Monetarisierungspfad geschützt und der Diff klein.

Der dritte Use Case ist Artikelgenerierung. Für ClaudeCodeLab sollte der Prompt Tiefe, konkrete Beispiele, Fehlerfälle, offizielle Links, interne Links, CTA und den abschließenden Absatz zum realen Testergebnis verlangen. So entsteht kein generischer KI-Text, sondern ein brauchbarer Anfängerartikel.

Kleine Prompt-QA-Rubrik

Bewerten Sie Ihren Prompt vor dem Senden mit 10 Punkten.

Punkte	Bereich	Frage
0-2	Scope	Sind editierbare und geschützte Dateien klar?
0-2	Kontext	Gibt es lokale Beispiele, Leser und Business-Zweck?
0-2	Akzeptanz	Kann der Agent erkennen, wann die Aufgabe fertig ist?
0-2	Prüfung	Sind Befehle oder manuelle Checks genannt?
0-2	Handoff	Ist klar, was am Ende berichtet werden soll?

Ab 8 Punkten ist der Prompt meist bereit. Bei 5 oder weniger muss der Agent fehlenden menschlichen Kontext kompensieren.

Ausführbarer Briefing-Generator

Statt “mach es besser” zu schreiben, lohnt sich immer dieselbe Briefing-Struktur. Dieses Skript erzeugt prompt-brief.md; passe Datei und Abnahmekriterien an, bevor du es an Claude Code oder Codex gibst. So sind Scope, Grenzen und Prüfung von Anfang an klar.

cat > prompt-brief.md <<'EOF'
# Task brief for Claude Code / Codex

Goal:
- Improve one article or feature without changing unrelated files.

Scope:
- May edit: site/src/content/blog/example.mdx
- Do not edit: hero images, routes, unrelated articles, billing code.

Context to read first:
- AGENTS.md
- A similar high-quality article
- The target file

Acceptance criteria:
- The intro explains who the reader is and why this matters.
- The draft includes at least three concrete examples.
- Code or prompt templates are copy-pasteable.
- Pitfalls and verification steps are explicit.
- Internal links and a natural CTA are included.

Verification:
- npm run build
- node scripts/check-code-fences.mjs
- Read the changed file once as a reviewer.

Return:
- What changed
- Checks run
- Remaining risks
EOF

CTA: Aus dem Muster einen Workflow machen

Sie müssen diese Muster nicht jeden Tag neu schreiben. Starten Sie mit dem kostenlosen Claude Code Cheatsheet für tägliche Befehle und sichere Gewohnheiten. Für fertige Prompt-Packs und Setup-Material schauen Sie in ClaudeCodeLab products. Wenn Ihr Team CLAUDE.md, Berechtigungen, Review-Policy, verification receipts und Rollout-Training strukturieren muss, ist Claude Code training and consultation der passende Einstieg.

In echten ClaudeCodeLab-Artikeln und Website-Aufgaben brachte es am meisten, Scope, Akzeptanzkriterien und Prüfnachweis vor der Bearbeitung zu schreiben. Handoff-Notizen haben die Review am nächsten Tag ebenfalls verkürzt, weil der Grund für jede CTA und jeden Link sichtbar blieb.