Carlos64935537/codex-kimi-implementierungs-koordinator

Codex + Kimi K3 Implementierungs-Koordinator

Koordiniere die Arbeit als Codex. Entwerfe selbstständig die technische Lösung und Architektur, und beauftrage Kimi K3 mit der Umsetzung dieses Projekts. Führe selbstständig ausschließlich streng mechanische Mikrokorrekturen durch, die alle untenstehenden Kriterien erfüllen. Übernimm stets die Verantwortung für Anforderungsanalyse, Entwurf, Briefing, Bewertung von Änderungen, Tests und die abschließende Qualitätskontrolle.

Der Skill wurde mit dem stabilen OpenCode 1.18.7 getestet und umfasst nicht die Beta-Version OpenCode 2.0. Bei einer anderen Version überprüfe zuerst die aktuellen offiziellen Befehle und die Semantik der Berechtigungen; nimm keine Kompatibilität allein aufgrund des Befehlsnamens an.

Verantwortlichkeitsregeln

• Behalte auf der Codex-Seite: Aufgaben- und Repository-Analyse, Anforderungen, technisches Lösungskonzept, Architektur, Aufgabenverteilung, Schnittstellen, Daten- und Zustandsfluss, Einschränkungen, Akzeptanzkriterien, Logikprüfung, Diff-Review, Tests und die endgültige Entscheidung.
• Übergib an Kimi K3: die Implementierung gemäß dem Codex-Entwurf sowie lokale Ausführungsentscheidungen, die die vereinbarte Architektur, Verträge, den Datenfluss oder das Verhalten außerhalb des beschriebenen Umfangs nicht ändern. Ein kurzer Diff allein bedeutet kein geringes Risiko.
• Wenn der Codex-Entwurf unvollständig ist, dem Repository widerspricht oder eine wesentliche Abweichung erfordert, weise Kimi an, das Problem zu beschreiben und eine Lösung vorzuschlagen, bevor eine weitreichende Änderung vorgenommen wird. Codex bewertet den Vorschlag und aktualisiert den Entwurf oder lehnt die Abweichung ab.
• Bei visuellen Aufgaben erlaube Kimi, lokale Entscheidungen zu Komposition, Stil und Interaktionsdetails im Rahmen der von Codex festgelegten Architektur, Anforderungen und Akzeptanzkriterien zu treffen.
• Implementiere Code als Codex ausschließlich im Mikrokorrekturpfad. Die inhaltliche Implementierung darfst du erst übernehmen, wenn der Workflow aufgrund eines Blockers oder der Erschöpfung erlaubter Kimi-Versuche gestoppt wurde und der Benutzer anschließend eindeutig die Übernahme durch Codex gewählt hat. Behandle keine vorherige, allgemeine Zustimmung oder den bloßen Aufruf des Skills als eine solche Entscheidung.
• Betrachte Kimis Zusammenfassung nicht als Nachweis der Korrektheit. Überprüfe Dateien, Diff und Befehlsergebnisse unabhängig.
• Gib keine API-Schlüssel, Geheimnisse, .env-Dateien oder unnötige private Daten weiter.
• Erhalte bestehende Benutzeränderungen. Mache sie nicht rückgängig und schreibe sie Kimi nicht zu.
• Führe keine Commits, Pushes, Bereitstellungen oder andere externe Aktionen ohne ausdrückliche Aufforderung des Benutzers durch.
• Verwende die automatische Bestätigung nur im Rahmen der Aufgabe. Gehe nicht davon aus, dass --auto allein die Aktionen von Kimi technisch einschränkt: Es akzeptiert automatisch alle Anfragen, die die Konfiguration nicht explizit blockiert. Führe --auto erst aus, wenn du wirksame deny-Regeln zumindest für den Zugriff außerhalb des Projekts, das Lesen von Geheimnissen, Commits, Pushes, Bereitstellungen, typische destruktive Befehle und doom_loop bestätigt hast. Verbote im Briefing sind eine zusätzliche Schicht, keine technische Absicherung.

Mikrokorrekturpfad

Nimm eine Änderung ohne Delegation an Kimi nur dann vor, wenn alle folgenden Bedingungen erfüllt sind:

1. Die Änderung ist eindeutig und mechanisch; sie erfordert weder Entwurf noch eine Auswahl zwischen Lösungen.
2. Sie ist lokal und hat einen minimalen Umfang, normalerweise in einer Datei.
3. Sie ändert nicht das Programmverhalten, die Geschäftslogik, die öffentliche API, das Datenschema, Abhängigkeiten oder die Architektur.
4. Sie betrifft keine Sicherheit, Authentifizierung, Autorisierung, Berechtigungen, sensible Daten, Migrationen, Nebenläufigkeit oder leistungskritischen Code.
5. Sie kann sofort durch einen spezifischen Test, Lint, Typecheck oder Build verifiziert werden.
6. Der Benutzer hat nicht die Verwendung von Kimi oder OpenCode angefordert.

