Goal-Instruktion-Verfasser

Was macht Goal-Instruktion-Verfasser?

Verwandeln Sie eine vage Anfrage in eine fertige Goal-Instruktion, die ein Agent ausführen kann, ohne raten zu müssen, was Erfolg, Fortschritt oder Abbruch bedeutet. Bewahren Sie die Absicht, Sprache, Autoritätsgrenzen und den angeforderten Umfang des Benutzers. Diese Fertigkeit entwirft und prüft den Instruktionsvertrag; Laufzeitzugriff, Berechtigungen und externe Genehmigungen verbleiben beim Host-Agenten und Benutzer. Beschreiben Sie die Prüfungen beim Schreiben einer Goal-Instruktion; führen Sie die zugrunde liegende Aufgabe nur aus, wenn der Benutzer auch die Ausführung angefordert hat.

Lesen Sie references/goal-contract.md beim Entwerfen oder Prüfen einer Goal-Instruktion. Lesen Sie references/examples.md nur, wenn ein durchgearbeitetes Beispiel die angeforderte Aufgabe verdeutlichen würde. Für Arbeiten, die mehrere Phasen, Artefakte oder mehr als wenige Iterationen umfassen, lesen Sie auch references/drift-control.md. Für Vorschau-zuerst-Arbeitsabläufe lesen Sie references/loop-preview.md.

Wählen Sie den Modus

• Entwurf: Erstellen einer Goal-Instruktion aus einer groben Anfrage.
• Verfeinerung: Bewahren einer bestehenden Goal-Instruktion, während fehlende Ziel-, Nachweis-, Schleifen- oder Beendigungsfelder geschlossen werden.
• Prüfung: Identifizieren von Mehrdeutigkeiten, unbegrenzten Wiederholungen, nicht überprüfbaren Kriterien und unsicheren oder nicht autorisierten Übergängen; die kleinstmöglichen Korrekturen vorschlagen.
• Konvertierung: Umwandeln einer Checkliste, eines Tickets oder einer Projektbeschreibung in eine Goal-Instruktion, ohne deren Umfang zu erweitern.
• Vorschau: Anzeigen der konkreten Schleife, Verzweigungen, Driftgates und Stopp- Bedingungen vor dem Schreiben der endgültigen Goal-Instruktion. Geben Sie in diesem Modus keine ausführbare Goal-Instruktion aus und führen Sie keine externen Arbeiten durch.

Wenn der Modus nicht angegeben ist, leiten Sie ihn aus der Eingabe ab. Stellen Sie nur Fragen, deren Antworten das Ziel, die Autorität, die Akzeptanzkriterien oder den rechtlichen Endzustand ändern würden. Andernfalls nennen Sie die Annahmen und fahren fort.

Vorschau vor dem Entwurf

Verwenden Sie Vorschau-zuerst, wenn der Benutzer nach “先看循环”, “preview”, “先设计流程” oder ähnlichem fragt. Bevorzugen Sie dies auch für mehrstufige, kostspielige, irreversible oder materiell unsichere Arbeiten. Für eine kurze, reversible Aufgabe reicht ein direkter Entwurf.

Die Vorschau ist ein Design-Checkpoint, keine Genehmigung zur Ausführung:

1. Nennen Sie das vorläufige Ergebnis, die Basislinie und die Annahmen.
2. Zeigen Sie die Schleife als konkrete Zustandsübergänge, einschließlich der ersten Arbeitseinheit, Erfolgs- und Fehlerverzweigungen, Fortschrittsnachweise, Driftprüfungen, Phasengates und rechtmäßige Stoppzustände. Unterscheiden Sie Iterationsprüfungen von breiteren Phasen- oder Lieferprüfungen, einschließlich Nachweiswiederverwendung und Grenzen für teure Prüfungen.
3. Listen Sie die Entscheidungen auf, die die Schleife oder ihren Umfang ändern könnten. Für Feedback-, Einführungs-, Pilot-, Launch- oder Validierungsarbeiten schließen Sie die Nachweisschwelle ein, was zählt, und das Feedback-Zeitfenster.
4. Enden Sie mit einer klaren Übergabe: Warten Sie auf die Bestätigung oder Überarbeitung der Schleife durch den Benutzer, bevor Sie die endgültige Goal-Instruktion generieren.

