Fortgeschrittenes Prompt Engineering für Claude Code und Codex: belastbare Task Briefs
Entwirf Claude Code/Codex Prompts mit Task Brief, Akzeptanzkriterien, Prüfbeleg und sicheren Iterationen.
Wenn Claude Code oder Codex ungleichmäßige Ergebnisse liefert, liegt es oft nicht am Modell. Häufig wurde die Arbeit zu unklar übergeben. Fortgeschrittenes Prompt Engineering ist keine magische Formulierung. Es ist Workflow-Design: Ziel, Scope, Kontext, Regeln, Akzeptanzkriterien, Prüfung und Übergabe in einem Paket.
Dieser Leitfaden zeigt, wie du ein wiederverwendbares “Prompt Packet” für Claude Code und Codex baust. Einsteiger können die Vorlagen direkt kopieren, aber die Struktur ist auch für Teams, echte Repositories, parallele Arbeiten, Produktionscode und veröffentlichte Artikel geeignet. Für Grundlagen lies zuerst 5 Tipps für bessere Prompts und CLAUDE.md Best Practices.
Tool-Verhalten ändert sich, deshalb gehören Funktionsaussagen an offizielle Quellen. Für Claude Code nutze Claude Code overview, Memory und Anthropic prompt engineering overview. Für Codex nutze OpenAI Codex docs und AGENTS.md guidance.
Fortgeschritten heißt Arbeitsvertrag
Ein schwacher Prompt ist nicht nur kurz. Er hat keine Entscheidungskriterien, keinen klaren Nicht-anfassen-Bereich, keine Definition von fertig und keine Beweisanforderung. Dann muss der Agent raten.
Ein praktischer Prompt funktioniert wie ein kleiner Arbeitsvertrag.
| Teil | Inhalt | Fehler ohne diesen Teil |
|---|---|---|
| Goal | Gewünschtes Ergebnis | Die Antwort wirkt passend, löst aber das falsche Problem |
| Scope | Was geändert werden darf und was nicht | Unrelated Refactors landen im Diff |
| Context | Docs, ähnlicher Code, offizielle Links | Alte Muster oder erfundene Annahmen werden genutzt |
| Constraints | Regeln und verbotene Änderungen | Dependencies, APIs oder Ton ändern sich |
| Acceptance criteria | Wie fertig bewertet wird | Review wird Geschmackssache |
| Verification | Befehle und manuelle Checks | Arbeit endet ohne Nachweis |
Anthropics Prompt-Engineering-Überblick startet mit Erfolgskriterien und empirischen Tests. Für Coding Agents ist das noch wichtiger, weil Claude Code und Codex Dateien lesen, bearbeiten und Befehle ausführen können, bevor ein Ergebnis wirklich geprüft ist.
Prompt Packet als Datei speichern
Eine lange Anweisung jedes Mal in den Chat zu tippen ist schwer zu prüfen und schlecht wiederverwendbar. Eine Datei wie prompt-packet.md macht die Aufgabe stabil. Das folgende Bash-Beispiel erzeugt ein minimales Paket.
cat > prompt-packet.md <<'EOF'
# Goal
Improve one published article so it is practical, accurate, and ready for review.
# Scope
May edit:
- site/src/content/blog/example-article.mdx
Do not edit:
- heroImage
- slug
- unrelated articles
- package or deployment files
# Context to read
- AGENTS.md
- site/src/content/blog/claude-md-best-practices.mdx
- Official docs relevant to the article topic
# Constraints
- Preserve existing frontmatter keys unless this task explicitly changes them.
- Use copy-pasteable examples, not pseudocode.
- Avoid unsupported claims. Link to official docs for tool behavior.
- Keep paragraphs short enough for mobile reading.
# Acceptance criteria
- updatedDate is 2026-06-02.
- The article has at least three concrete use cases.
- The article names specific pitfalls and how to avoid them.
- The article includes an internal link, an official external link, and a natural CTA.
- The final section explains what was actually verified.
# Verification
- node scripts/check-code-fences.mjs
- node scripts/check-updated-article-quality.mjs
- Read the diff once as a critical reviewer.
# Return format
- Changed files
- Key improvements
- Checks run
- Residual risks
EOF
Gib dem Agent danach eine kurze Anweisung: “Lies zuerst prompt-packet.md, prüfe die Zieldatei und den gelisteten Kontext, und arbeite nur innerhalb des Scope.” Das ist keine Bürokratie. Es verhindert, dass der Agent aus Hilfsbereitschaft Nachbarseiten, Bilder, Konfigurationsdateien oder fremden Code verändert.
Prompt vor Nutzung prüfen
Prompts sind Prosa, also kann Qualität driften. Ein kleiner Checker erkennt fehlende Struktur. Speichere ihn als check-prompt-packet.cjs.
// save as check-prompt-packet.cjs
const fs = require("node:fs");
const file = process.argv[2] || "prompt-packet.md";
const text = fs.readFileSync(file, "utf8");
const required = [
"# Goal",
"# Scope",
"# Context to read",
"# Acceptance criteria",
"# Verification",
"# Return format",
];
const missing = required.filter((heading) => !text.includes(heading));
const hasDoNotTouch = /do not (edit|change|touch)/i.test(text);
const hasCommand = /npm run|npm test|pnpm |yarn |node scripts\//i.test(text);
if (missing.length || !hasDoNotTouch || !hasCommand) {
console.error("Prompt packet is not ready.");
if (missing.length) console.error("Missing headings: " + missing.join(", "));
if (!hasDoNotTouch) console.error("Add an explicit do-not-touch boundary.");
if (!hasCommand) console.error("Add at least one verification command.");
process.exit(1);
}
console.log("Prompt packet looks actionable.");
So führst du ihn aus:
node check-prompt-packet.cjs prompt-packet.md
Der Check ist bewusst klein. In Masas Artikelbetrieb entstanden die häufigsten Fehler, wenn “nicht anfassen” oder der finale Nachweis fehlten. In Produktcode ist es identisch: Ohne Definition von fertig entscheidet der Reviewer nach Gefühl.
Vage Ziele in Akzeptanzkriterien übersetzen
“Mach es besser”, “stärkeres SEO” und “production ready” sind sinnvolle Absichten, aber nicht prüfbar. Schreibe sie als Kriterien, die bestehen oder scheitern können.
Schwacher Prompt:
Verbessere diesen Artikel und stärke SEO.
Nützlicher Prompt:
Schreibe den Artikel als praktischen Guide für Entwickler um, die mit Claude Code starten.
Acceptance criteria:
- Der Titel enthält "Claude Code" und "prompt engineering".
- Die description ist unter 120 Zeichen.
- Der Body enthält mindestens drei konkrete Use Cases.
- Es gibt mindestens zwei schlechte Prompt-Beispiele und zwei verbesserte Versionen.
- Der Artikel verlinkt offizielle Docs und passende interne Artikel.
- Der letzte Abschnitt sagt, was tatsächlich geprüft wurde.
- Führe nach dem Edit den Code-Fence-Check aus und berichte das Ergebnis.
Für Implementierung werden die Kriterien technischer.
Acceptance criteria:
- Public API type nicht ändern.
- Validierung und sichtbare Fehlermeldungen ergänzen.
- Mindestens einen Failure-Path-Test hinzufügen oder aktualisieren.
- npm test und npm run build ausführen und Ergebnisse berichten.
- Geänderte Dateien und geprüfte, aber unveränderte relevante Dateien erklären.
Akzeptanzkriterien sind keine Mikrokontrolle. Sie teilen den Review-Standard vor Beginn der Arbeit.
Kontextbudget steuern
Die Memory-Dokumentation von Claude Code erklärt, dass CLAUDE.md und auto memory als Kontext geladen werden, nicht als erzwungene Konfiguration. Länger ist nicht automatisch besser. Lange Regeln können die wichtigste Regel verdecken.
Nutze drei Kontextebenen.
| Ebene | Beispiele | Bester Ort |
|---|---|---|
| Immer nötig | Build-Befehle, Namensregeln, verbotene Bereiche | CLAUDE.md oder AGENTS.md |
| Task-spezifisch | Zieldatei, ähnlicher Code, Qualitätsmaßstab | prompt-packet.md |
| Nur bei Bedarf | Lange Specs, alte Meeting Notes, Rohlogs | Datei nennen, nicht alles einfügen |
Der typische Fehler ist Materialdumping. Wenn Meeting Notes, alte Entwürfe, Logs und aktuelle Aufgabe zusammenkommen, muss der Agent Priorität erraten. Schreibe stattdessen die Lesereihenfolge.
Context to read in order:
1. AGENTS.md for project rules.
2. The target article.
3. One similar high-quality article for tone and structure.
4. Official docs only for tool behavior.
Ignore:
- Old brainstorming notes unless they contradict the current implementation.
- Unrelated product pages.
- Generated files and build output.
Das spart Exploration. Bei paralleler Arbeit schützt es auch fremde Dateien, weil sichtbare Dateien nicht automatisch editierbar sind.
Beispiele und Constraints trennen
Beispiele zeigen das gewünschte Muster. Constraints definieren Grenzen. Wenn du beides vermischst, wird der Prompt unscharf.
Schwacher Prompt:
Mach diese Seite wie den Productivity-Tips-Artikel.
Besser:
Reference style:
- Use site/src/content/blog-de/claude-code-productivity-tips.mdx only for section density and CTA placement.
- Do not copy its examples or claims.
Constraints:
- Keep this article focused on prompt engineering.
- Do not introduce pricing claims.
- Preserve heroImage and slug.
Schreibe nicht nur “nichts kaputt machen”. Gib auch die positive Grenze. “Keine Libraries hinzufügen” wird zu “nur vorhandene Dependencies verwenden”. “Nicht zu viel ändern” wird zu “nur die gelistete Datei editieren und Public API behalten”.
Sichere Iterationsschleife anfordern
Für ernsthafte Arbeit ist ein riesiger Einzelprompt weniger zuverlässig als eine klare Schleife.
- Ziel, Regeln und nächstes gutes Beispiel lesen.
- Kurz den Plan nennen.
- Nur im Scope editieren.
- Mit Befehlen und manueller Prüfung verifizieren.
- Änderungen, Belege und Risiken berichten.
So kann es im Prompt stehen.
Workflow:
- First inspect the target file and the nearest quality reference.
- If the change is larger than two files, explain the plan before editing.
- Edit only the files listed in Scope.
- After editing, run the Verification commands if feasible.
- End with a verification receipt, not a general summary.
Eine Verification Receipt ist der Arbeitsbeleg. Das volle Muster steht im Verification-Receipt-Guide, aber die Minimalform reicht im Alltag.
Verification receipt:
- Changed files:
- Commands run:
- Results:
- Manual checks:
- Could not verify:
- Residual risks:
Vier konkrete Use Cases
Der erste Use Case ist Bugfixing. Übergib Symptom, Repro-Schritte, erwartetes Verhalten, Logs und erlaubte Dateien. Bitte den Agent, die wahrscheinliche Ursache vor dem Edit zu erklären, dann den kleinsten Fix zu machen und einen Failure-Path-Test hinzuzufügen. Das verhindert kosmetische Fixes.
Der zweite Use Case ist ein kleines Feature. Beschreibe sichtbare Änderung, ob API oder Datenbank geändert werden dürfen, welches UI-Muster gilt und welche Tests den Erfolg beweisen. Für ein Kategorie-Feld im Kontaktformular gehören Optionen, Validierung, Payload, Analytics Event und Lokalisierung in die Kriterien.
Der dritte Use Case ist Artikel-Redaktion. Übergib Leser, Suchintention, Ziellänge, Pflichtbeispiele, Fehlerfälle, interne Links, CTA und offizielle Quellen. Bei ClaudeCodeLab verhindert das, dass ein dünner Artikel nur zu einer glatteren Zusammenfassung wird.
Der vierte Use Case ist Code Review. Ein Review-Prompt braucht vor allem Ausgabeformat. Fordere Severity, Datei und Zeile, Repro-Bedingung, Fix-Richtung und fehlende Tests. Statt “alles prüfen” priorisiere Security, Datenverlust, Public API Changes und ungetestete Fehlerpfade.
Häufige Fehler
Fehler 1: Ziele mischen. “Refactor, schneller machen, SEO verbessern und CTA ändern” sind mehrere Jobs. Ein Packet sollte ein Ziel haben.
Fehler 2: Nur Verbote schreiben. “Nichts kaputt machen” sagt nicht, was erlaubt ist. Kombiniere verbotene und erlaubte Bereiche.
Fehler 3: Altes Wissen als offizielles Verhalten behandeln. Claude Code, Codex, memory, settings und AGENTS.md können sich ändern. Verlinke offizielle Docs und behaupte nicht mehr als dort steht.
Fehler 4: Verifikation optional machen. Wenn ein Befehl nicht läuft, soll der Agent das melden. Schweigen ist schlechter als ein benannter Prüfrest.
Fehler 5: Gute Prompts im Chat lassen. Funktionierende Anweisungen gehören in prompt-packet.md, CLAUDE.md oder eine Team-Review-Checkliste. Für Übergaben passt der Artikel zu Team-Handoff-Regeln.
CTA: erst standardisieren, dann skalieren
Du musst dieses Packet nicht jeden Tag neu schreiben. Starte mit der kostenlosen Cheatsheet für tägliche Checks, vergleiche wiederverwendbare Materialien unter Produkte und Templates, und nutze Claude Code Training oder Beratung, wenn dein Team CLAUDE.md, Permissions, Reviews, Verification Receipts und Artikelqualität für ein echtes Repository strukturieren will.
Was ich geprüft habe
Für diesen Artikel habe ich im offiziellen Claude Code overview geprüft, dass Claude Code Codebases lesen, Dateien bearbeiten und Befehle ausführen kann. In Memory habe ich die Unterscheidung zwischen CLAUDE.md, auto memory und erzwungener Konfiguration geprüft. Im Anthropic prompt engineering overview habe ich die Voraussetzung bestätigt, Erfolgskriterien und Tests vor der Prompt-Optimierung festzulegen. Den Codex-Teil habe ich mit OpenAI Codex docs und AGENTS.md guidance abgeglichen. Die praktische Schlussfolgerung: Prompts als überprüfbare Arbeitsverträge behandeln, nicht als einmalige Chatnachrichten.
Kostenloses PDF: Claude-Code-Cheatsheet
E-Mail eintragen und eine Seite mit Befehlen, Review-Gewohnheiten und sicheren Workflows herunterladen.
Wir schützen Ihre Daten und senden keinen Spam.
Über den Autor
Masa
Engineer für praktische Claude-Code-Workflows und Team-Einführung.
Ähnliche Artikel
Claude-Code-Permission-Receipt: Scope, Beweis und Rollback festhalten
Permission-Receipt für Claude Code: erlaubte Aktionen, Freigabegrenzen, Prüfbefehle, Rollback und Umsatz-CTA-Prüfung.
Sicheres Agent Harness fur Claude Code und Codex: Rechte, Prufung und Rollback
Ein praktisches Agent Harness fur Claude Code und Codex mit Policy, Plan, Verifikation und Recovery.
Claude Code Subagents: Praxisleitfaden für sichere Agent-Delegation
Claude Code Subagents praktisch nutzen: Artikel- und Codearbeit sicher aufteilen, Prompts einsetzen, Fehler vermeiden.