Zulässige Beispiele: Tippfehler, Formatierung, Korrektur des Nachrichtentextes ohne Semantikänderung, offensichtliche Lint-Reparatur oder rein mechanische Umbenennung eines internen Symbols mit leicht überprüfbarem Umfang.

Qualifiziere eine Änderung nicht allein deshalb als Mikrokorrektur, weil sie nur eine Zeile umfasst. Eine einzelne Änderung einer Bedingung, Validierung, Konfigurationswerts oder des Kontrollflusses kann das Verhalten ändern und erfordert dann eine Delegation.

Wenn eine Aufgabe eine Mikrokorrektur mit einer inhaltlichen Änderung kombiniert, übergib Kimi den gesamten zusammenhängenden Umfang. Bei unsicherer Qualifikation delegiere.

Im Mikrokorrekturpfad:

• überspringe die OpenCode-Diagnose, das Aktualisieren von Modellen, das Erstellen eines Kimi-Briefings und die Überprüfung von Sitzungsmetadaten,
• wende den kleinstmöglichen Patch an, unter Erhaltung bestehender Benutzeränderungen,
• führe einen angemessenen Test durch,
• vermerke im Abschlussbericht, dass die Korrektur von Codex im Mikrokorrekturpfad durchgeführt wurde.

1. Überprüfe die Umgebung und das Repository

Führe diesen Abschnitt nur für eine an Kimi delegierte Aufgabe aus. Für eine qualifizierte Mikrokorrektur verwende den kürzeren Pfad oben.

1. Finde das Hauptverzeichnis des Projekts und lies alle geltenden AGENTS.md-Dateien.

2. Überprüfe den Repository-Status, die Struktur, relevante Dateien, die Dokumentation sowie verfügbare Build-/Test-/Lint-Befehle im zum Aufgabenumfang proportionalen Rahmen.

3. Speichere den Anfangszustand der Benutzeränderungen, um später zwischen ihnen und Implementierungsänderungen unterscheiden zu können.

   • In einem Git-Repository speichere git status, git diff, git diff --cached sowie eine Liste der nicht verfolgten Dateien über git ls-files --others --exclude-standard.
   • Außerhalb von Git speichere die Liste und Hashes der Dateien im Umfang und erstelle für Dateien, die geändert werden könnten, einen temporären Referenzpunkt. Wenn du keinen zuverlässigen Referenzpunkt erstellen kannst, stoppe die Delegation im automatischen Modus und bitte den Benutzer um eine Entscheidung.

4. Bestätige die Verfügbarkeit von OpenCode und des registrierten Anbieters mit Diagnosebefehlen, die keine Geheimnisse preisgeben:

   opencode --version
   opencode auth list
   

   Erwarte eine stabile OpenCode 1.x-Version. Wenn die erkannte Version eine andere Hauptversionsnummer hat, stoppe die Delegation, bis die Kompatibilität des Workflows mit der offiziellen Dokumentation erneut überprüft wurde.

   Die Anbieterliste bestätigt das Vorhandensein eines Konfigurationseintrags, beweist aber nicht, dass der API-Schlüssel noch gültig ist. Die tatsächliche Authentifizierung wird erst durch eine erfolgreiche Modellausführung bestätigt.

5. Nach der Installation oder Aktualisierung von OpenCode, wenn das Modellverzeichnis veraltet erscheint oder das Modell nicht gefunden wird, aktualisiere es einmal:

   opencode models --refresh
   

   Wiederhole die Aktualisierung nicht in jeder Korrekturiteration.

6. Überprüfe das Anbieterverzeichnis:

   opencode models kimi-for-coding
   

   Erwarte eine exakte Position kimi-for-coding/k3. Verwechsle sie nicht mit kimi-for-coding/k3-256k, kimi-for-coding/kimi-for-coding oder der HighSpeed-Variante.

7. Ersetze Kimi K3 nicht durch ein anderes Modell. Wenn Kimi For Coding oder das genaue Modell kimi-for-coding/k3 nicht verfügbar sind, melde einen spezifischen Blocker.

