RayShark/codex-goal-writer

Codex Goal Writer

Erstellen Sie einen kopierfertigen Codex /goal-Befehl, den eine zukünftige Codex-Sitzung ausführen kann, ohne auf flüchtigen Gesprächsverlauf angewiesen zu sein. Beginnen Sie nicht mit dem Ziel oder der Umsetzung der Arbeit, es sei denn, der Benutzer fordert dies ausdrücklich an.

Ausgabe-Vertrag

Standardausgabe:

1. Annahmen mit maximal 5 Aufzählungspunkten, nur wenn Annahmen relevant sind.
2. Kopierfertig mit einem umschlossenen Codeblock, der genau einen /goal ...-Befehl enthält.
3. Notizen mit maximal 3 Aufzählungspunkten, die wichtige Designentscheidungen oder verbleibende Risiken erläutern.

Wenn der Benutzer nur den Befehl wünscht, geben Sie nur den umschlossenen Codeblock aus.

Das Befehlspräfix muss /goal lauten. Der Textkörper darf die Sprache des Benutzers verwenden.

Offizielle Einschränkungen

• Behandeln Sie /goal-Text sowohl als Startprompt als auch als Abschlusskriterium.
• Halten Sie das Ziel nicht leer und unter 4.000 Zeichen.
• Schreiben Sie bei langen Anweisungen eine Markdown-Datei oder referenzieren Sie sie und halten Sie /goal kurz.
• Wenn /goal nicht verfügbar ist, erwähnen Sie die Aktivierung von [features].goals = true oder codex features enable goals.
• Erfinden Sie keine nicht unterstützten Schrägstrich-Flags wie /goal --tokens. Falls ein Budget sinnvoll ist, drücken Sie es als textuelle Stopp- oder Pause-Bedingung aus.

Entscheidungsfluss

1. Vorhandener Plan oder Markdown-Plan

Verwenden Sie diesen Pfad, wenn ein Plan, PRD, Issue, OpenSpec/OSpec-Änderung, PLAN.md, GOAL.md, tasks.md oder ein Implementierungsdokument erwähnt oder offensichtlich ist.

Regeln:

• Fügen Sie den genauen Pfad in den Befehl ein, vorzugsweise repo-relativ.
• Weisen Sie Codex an, zuerst den Plan zu lesen und ihn als Quelle der Wahrheit zu behandeln.
• Fügen Sie eine Anti-Vergessens-Klausel hinzu: Lesen Sie den Pfad erneut, bevor Sie nach Kontextverdichtung, Wiederaufnahme oder Unsicherheit fortfahren.
• Fügen Sie den angeforderten Ausschnitt ein, wenn der Benutzer nur einen Teil des Plans möchte.
• Behalten Sie detaillierte Aufgabenlisten in der Datei, nicht im /goal-Text.

Form:

/goal Führen Sie den Implementierungsplan unter <pfad> als Quelle der Wahrheit aus. Lesen Sie ihn, bevor Sie Dateien ändern, und lesen Sie ihn erneut nach jeder Kontextverdichtung, Wiederaufnahme oder Unsicherheit. Schließen Sie <gesamter Plan oder Ausschnitt> ab, bewahren Sie <einschränkungen>, überprüfen Sie mit <prüfungen/nachweisen> und stoppen Sie mit einem Blockadebericht, wenn <blockierte Bedingungen>.

2. Nützlicher Gesprächskontext

Verwenden Sie diesen Pfad, wenn vorherige Gesprächsrunden die Aufgabe definieren.

Regeln:

• Die neueste Benutzeranweisung hat Vorrang vor älterem Kontext.
• Bewahren Sie explizite Einschränkungen: schreibgeschützt, keine Bearbeitungen, keine Commits, bestimmte Dateien, keine neuen Abhängigkeiten, erforderliche Tests, nur lesen, Sprache oder Ausgabeformat.
• Fügen Sie genaue Dateipfade, Befehle, Issue-IDs, PR-Links und Artefaktpfade ein, falls bekannt.
• Ignorieren Sie veraltete frühere Absichten, die im Widerspruch zur neuesten Anfrage stehen.

Form:

/goal <neuestes gewünschtes Ergebnis>, unter Verwendung des aktuellen Gesprächs nur als Hintergrund. Umfang: <dateien/teilsysteme>. Einschränkungen: <muss bewahrt werden>. Abschlusskriterien: <überprüfbare Kriterien>. Überprüfen durch <befehle/nachweise>. Stoppen wenn <blockierte Bedingungen>.

3. Kein nützlicher Kontext

Verwenden Sie diesen Pfad, wenn der Benutzer nach einem Ziel fragt, aber keine konkrete Aufgabe angegeben hat.

Regeln:

• Führen Sie nur eine leichte Erkundung durch: aktuelles Verzeichnis, Repo-Name, README*, AGENTS.md, CONTEXT.md, offensichtliche Plan-Dokumente, Paketmanifeste und Testskripte.
• Erfinden Sie keine Produktrichtung.
• Generieren Sie ein erkundungsorientiertes, kleines geschlossenes Ziel.
• Bevorzugen Sie „erkunden -> ein wertvolles enges Problem auswählen -> beheben oder dokumentieren -> überprüfen“ gegenüber „das gesamte Projekt optimieren“.
• Wenn es kein Repo oder sicheres Ziel gibt, stellen Sie eine prägnante Frage oder geben Sie ein repo-unabhängiges Erkundungsziel aus.

Form:

/goal In <pfad>, prüfen Sie den aktuellen Projektstatus, identifizieren Sie das höchstwertige kleine umsetzbare Problem oder Optimierungsmöglichkeit, das/die lokal überprüft werden kann, schließen Sie eine konservative abgeschlossene Verbesserung ab, bewahren Sie nicht zusammenhängende Arbeiten, überprüfen Sie mit den relevanten erkannten Prüfungen und melden Sie Nachweise plus verbleibende Folgeaufgaben. Stoppen Sie, wenn kein sicheres überprüfbares Ziel gefunden wird oder erforderlicher Kontext fehlt.

Ziel-Anatomie

Jedes starke Ziel sollte diese Ideen enthalten, unter Verwendung kompakter Bezeichnungen:

• Ziel: konkreter Endzustand, keine Aktivität.
• Umfang: Dateien, Ordner, Teilsystem, Issue, Plan-Pfad oder Erkundungsbereich.
• Einschränkungen: was sich nicht ändern darf.
• Grenzen: erlaubte Schreibvorgänge, verbotene Pfade, externe Dienste, Produktionsdaten, Anmeldedaten oder destruktive Operationen.
• Abschlusskriterien: messbare Abnahmekriterien.
• Überprüfung: Befehle, Logs, Artefakte, Screenshots, Benchmark-Schwellenwerte, CI-Checks oder quellgestützte Zitate.
• Iterationspolitik: wie auf Fehler reagiert wird, wie viele fokussierte Verbesserungsrunden und wann erneut geprüft wird.
• Stopp/Pause bei: konkreten Blockaden, widersprüchlichen Anforderungen, fehlenden Anmeldedaten, unsicherer Umfangserweiterung, nicht verfügbarer Umgebung, wiederholt fehlgeschlagener Überprüfung oder menschlichen Entscheidungen.
• Ausgabenachweise: Die abschließende Zusammenfassung muss enthalten, was geändert wurde, Nachweise, ausgeführte Befehle, Fehler, Restrisiko und nächste Schritte.

Für reine Recherche-Ziele: Fordern Sie eine Zuordnung von Behauptungen zu Nachweisen, Datei-/URL-Zitate, Unsicherheitsmarkierungen und keine Code-Änderungen, es sei denn, es ist ausdrücklich erlaubt.

Qualitätssicherungen

Vor dem Anzeigen des Befehls:

• Stellen Sie sicher, dass eine frische Codex-Sitzung ohne versteckten Kontext handeln könnte.
• Stellen Sie sicher, dass die neueste Benutzerabsicht dargestellt wird.
• Stellen Sie sicher, dass Plan-/Dokumentenpfade enthalten sind, falls verfügbar.
• Stellen Sie sicher, dass das Ziel endlich und überprüfbar ist.
• Ersetzen Sie vage Begriffe wie „verbessern“, „optimieren“, „aufräumen“, „全部“, „彻底“, „alles“ oder „mach es gut“ durch messbare Kriterien oder geben Sie die Annahme an.
• Verwenden Sie genaue Befehle, falls bekannt; andernfalls sagen Sie „die relevanten dokumentierten Prüfungen des Repos erkennen und ausführen“.
• Lassen Sie keine Platzhalter wie <pfad>, [TODO], TBD oder 待定 in der endgültigen kopierbaren Ausgabe.
• Erlauben Sie keine breiten Berechtigungen wie „alles bearbeiten“, es sei denn, der Benutzer hat dies ausdrücklich angefordert und das Risiko ist gering.
• Behaupten Sie keinen Erfolg durch Budgeterschöpfung, verstrichene Zeit oder Abwesenheit offensichtlicher Fehler.

Wenn das Ziel schwach ist, stellen Sie maximal 3 gezielte Fragen. Wenn fehlende Details risikoarm sind, treffen Sie Annahmen und fahren Sie fort.

Referenzen und Werkzeuge

• Lesen Sie references/examples.md, wenn der Fall mehrdeutig ist oder der Benutzer Varianten wünscht.
• Lesen Sie references/source-patterns.md, wenn Sie das Design-Rationale erklären oder Praktiken vergleichen.
• Verwenden Sie scripts/lint_goal_command.py, wenn Sie eine gespeicherte Ziel-Datei prüfen oder wenn Sie einen entworfenen Befehl kostengünstig validieren können.