Wenn der Benutzer bestätigt, übernehmen Sie die akzeptierte Vorschau in die endgültige Goal-Instruktion, ohne stillschweigend deren Schleife, Umfang oder Endregeln zu ändern. Wenn der Benutzer sie überarbeitet, generieren Sie die Vorschau neu oder dokumentieren Sie die geänderte Entscheidung zuerst. Eine Vorschau-Antwort muss nicht behaupten, dass die Goal-Instruktion vollständig ist, und darf keine externen Nebenwirkungen ausführen, nur weil eine Schleife beschrieben wurde.

Erstellen Sie den dreischichtigen Vertrag

1. Goal: Definieren Sie das Ergebnis

Schreiben Sie einen Satz mit einem beobachtbaren Endzustand. Er sollte sagen, welches Artefakt, Verhalten, welche Entscheidung oder welche verifizierte Änderung vorhanden sein wird, wenn die Arbeit abgeschlossen ist. Machen Sie dann den Vertrag konkret:

• Basislinie: Was existiert jetzt und welche Version, Quelle oder Fakten sind maßgeblich.
• Umfang: Was darf sich ändern und was ist eingefroren.
• Akzeptanzkriterien: Beobachtbare Prüfungen, die an Nachweise gebunden sind, nicht an Aktivitäten wie „weiterarbeiten“ oder „sich mehr anstrengen“.
• Abhängigkeiten und Autorität: Werkzeuge, Zugriff, Eigentümerentscheidungen und externe Gates, die der Agent überschreiten darf oder nicht.
• Liefergegenstand: Die Dateien, die Entscheidung, der Bericht oder die Nachricht, die zurückgegeben wird.

Für Goals zu Feedback, Einführung, Piloten, Launches oder Validierung definieren Sie eine Feedback-Nachweisschwelle, bevor Sie einen Entwurf erstellen: Was zählt als Feedback, ob ein Einstiegspunkt ausreicht oder mindestens N Nicht-Autoren-Antworten erforderlich sind, und das Zeitfenster oder der Versuchsrahmen. Zählen Sie keine autorennur-Aktivitäten, es sei denn, der Benutzer wählt diese Schwelle explizit.

Bevorzugen Sie ein tragendes Ergebnis pro Goal. Teilen Sie nicht zusammenhängende Ergebnisse in separate Goals auf. Ersetzen Sie vage Verben wie „verbessern“, „behandeln“ oder „abschließen“ durch ein messbares Ergebnis.

Drift bei langlebigen Arbeiten verhindern

Frieren Sie für eine lange oder mehrstufige Goal-Instruktion einen kompakten Goal-Anker vor der ersten Iteration ein: das Ein-Satz-Ergebnis, Kriterien-IDs, eingefrorener Umfang und aktuelle Phase. Behandeln Sie ihn als Invariante. Eine neue Entdeckung kann die Pläne ändern, darf aber nicht stillschweigend das Ergebnis, die Akzeptanzkriterien oder die Autorität ändern. Eine explizite Eigentümerentscheidung erstellt eine neue Goal-Version oder einen Umfangsänderungsdatensatz.

Zeichnen Sie bei jeder Iteration vor dem Handeln drei Links auf:

1. Zielkriterium: Welches Akzeptanzkriterium diese Arbeit voranbringt.
2. Erwartetes Delta: Welcher beobachtbare Nachweis sollte sich ändern, wenn es funktioniert.
3. Umfangsbegründung: Warum diese Aktion jetzt innerhalb der eingefrorenen Grenze liegt.

Klassifizieren Sie das Ergebnis nach der Verifizierung als:

• ON_TARGET: Das benannte Kriterium hat sich bewegt und die Nachweise unterstützen den nächsten Schritt.
• SIDE_QUEST: Nützlich, aber für dieses Goal nicht erforderlich; parken Sie es in einer zurückgestellten Liste, anstatt die Schleife zu erweitern.
• DRIFTED: Kein Kriterium hat sich bewegt, die Aktion hat das Ziel oder den Umfang geändert, oder der nächste Schritt kann nicht vom Anker aus gerechtfertigt werden; Stopp und Neuausrichtung.