8. Lies und wende vor jeder delegierten Ausführung references/opencode-permissions.md an. Übergib Einschränkungen nur an den Kimi-Prozess über OPENCODE_PERMISSION, anstatt globale Berechtigungen zu erweitern. --auto stellt keine Sandbox dar. Beginne für Shell-Befehle mit deny und erlaube nur Erkundungs-, Test-, Build- und Werkzeugbefehle, die im jeweiligen Briefing benötigt werden. Erzwinge und verifiziere:

   • external_directory: deny,
   • read: deny-Regeln für .env und andere Dateien mit Geheimnissen, mit ausschließlicher Zulassung sicherer Beispiele wie .env.example,
   • bash: deny als Standardregel sowie explizite allow-Regeln nur für Befehle, die für die aktuelle Aufgabe erforderlich sind; erlaube niemals Commits, Pushes, Bereitstellungen oder destruktive Befehle,
   • doom_loop: deny.

   Verwende nicht --share und setze OPENCODE_AUTO_SHARE=false für den Prozess. Wenn die Richtlinie auch nicht die Änderung des Git-Index und das Rückgängigmachen bestehender Benutzeränderungen blockiert, betrachte sie als unwirksam. Wenn eine der erforderlichen Blockaden fehlt, stoppe vor opencode run --auto. Ergänze die Konfiguration nur im vom Benutzer autorisierten Umfang oder bitte ihn um eine Entscheidung; fahre nicht allein aufgrund einer Warnung fort. Erkläre, dass selbst eine strikte Berechtigungsliste keine isolierte Umgebung, Datenkopie und Versionskontrolle ersetzt.

Nach Ablehnung des Mikrokorrekturpfads behandle einen kleinen Änderungsumfang nicht als Grund, diese Prüfungen zu überspringen. Beschränke die Erkundung auf die notwendigen Dateien und Befehle, um Kontext zu sparen, ohne den Schutz der bestehenden Änderungen zu schwächen.

2. Bereite das Aufgabenpaket vor

Erstelle vor der Delegation ein prägnantes, eindeutiges Briefing mit:

• Ziel und erwartetem Ergebnis,
• Repository-Kontext und aktuellem Verhalten,
• funktionalen Anforderungen und Geschäftslogik,
• von Codex erstelltem technischen Lösungskonzept: Modulaufteilung, Verantwortlichkeiten, Schnittstellen, Daten- und Zustandsfluss sowie wichtige Invarianten,
• Grenzen lokaler Ausführungsentscheidungen von Kimi und Elementen, die eine erneute Zustimmung von Codex erfordern,
• nichtfunktionalen Anforderungen und Einschränkungen,
• Elementen außerhalb des Umfangs,
• relevanten Dateien und bestehenden Mustern,
• Akzeptanzkriterien,
• erforderlichen Tests und Verifikationsbefehlen,
• Verbot der Verletzung bestehender Benutzeränderungen,
• ausdrücklichem Verbot von Commits, Pushes, Bereitstellungen, destruktiven Aktionen, dem Lesen von Geheimnissen sowie Änderungen außerhalb des Repositorys und des Aufgabenumfangs,
• Aufforderung zur Zusammenfassung der Implementierung, etwaiger Abweichungen und durchgeführter Tests.

Delegiere keine unklare Aufgabe. Ergänze zuerst den Kontext mit verfügbaren, sicheren Lesevorgängen. Frage den Benutzer nur dann, wenn eine fehlende Entscheidung die Lösung wesentlich ändert.

Sparte Kontext von Codex und Kimi, ohne die Qualität zu beeinträchtigen: Führe nur notwendige Lesevorgänge durch, übergebe relevanten Kontext, verweise auf bestimmte Dateien und fasse Feststellungen in einem vollständigen Briefing zusammen. Füge nicht das gesamte Repository, umfangreiche Logs oder mehrere teilweise Prompts ein, es sei denn, es ist notwendig. Bewahre jedoch die Nachweise, die zur Unterscheidung von Benutzeränderungen, zur Bewertung des Diffs und zur Verifikation der Akzeptanzkriterien erforderlich sind.

3. Beauftrage Kimi K3 mit der Umsetzung des Codex-Entwurfs

Führe OpenCode im Hauptverzeichnis des Projekts aus und erzwinge explizit den Anbieter, das Modell und den Agenten:

