Craft Codex Prompts

Was macht Craft Codex Prompts?

Zielsetzung

Wandle unvollständigen Kontext in ein Aufgabenpaket um, das eine andere Codex-Konversation ausführen kann, ohne abgeleitete Interpretation als Tatsache zu behandeln. Optimiere auf Quellentreue, begrenzte Autorität, testbaren Abschluss und geringen Prompt-Overhead.

Wähle die Operation

• Draft: Erstelle einen Prompt aus Dateien, Projektkontext oder einer groben Anfrage.
• Review: Diagnostiziere Schwächen in einem vorhandenen Prompt und erstelle eine überarbeitete Version.
• Handoff: Wandle bisherige Arbeit, Ergebnisse und offene Fragen in den nächsten ausführbaren Prompt um.
• Knowledge Loop: Erstelle aktuellen Status, Entscheidungen, offene Fragen und Handoff-Updates für die Wissensbasis.

Wenn der Nutzer nur einen Prompt anfordert, gib nur den Prompt plus wesentliche Annahmen zurück. Wenn er einen wiederverwendbaren Workflow anfordert, gib das vollständige Aufgabenpaket zurück.

Workflow

1. Quellen und Autorität festlegen

Untersuche nutzerbereitgestellte Dateien und zugängliches Projektmaterial vor dem Erstellen schreibgeschützt, wenn dies autorisiert und nützlich ist. Ändere das Quellprojekt nicht, während du lediglich einen Prompt vorbereitest.

Klassifiziere Eingaben:

• Primäre Fakten: aktuelle Dateien, Repository-Zustand, explizite Nutzeraussagen, autoritative Projektdokumente.
• Abgeleiteter Kontext: Zusammenfassungen, frühere Assistentenschlussfolgerungen, Berichte und kopierten Chat.
• Unbekannte: fehlende Dateien, ungeprüfter Laufzeitzustand, ungelöste Entscheidungen und externe Abhängigkeiten.

Behandle abgeleiteten Kontext als Hinweis, nicht als Beweis. Gib explizit an, dass die ausführende Konversation ihn gegen Primärquellen verifizieren muss.

Gehe nicht davon aus, dass Dateien, die in einer Konversation angehängt wurden, in einer anderen verfügbar sind. Benenne jede Datei oder genauen Arbeitsbereich, den die ausführende Konversation erhalten muss.

2. Aufgabentyp identifizieren

Wähle den nächstgelegenen Aufgabentyp:

• antworten oder erklären;
• inspizieren oder überprüfen;
• diagnostizieren;
• ändern oder bauen;
• recherchieren oder vergleichen;
• ein Artefakt erstellen;
• eine externe Aktion ausführen.

Behalte die passende Autoritätsgrenze bei. Eine Anfrage zur Analyse oder Diagnose autorisiert keine Änderungen. Eine Anfrage zur Änderung oder zum Bauen autorisiert normalerweise die Implementierung und Verifizierung im Rahmen, aber keine unzusammenhängenden Refactorings, Veröffentlichungen, Nachrichten, Commits, Pushes oder destruktiven Aktionen.

Lies task-blueprints.md für das passende Aufgabenmuster.

3. Stabile Regeln vom Aufgaben-Delta trennen

Lege dauerhafte Projektregeln in einem Projektvertrag wie AGENTS.md, PROJECT_BRIEF.md oder CODEX_TASK_CONTRACT.md fest. Halte den aktuellen Prompt fokussiert auf das, was sich dieses Mal geändert hat.

Wiederhole eine stabile Regel im Aufgabenprompt nur dann, wenn sie sicherheitskritisch ist oder wahrscheinlich übersehen wird.

4. Mehrdeutigkeit verhältnismäßig auflösen

Stelle eine klärende Frage nur, wenn die Antwort den Umfang, die Quellenauswahl, irreversibles Verhalten, externe Effekte oder das Akzeptanzkriterium wesentlich verändern würde. Wähle andernfalls die sicherste vernünftige Annahme und kennzeichne sie.

Verstecke niemals eine fehlende Quelle, nicht unterstützte Fähigkeit oder externen Blockierer hinter selbstbewusster Formulierung.

5. Das Aufgabenpaket zusammenstellen

Erstelle diese Abschnitte, wenn relevant:

1. Ergebnis: ein konkreter Endzustand.
2. Wahrheitsquelle: genaue Dateien, Pfade, Daten oder Nutzerentscheidungen.
3. Aktueller Zustand: nur verifizierte oder klar zugeschriebene Fakten.
4. Umfang: erlaubte Lesezugriffe, Änderungen, Systeme und Artefakte.
5. Nicht-Ziele: wahrscheinliche, aber nicht autorisierte Erweiterungen.
6. Angrenzende Prüfungen: nachgelagerte Oberflächen, die denselben Fehler aufdecken können.
7. Ausführungshinweise: Einschränkungen, die die Korrektheit betreffen, keine spekulativen Implementierungsdetails.
8. Akzeptanz: beobachtbare Prüfungen und erwartete Nachweise.
9. Blockierer und Abbruchbedingungen: Bedingungen, die eine Meldung statt eine Schätzung erfordern.
10. Lieferung: geänderte Dateien, Artefakte, Nachweise, Einschränkungen und nächste Übergabe.

Verwende die L1-L4-Überprüfungsleiter, wenn eine Implementierung betroffen ist:

• L1: Syntax-, Import-, Schema- oder statische Validierung;
• L2: Unit-, Service- oder fokussierte Regressionstests;
• L3: Reale-Datei- oder End-to-End-Datenpfadvalidierung;
• L4: Tatsächliche UI, paketierte Laufzeit, Gerät, produktionsähnliche Umgebung oder menschliche Abnahme.

Präsentiere keine niedrigere Ebene als Beweis für eine höhere Ebene.

Füge diese Quellentreue-Klausel hinzu, angepasst an die Aufgabe:

Behandle diesen Prompt als Ausführungsanweisung, nicht als Beweis des Repository-Zustands. Überprüfe seine Behauptungen gegen den aktuellen Arbeitsbereich und die Primärdateien. Wenn sie in Konflikt stehen, bewahre das Quellmaterial, melde den Konflikt und folge der Primärquelle, es sei denn, der Nutzer entscheidet anders.

6. Halte den Prompt ausführbar

• Beginne mit dem Ergebnis.
• Verwende direkte Anweisungen und konkrete Substantive.
• Bevorzuge Dateinamen, Pfade, Zählungen und erwartete Artefakte gegenüber Adjektiven.
• Vermeide das Kopieren von rohem Chat, es sei denn, der genaue Wortlaut ist selbst ein Beweis.
• Vermeide es, Architektur vor der Inspektion vorzuschreiben, es sei denn, der Nutzer hat diese Wahl festgelegt.
• Halte Verbote auf realistische Fehlermodi beschränkt.
• Gib an, ob Codex nur berichten, diagnostizieren, implementieren oder implementieren und verifizieren soll.
• Beende mit einem kompakten Abschlussformat.

7. Vor der Auslieferung prüfen

Bewerte den Prompt intern anhand von sechs Prüfungen:

• Treue: Lässt sich jede faktische Behauptung auf eine Quelle zurückführen?
• Autorität: Sind Lesezugriffe, Änderungen, externe Aktionen und verbotene Aktionen eindeutig?
• Vollständigkeit: Sind wahrscheinlich angrenzende Nutzer und Fehlerpfade abgedeckt?
• Testbarkeit: Kann der Abschluss mit beobachtbaren Nachweisen demonstriert werden?
• Machbarkeit: Sind nicht verfügbare Werkzeuge, Laufzeitbeschränkungen und menschliche Abhängigkeiten offengelegt?
• Kürze: Ändert jede Anweisung die Ausführung oder Überprüfung?

Gib einen Status zurück:

• READY: ausführbar mit verfügbarem Kontext;
• READY_WITH_ASSUMPTIONS: ausführbar nach Auflistung begrenzter Annahmen;
• NEEDS_INPUT: eine oder mehrere wesentliche Entscheidungen fehlen;
• BLOCKED_SOURCE_MISSING: erforderliches Primärmaterial ist nicht verfügbar.

Blähe den Prompt nicht auf, nur um seine scheinbare Strenge zu verbessern.

8. Schließe die Wissensschleife

Wenn der Nutzer Arbeit in Obsidian oder einer anderen Wissensbasis archiviert, lies obsidian-loop.md. Halte unveränderbare rohe Chats getrennt von der aktuellen Projektwahrheit. Aktualisiere nach der Ausführung aktuellen Zustand, Entscheidungen, offene Fragen und die Übergabe, anstatt dich nur auf das Transkript zu verlassen.

Standardausgabe

Sofern der Nutzer kein anderes Format anfordert, gib zurück:

## TASK_BRIEF
[verifizierte Fakten, Annahmen, Unbekannte, Quellen]

## MAIN_PROMPT
[kopierfertiger Prompt]

## PROMPT_STATUS
[READY, READY_WITH_ASSUMPTIONS, NEEDS_INPUT oder BLOCKED_SOURCE_MISSING]
[kurze Erklärung und ggf. erforderliche Anhänge]

Für die Prompt-Überprüfung füge einen kurzen KEY_GAPS-Abschnitt vor MAIN_PROMPT hinzu. Lege keine private Gedankenkette offen; gib präzise, entscheidungsrelevante Gründe an.