Führen Sie standardmäßig alle 3–5 Iterationen, bei jedem Meilenstein und vor einer irreversiblen oder kostspieligen Aktion ein Phasengate durch. Lesen Sie den Anker erneut, vergleichen Sie den aktuellen Zustand mit der Basislinie, markieren Sie Kriterien als offen oder verifiziert, überprüfen Sie zurückgestellte Seitenaufgaben und wählen Sie eine gerechtfertigte nächste Aktion. Ändern Sie niemals Kriterien, um abgeschlossene Arbeiten als auf Ziel erscheinen zu lassen.

2. Schleife: Definieren Sie, wie Fortschritt erzielt wird

Verwenden Sie eine begrenzte Iteration mit einem sichtbaren Fortschrittssignal:

1. Überprüfen Sie den aktuellen Zustand und den letzten langlebigen Cursor.
2. Auswählen der kleinsten nächsten Arbeitseinheit, nennen Sie das Zielkriterium, das erwartete Delta und die Umfangsbegründung.
3. Handeln Sie innerhalb des erlaubten Umfangs und der Autorität.
4. Verifizieren Sie das Ergebnis anhand des relevanten Kriteriums unter Verwendung der unten stehenden Verifizierungsstrategie; erfassen Sie die Nachweise.
5. Klassifizieren Sie das Ergebnis als ON_TARGET, SIDE_QUEST oder DRIFTED und wenden Sie die entsprechende Driftregel an.
6. Aufzeichnen des Deltas, des verbleibenden Abstands, der Entscheidung und des nächsten Cursors, bevor eine weitere Iteration beginnt.

Geben Sie das zur Aufgabe passende Iterationslimit an: eine Zeitbox, ein Werkzeug- oder Token-Budget, maximale Versuche oder eine endliche Arbeitsliste. Fügen Sie eine No-Op-Regel hinzu: Wiederholen Sie nicht die gleiche Aktion ohne neue Informationen; ändern Sie nach einem wiederholten Fehlschlag die Hypothese oder stoppen Sie mit dem Blocker. Die Schleife muss erklären können, warum sich die nächste Iteration von der vorherigen unterscheidet.

Verifizierungsstrategie

Fügen Sie eine kurze Verifizierungsstrategie in die Goal-Instruktion ein. Bewahren Sie explizite Benutzer- und Repository-Akzeptanzanforderungen, während Sie kontrollieren, wann Prüfungen laufen:

• Iterationsprüfungen: Wählen Sie die kleinstmöglichen Prüfungen, die für das betroffene Verhalten ausreichen. Erweitern Sie sie bei Änderungsauswirkungen, neuen Fehlern, ungelöster Unsicherheit oder einem erforderlichen Gate.
• Phasen- und Lieferprüfungen: Nachdem die relevante Implementierung stabil ist, schließen Sie die verbleibenden erforderlichen Regression, Build, Integration und Artefaktprüfungen ab. Ein Phasengate überprüft aktuelle Nachweise; es wiederholt nicht automatisch die gesamte Validierungs- und Lieferpipeline.
• Nachweiswiederverwendung: Binden Sie Ergebnisse an die geprüfte Quelle oder das geprüfte Artefakt, relevante Eingaben, Abhängigkeiten und Umgebung. Tragen Sie Ergebnisse weiter, solange diese Bedingungen gültig bleiben. Dokumentations- oder Empfangsänderungen invalidieren keine nicht zusammenhängenden Laufzeitprüfungen. Unterscheiden Sie wiederverwendete Nachweise von neu durchgeführten Prüfungen.
• Wiederholungsgrund: Vor der Wiederholung einer Prüfung nennen Sie die Änderung oder den neuen Nachweis, der das Ergebnis ungültig macht, und wählen Sie die betroffenen Prüfungen aus. Eine Quell- oder Artefaktänderung invalidiert abhängige Nachweise, einschließlich Verbraucherprüfungen, wenn das konsumierte Artefakt sich ändert.
• Kosten und Abschluss: Geben Sie teuren Prüfungen geeignete Befehls-Timeouts oder Versuchsgrenzen. Ein Timeout lässt das Kriterium unverifiziert; melden Sie den Abstand. Beenden Sie, wenn alle Kriterien gültige Nachweise haben und die Lieferung abgeschlossen ist; weitere Prüfungen benötigen ein konkretes ungelöstes Problem oder ein ungültiges Ergebnis.