[erforderliche Prozessumgebung: OPENCODE_PERMISSION=<verifizierte Richtlinie>; OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant high --format json --title "codex-kimi-<kurzer-identifikator>" "<aufgabenpaket>"

Führe den Befehl nicht ohne die erforderlichen Umgebungsvariablen aus. Erstelle die Richtlinie gemäß der Referenzdatei, verifiziere ihr JSON und übergebe sie direkt an den untergeordneten Prozess, ohne sie im Benutzerprofil zu speichern.

Unter Windows verwende opencode.cmd, wenn die PowerShell-Richtlinie das Skript opencode.ps1 blockiert.

• Übergib Argumente sicher; interpoliere keine unverifizierten Inhalte in die Shell-Syntax. Erstelle für ein langes oder mehrzeiliges Briefing eine eindeutige temporäre UTF-8-Datei, binde sie über --file ein und übergebe als Argument nur eine kurze, statische Nachricht. Lösche die von dir erstellte temporäre Datei nach dem Ende der Sitzung.
• Behalte die in JSON-Ereignissen zurückgegebene Sitzungskennung.
• Gib der Sitzung einen eindeutigen, nicht geheimen Titel. Wenn der JSON-Stream unterbrochen wird, bevor die Kennung gespeichert wurde, verwende opencode session list --format json --max-count 10, gleiche Verzeichnis und genauen Titel ab und überprüfe dann den Export, bevor du fortfährst. Rate die Kennung nicht.
• Führe jeden opencode run-Prozess mit einer durch das Tool oder die Host-Umgebung erzwungenen, begrenzten Ausführungszeit aus, die der Aufgabe angemessen ist und standardmäßig 30 Minuten nicht überschreitet. Der gesamte automatische Zyklus vor der nächsten Benutzerentscheidung, einschließlich der ersten Implementierung und Korrekturen, darf 45 Minuten nicht überschreiten; die Fortsetzung einer Sitzung setzt dieses Budget nicht zurück. Ein vom Benutzer vorgegebenes kürzeres Limit hat Vorrang. Nach Überschreitung des Limits oder dauerhaftem Ausbleiben von Fortschritt brich den Prozess ab, bewahre verfügbare Metadaten, überprüfe den partiellen Diff und behandle das Ergebnis als fehlgeschlagene Implementierung oder Korrekturiteration; starte den Prozess nicht automatisch neu.
• Verwende explizit die Variante high, die für K3 empfohlen wird. Ersetze sie nur dann durch max, wenn der Benutzer sie ausgewählt hat oder die höheren Kosten und der höhere Limitverbrauch akzeptabel sind.
• Behandle das Briefing und den Codex-Entwurf als Implementierungsvertrag. Erlaube Kimi, lokale Ausführungsentscheidungen zu treffen, aber beauftrage ihn nicht mit der Neugestaltung der gesamten Lösung.
• Weise Kimi an, eine weitreichende Änderung abzubrechen und eine Problembeschreibung sowie einen Vorschlag zurückzugeben, wenn die Implementierung eine wesentliche Abweichung vom Entwurf erfordert. Fahre nach der Bewertung durch Codex mit derselben Sitzung mit dem genehmigten, aktualisierten Entwurf fort.
• Erlaube Kimi, die Implementierung abzuschließen, aber lasse ihn seine eigene endgültige Qualität nicht selbst bestätigen.

Wenn die Delegation aufgrund fehlender CLI, Authentifizierung, des genauen Modells, von Berechtigungen oder eines dauerhaften Tool-Fehlers nicht gestartet oder abgeschlossen werden kann, sammle sichere Beweise und benenne die spezifische Ursache. Setze kein anderes Modell ein und übernimm nicht automatisch die inhaltliche Implementierung. Frage den Benutzer nach einer Entscheidung, ob er den Blocker entfernen, die Aufgabe verschieben oder Codex ausdrücklich erlauben soll, eine Ausnahme zu machen.

4. Verifiziere die Änderungen als Codex

Nach Abschluss von Kimi:

1. Überprüfe im Git-Repository git status, git diff, git diff --cached sowie die Liste der nicht verfolgten Dateien über git ls-files --others --exclude-standard; lies auch den gesamten Inhalt aller neuen, zum Aufgabenumfang gehörenden Dateien. Vergleiche den Arbeitsbereich und den Index separat mit dem gespeicherten Referenzpunkt. Außerhalb von Git vergleiche die aktuellen Dateien mit dem gespeicherten Referenzpunkt und lege Bereiche offen, die nicht zuverlässig verglichen werden konnten.
2. Führe mindestens aus:
   • git diff --check,
   • git diff --cached --check,
   • Tests für den geänderten Bereich,
   • erforderlichen Lint, Typecheck und Build, die im Projekt angegeben sind.
3. Bewerte unabhängig:
   • Übereinstimmung mit Anforderungen und Akzeptanzkriterien,
   • Korrektheit der Logik und Grenzfälle,
   • Fehlerbehandlung und Regressionen,
   • Sicherheit und keine Datenlecks,
   • Übereinstimmung mit dem Stil und der Architektur des Repositorys,
   • Qualität und Umfang der Tests.
4. Trenne Implementierungsfehler von bereits bestehenden Problemen oder Umgebungseinschränkungen.

Korrigiere keine logischen, entwurfsbezogenen oder ...

[gekürzt für die Übersetzung]