trailofbits/goal-prompt

Ziel-Prompt

/goal sorgt dafür, dass der Agent arbeitet, bis eine Abschlussbedingung erfüllt ist. Sowohl Claude Code als auch Codex akzeptieren den Befehl als eine Zeile mit maximal 4.000 Zeichen. In Claude Code beurteilt ein kleines Modell die Bedingung nach jeder Interaktion erneut, nur anhand des Transkripts – es kann keine Befehle ausführen.

Entwerfe eine Bedingung, die terminieren kann, und formatiere sie dann. Ein Ziel ist für Arbeiten gedacht, die größer als eine einzelne Interaktion sind und eine überprüfbare Ziellinie haben; verknüpfe kleine Ziele mit einer Überprüfung dazwischen, anstatt ein einziges riesiges Ziel zu schreiben.

Entwurf

Füge die Elemente mit UND zusammen – niemals „oder“, die Schleife nimmt den billigeren Zweig:

1. Endzustand, nicht Aktivität – „alle legacyAuth()-Aufrufe verwenden auth.verify()“, nicht „migriere den Auth-Code“. Eine Aktivität kann man behaupten; ein Endzustand ist wahr oder falsch.
2. Umfang zum Einlesen – die Dateien, das Issue, die Logs oder der Plan, die vor dem Handeln gelesen werden sollen.
3. Angegebene Prüfung – der genaue Befehl und sein beobachtbares Ergebnis („npm test beendet mit 0“), plus eine Anweisung, ihn auszuführen und die Ausgabe zu zeigen; ein Ergebnis, das nie im Transkript landet, existiert für den Bewerter nicht.
4. Invarianten – was sich nicht ändern darf („ohne Änderung von vendor/“), inklusive „schwäche, überspringe oder bearbeite die Prüfungen selbst nicht“.
5. Stoppgrenze oder Blockade-Klausel – „oder stoppe nach 20 Durchläufen“, „bei Blockade stoppe und melde die Blockade“. Ohne eine solche läuft eine falsch formulierte Bedingung endlos; der Formatierer warnt, wenn sie fehlt. (Claude Code setzt den Durchlaufzähler bei Sitzungswiederaufnahme zurück, sodass eine Durchlaufgrenze stillschweigend über Wiederaufnahmen hinweg verlängert wird.)

Halte es klein. Jede Einschränkung verengt den Zustandsraum, den das Modell erkunden kann. Reduziere auf ein einziges terminierendes Kriterium, wenn möglich, verschiebe Umfang und Definitionen in eine referenzierte Datei und entferne Nicht-Ziele – eine Einschränkung verdient ihren Platz nur, wenn sie einen echten einfachen Ausweg schließt.

Benenne bei langen Zielen auch den endgültigen Nachweis (Diff, Bericht, Artefakt) und fordere eine Fortschrittslogdatei – dauerhafter Zustand über Komprimierung und Wiederaufnahme hinweg. Wenn die Kurzbeschreibung 4.000 Zeichen überschreitet, lege die Details in einer GOAL.md ab und referenziere diese Datei aus dem Objective.

Erfinde niemals fehlende Elemente. Fundiere jedes Element in der Anfrage des Benutzers, im Gespräch oder im Repository – schlage nach, anstatt zu raten. Wenn ein Element nicht aus verfügbaren Informationen gefüllt werden kann, optimiere und formatiere dennoch, was der Benutzer bereitgestellt hat, lasse das Element weg und kennzeichne es als fehlend (siehe Format). Ein Ziel mit einer erfundenen Erfolgsbedingung terminiert auf dem falschen Vertrag.

Schlupflöcher schließen

Lies vor dem Formatieren den entworfenen Zustand so, wie es ein faules Modell tun würde: Was ist der billigste Weg, jede Prüfung zu bestehen, ohne die beabsichtigte Arbeit zu erledigen? Schließe die billigsten – bevorzuge die Kombination von Prüfungen, die du bereits hast, gegenüber dem Hinzufügen von Einschränkungen, und zähle nicht jedes vorstellbare Schlupfloch in eine Liste von Nicht-Zielen auf. Die wiederkehrenden Schlupflöcher:

• Löschen oder stubben statt reparieren – „Suche zeigt nichts an“ gilt auch, wenn die Aufrufer weg sind; kombiniere solche Prüfungen mit einer, die beweist, dass die Funktion noch funktioniert.
• Auf einer Teilmenge bestehen – eine Testdatei ausführen, den Suchpfad verengen, Verzeichnisse von der Prüfung ausschließen.
• Die Prüfung austricksen – Tests überspringen/xfailen, erwartete Ausgaben fest codieren, Testeingaben spezialisieren, die Prüfung selbst bearbeiten (die Invariantenregel).
• Behaupten ohne Ausführen – „erledigt“ oder „blockiert“ erklären, ohne Prüfausgabe im Transkript (die Regel „zeige die Ausgabe“).

Die gleiche Disziplin wie oben: Ein Schlupfloch, das du nicht aus verfügbaren Informationen schließen kannst, kommt in die Liste Fehlend: als Warnung – eine erfundene oder absurde Einschränkung ist schlimmer als eine gekennzeichnete Lücke.

Sicherheitsforschungsziele

Reduziere Auditziele auf ein einziges terminierendes Kriterium, wie das Identifizieren, Auslösen und Validieren einer hochkritischen Schwachstelle, die unter einem referenzierten Bedrohungsmodell-Datei gültig ist. Diese Datei, nicht das Ziel, trägt Umfang, Angreiferfähigkeiten, Schweregrad-Baseline und bekannte Erkenntnisse zum Überspringen. Verwende neutrale Formulierungen („auslösen und validieren“, nicht „beweise, dass dies ausnutzbar ist“), erfordere nachgewiesene Vorbedingungen – angenommener Angreiferzugriff ist der häufigste Fehlalarm – und stoppe nach jedem Fund für eine menschliche Überprüfung, anstatt ungeprüfte Berichte anzuhäufen. Validiere Funde mit einem zweiten Durchlauf eines frischen Agenten, niemals des Entdeckers allein.

Format

Führe uv run --no-project {baseDir}/scripts/format_goal_prompt.py --fenced auf dem Entwurf aus (Datei oder stdin). Es reduziert Leerzeichen auf eine Zeile, entfernt /goal-Präfixe, Anführungszeichen und Codeblöcke, warnt bei fehlender Stoppklausel und lehnt Ausgaben über 4.000 Zeichen ab – kürze oder verschiebe Details in eine Datei und führe erneut aus.

Gib genau einen umschlossenen text-Block zurück, eine Zeile:

/goal <einzelnes normalisiertes Objective>

Füge keinen Prosa drum herum hinzu – es sei denn, Checklistenelemente konnten nicht fundiert werden: dann folge dem Block mit einer Fehlend:-Liste, eine Zeile pro Lücke, die dem Benutzer mitteilt, was er bereitstellen soll.

Beispiel

Entwurf:

/goal Migriere das Auth-Modul:
  - ersetze legacyAuth() durch auth.verify()
  - stelle sicher, dass die Tests noch funktionieren

Überarbeitet und formatiert:

/goal Alle legacyAuth()-Aufrufstellen verwenden auth.verify(): `rg "legacyAuth\\(" -t ts` gibt nichts aus UND `npm test` beendet mit 0 (beide ausführen, Ausgabe zeigen), ohne Änderung von vendor/ oder Abschwächung eines Tests. Bei Blockade stoppe und melde versuchte Pfade und die Blockade, oder stoppe nach 20 Durchläufen.

Hier stammt npm test aus der package.json des Repositorys – keine Schätzung – und die Kombination mit der Null-Treffer-Prüfung schließt das billigste Schlupfloch: Löschen der Aufrufstellen anstatt deren Migration. Wenn nichts ein Element fundiert, formatiere, was existiert, und kennzeichne die Lücken:

Entwurf: mache Checkout schneller, ohne Metrik oder Benchmark im Kontext:

/goal Mache Checkout schneller

Fehlend:

• messbarer Endzustand – welche Metrik und welcher Schwellenwert gelten als „schneller“
• Verifikation – der Benchmark oder Befehl, der es beweist
• Stoppgrenze – z. B. „oder stoppe nach 20 Durchläufen“