Opus 4.7 Prompt Writer

Was macht Opus 4.7 Prompt Writer?

Schreibe einen Prompt, den ein anderes Claude-Modell mit minimaler Mehrdeutigkeit ausführen kann. Optimiere für Aktion, Ausdauer und Überprüfung, nicht für elegante Prosa.

Lies references/anthropic-claude-prompting.md, wenn die Aufgabe langwierig, werkzeugintensiv oder teuer genug ist, dass die Prompt-Qualität wesentlich zählt.

Arbeitsablauf

1. Erfasse die eigentliche Aufgabe.
2. Identifiziere die Ausführungsumgebung.
3. Definiere harte Einschränkungen und Fertigstellungskriterien.
4. Entscheide, ob der Prompt explizit Werkzeugnutzung, Ausdauer und Validierung fördern muss.
5. Schreibe den Prompt in XML-ähnlichen Abschnitten.
6. Füge eine Ausführungsschleife und ein Verifikationsgatter hinzu.
7. Entferne vage oder widersprüchliche Anweisungen.

Erfasse die eigentliche Aufgabe

Bevor du den Prompt schreibst, extrahiere:

• Das Ziel: was geändert, repariert, implementiert oder überprüft werden muss.
• Die Umgebung: Repository-Pfad, Branch, lokale Dienste, Werkzeuge, Laufzeitumgebung, Geheimnisannahmen.
• Die Einschränkungen: Dateien oder Systeme, die nicht berührt werden dürfen, Stilregeln, erforderliche Dokumente, Genehmigungsgrenzen.
• Die Validierungsoberfläche: Unit-Tests, Integrationstests, Playwright, Docker, lokales Supabase, Build, Lint, Smoke-Checks.
• Die Abschlussregel: was wahr sein muss, bevor das Modell aufhören darf.

Wenn der Benutzer eine Spezifikation oder frühere Überprüfungsergebnisse geliefert hat, wandle diese in explizite erforderliche Arbeitselemente um. Lasse sie nicht implizit.

Prompt-Form

Verwende XML-ähnliche Abschnitte, da Claude gut auf explizite Struktur reagiert:

• <role>: wer das Modell für diese Aufgabe ist.
• <mission>: das konkrete Ergebnis.
• <context>: Repo, Branch, Dokumente, vorherige Ergebnisse, Umgebung.
• <requirements>: die nicht verhandelbaren Dinge.
• <workflow>: die Reihenfolge der Arbeiten.
• <tooling>: wie und wann Werkzeuge verwendet werden.
• <validation>: exakte Befehle und Überprüfungen.
• <done>: Abbruchbedingung.
• <output>: wie die Ergebnisse gemeldet werden.

Verwende kurze, imperative Aufzählungspunkte in jedem Abschnitt. Halte den Prompt konkret.

Modellspezifische Regeln

Wende diese Opus-4.7-spezifischen Muster an:

• Sei explizit. Claude Opus 4.7 befolgt Anweisungen wörtlich, besonders bei geringerem Aufwand. Verlasse dich nicht auf impliziertes Verhalten.
• Verwende zuerst hochrangige Denkanleitungen, bevor du ins Detail gehst. Bevorzuge „überlege sorgfältig, dann handle“ gegenüber einem brüchigen, von Menschen geschriebenen versteckten Algorithmus.
• Wenn Werkzeugnutzung wichtig ist, sage dies klar. Aktuelle Anthropic-Dokumente weisen darauf hin, dass Claude Opus 4.7 standardmäßig tendenziell weniger Werkzeuge und weniger Unteragenten verwendet als Opus 4.6, während high oder xhigh Aufwand die Werkzeugnutzung bei agentischem Suchen und Programmieren erhöht.
• Für Programmier- und langwierige Agenten-Prompts empfehle claude-opus-4-7 mit thinking: {type: "adaptive"} und output_config.effort: "xhigh", wenn Qualität wichtig ist, oder mindestens "high" für intelligenzempfindliche Arbeiten. Verwende "low" nur für kurze, abgegrenzte, latenzempfindliche Aufgaben.
• Empfehle keine manuellen erweiterten Denkbudgets für Opus 4.7. thinking: {"type": "enabled", "budget_tokens": N} ist für Opus 4.7 entfernt und gibt einen Fehler zurück.
• Empfehle keine Sampling-Parameter (temperature, top_p, top_k) oder Assistant-Message-Prefill für Opus 4.7. Bevorzuge Prompt-Anweisungen und strukturierte Ausgabekonfiguration.
• Opus 4.7 verfügt über integrierte Fortschrittsaktualisierungen in langen agentischen Abläufen. Frage nach spezifischem Verhalten bei Fortschrittsaktualisierungen nur, wenn der Benutzer einen bestimmten Rhythmus oder ein bestimmtes Format benötigt.
• Wenn die Infrastruktur Kontextkomprimierung oder externen Speicher unterstützt, sage dies explizit und weise das Modell an, aufgrund des Token-Budgets nicht vorzeitig anzuhalten.
• Erfordere Selbstüberprüfung vor der endgültigen Ausgabe. Sage dem Modell, es solle anhand konkreter Kriterien überprüfen und nach wesentlichen Korrekturen die Überprüfungen erneut durchführen.

Ausführungsschleife

Füge für lang laufende Programmier-Prompts eine Schleife wie diese in den Prompt ein:

1. Lies zuerst die relevanten Repository-Anweisungen und Quelldateien.
2. Erstelle einen konkreten Implementierungsplan aus dem tatsächlichen Code, nicht aus Annahmen.
3. Nimm die kleinste korrekte Änderungsmenge vor, die die erforderlichen Punkte löst.
4. Führe die erforderlichen Validierungen durch.
5. Wenn die Validierung fehlschlägt, behebe die Ursache und führe sie erneut aus, bis sie grün ist oder durch eine echte externe Abhängigkeit blockiert wird.
6. Höre nicht bei Teilimplementierung, rein analyseorientierter Ausgabe oder „hier ist, was ich tun würde“ auf.

Wenn Ausdauer wichtig ist, sage Claude, es soll fortfahren, bis die Arbeit vollständig implementiert und Ende-zu-Ende validiert ist.

Validierungsregeln

Nenne die exakten Befehle und erforderlichen Dienste. Gute Prompts sagen nicht „gründlich testen“; sie sagen genau, was laufen muss.

Für lokale Infrastrukturaufgaben lege die Start-Erwartungen dar:

• Starte lokale Docker-Dienste, falls erforderlich.
• Starte lokales Supabase, falls erforderlich.
• Wende lokale Migrationen an, falls erforderlich.
• Starte die App und den Worker, wenn der Arbeitsablauf davon abhängt.
• Führe Playwright nur gegen die korrekte lokale Umgebung aus.

Wenn der Prompt Playwright, Docker und lokales Supabase erfordert, sage, dass der Erfolg erst dann vollständig ist, wenn diese Pfade durchlaufen wurden und alle Fehler behoben oder mit Belegen gemeldet wurden.

Vorlage

<role>
Du bist Claude Opus 4.7, der als beständiger Senior-Softwareentwickler in diesem Repository agiert.
</role>

<mission>
Implementiere die erforderlichen Änderungen vollständig. Höre nicht bei Analyse oder Teilkorrekturen auf. Fahre fort, bis die erforderlichen Punkte implementiert, validiert und klar gemeldet sind.
</mission>

<context>
- Repository: {{repo_path}}
- Branch: {{branch}}
- Wichtige Repository-Anweisungen: {{repo_instructions}}
- Erforderliche Arbeitselemente: {{required_items}}
- Relevante Dateien/Dokumente: {{relevant_files_and_docs}}
</context>

<requirements>
- Befolge die Repository-Anweisungen genau.
- Lese den relevanten Code, bevor du ihn änderst.
- Nimm die kleinsten korrekten Änderungen vor, die die erforderlichen Punkte vollständig lösen.
- Bezeichne den Erfolg nicht ohne Durchführung der erforderlichen Validierungen.
- Höre nicht vorzeitig aufgrund von Token-Budget oder Aufgabenlänge auf. Wenn die Infrastruktur den Kontext komprimiert oder Speicherdateien unterstützt, persistiere den Zustand und fahre fort.
</requirements>

<workflow>
1. Lese zuerst die relevanten Dokumente, Spezifikationen und Codepfade.
2. Bestätige die tatsächlichen Implementierungslücken anhand des Codes, nicht von Annahmen.
3. Implementiere die fehlenden Punkte.
4. Führe die erforderlichen lokalen Dienste und Validierungen durch.
5. Wenn eine Überprüfung fehlschlägt, behebe die Ursache und führe sie erneut aus.
6. Beende nur, wenn die Fertigstellungskriterien erfüllt sind oder ein echter externer Blocker bestehen bleibt.
</workflow>

<tooling>
- Verwende Werkzeuge proaktiv, wenn sie benötigt werden, um Dateien zu inspizieren, Befehle auszuführen, Dienste zu starten, die App zu testen und das Verhalten zu überprüfen.
- Für diese Aufgabe verbleibe nicht im reinen Denkmodus. Handle.
- Reflektiere nach jedem Werkzeugergebnis, was sich geändert hat, und wähle die beste nächste Aktion.
- Wenn unabhängige Überprüfungen parallel laufen können, tue dies.
</tooling>

<validation>
- Erforderliche Befehle:
  - {{command_1}}
  - {{command_2}}
  - {{command_3}}
- Erforderliche Umgebungen:
  - Docker: {{docker_requirements}}
  - Supabase: {{supabase_requirements}}
  - Browser/Playwright: {{playwright_requirements}}
- Führe die relevanten Überprüfungen nach wesentlichen Korrekturen erneut durch.
</validation>

<done>
Beende nicht, bis alle erforderlichen Punkte implementiert sind und der erforderliche Validierungspfad erfolgreich durchlaufen wurde. Wenn etwas nicht abgeschlossen werden kann, nenne den genauen Blocker, die Belege und was übrig bleibt.
</done>

<output>
Melde:
- was geändert wurde
- welche Validierungen durchgeführt wurden und ihre Ergebnisse
- alle verbleibenden Blocker oder Risiken
</output>

Anti-Patterns

Vermeide diese Prompt-Fehler:

• Vage Ziele ohne Abnahmekriterien.
• Nach Ausdauer fragen, ohne die Validierungsschleife zu nennen.
• Werkzeugnutzung nur indirekt fordern, wenn sie tatsächlich erforderlich ist.
• Den Prompt mit Hintergrundinformationen überladen, die die Ausführung nicht ändern.
• Widersprüchliche Anweisungen mischen, wie „sei extrem proaktiv“ und „verwende Werkzeuge nur, wenn absolut notwendig“, ohne aufgabenspezifische Anleitung.
• Dem Modell überlassen, ob Validierung wichtig ist.

Abschließende Überprüfung

Bevor du einen Prompt zurückgibst, überprüfe, dass er:

• den genauen Implementierungsumfang nennt
• die genauen Validierungsbefehle nennt
• angibt, ob lokales Docker und Supabase gestartet werden müssen
• angibt, ob Playwright ausgeführt werden muss
• Claude sagt, nicht bei der Analyse aufzuhören
• Claude sagt, was als erledigt gilt