3. Terminierung: Definieren Sie rechtliche Endzustände

Machen Sie die Endzustände explizit und gegenseitig verständlich:

• Abgeschlossen: Jedes Akzeptanzkriterium ist verifiziert und das Liefergegenstand ist verfügbar.
• Blockiert: Eine benannte Abhängigkeit, fehlende Autorität oder ungelöster Fehler verhindert die nächste sinnvolle Aktion; melden Sie genau, was zur Entblockung benötigt wird.
• Pausiert: Der Eigentümer bittet explizit um Pause; bewahren Sie den Cursor und setzen Sie nicht ohne Autorisierung fort.
• Zeitlich begrenzt/Budgetiert: Das Limit wird vor Abschluss erreicht; melden Sie den verifizierten Fortschritt, den verbleibenden Abstand und die sicherste nächste Aktion.
• Gestoppt: Der Eigentümer bricht die Arbeit ab oder eine Aktion würde die gewährte Autorität überschreiten; führen Sie nicht stillschweigend fort.
• Neuausrichtung erforderlich: Eine Driftprüfung schlägt fehl; stoppen Sie die aktuelle Schleife, bewahren Sie den Checkpoint und setzen Sie erst fort, nachdem die nächste Aktion neu verankert wurde. Verwenden Sie GOAL PAUSED: Neuausrichtung erforderlich, wenn ein lokales Endzustands-Label benötigt wird.

Verwenden Sie nicht „Weiter bis zufrieden“, „Unbegrenzt versuchen“ oder eine Erfolgsbehauptung, die nur auf Anstrengung basiert. Wenn die Aufgabe eine lokale Konvention für Endzustands-Strings hat, bewahren Sie sie; andernfalls geben Sie jedem Zustand ein kurzes, genaues Label und verlangen Sie, dass die endgültige Antwort es enthält. Ein Ziel oder Akzeptanzkriterium kann nicht geändert werden, nur weil die aktuelle Arbeit schwierig oder interessant geworden ist.

Erzeugen Sie die Antwort

Geben Sie das Ergebnis in der Sprache des Benutzers zurück. Sofern der Benutzer kein anderes Format anfordert, verwenden Sie diese Reihenfolge:

1. Designnotizen: Ein kurzer Absatz, der das Ziel, die Schleife und die Terminierungs- und Driftkontrollentscheidungen erläutert; listen Sie Annahmen oder wertvolle offene Fragen auf.
2. Schleifenvorschau: Im Vorschaumodus zeigen Sie die Zustandsübergänge, Verzweigungen, Nachweise, Driftgates, Endzustände und ungelösten Entscheidungen; stoppen Sie dort und warten Sie auf Bestätigung.
3. Zum Einfügen bereite Goal-Instruktion: Im Entwurfs-, Verfeinerungs- oder Konvertierungsmodus fügen Sie die vollständige Instruktion in einen Code-Block mit den Abschnitten Ziel, Goal-Anker, Basislinie und Umfang, Akzeptanzkriterien, Feedback-Nachweise (falls zutreffend), Verifizierungsstrategie, Ausführungsschleife, Driftkontrolle, Grenzen und No-Op- Regel, Terminierung und Berichterstattung ein.
4. Prüfnotizen: Wenn Sie verfeinern oder prüfen, nennen Sie jede verbleibende Mehrdeutigkeit und die kleinste Änderung, die sie löst.

Der zum Einfügen bereite Block muss als Instruktion ausführbar sein, nicht als Diskussion darüber, wie man eine Instruktion schreiben könnte. Halten Sie Akzeptanzprüfungen und Endzustände konkret genug, dass ein späterer Prüfer sie anhand von Nachweisen entscheiden kann.