搭子.skill (Partner)

Was macht 搭子.skill (Partner)?

Mein Claude Code und Codex sind die besten der Welt.

Übersicht

Nutze diese Fähigkeit, um einen Zwei-Agenten-Coding-Workflow auszuführen: Claude Code ist der wertvolle Agent für Planung, Verfeinerung und Review; Codex ist der äußere Orchestrator und Hauptimplementierer. Halte die Nutzung von Claude Code fokussiert, da es möglicherweise über die API abgerechnet wird.

Bevorzuge eine einzige langlebige Claude Code-Sitzung für kleine und mittlere Aufgaben: Frage Claude nach dem Plan, lass Codex implementieren, und gib dann die Diff-Zusammenfassung und die wichtigsten Dateien an dieselbe Claude-Sitzung zurück, um UI/Interaktionsverfeinerung und das abschließende /codex:review durchzuführen. Dies vermeidet, dass Claude den gleichen Projektkontext neu aufbauen muss, und gibt Claude genügend Kontinuität, um die Arbeit zu verbessern.

Partner ist keine Ausrede für Delegation. Der Benutzer bleibt der Eigentümer, Codex bleibt für den Repository-Nachweis verantwortlich, und Claude Code wird als wertvoller Mitarbeiter behandelt, dessen Ausgabe verifiziert werden muss.

Standardablauf

1. Im Ziel-Repository verankern.

   • Betrete das konkrete Projektverzeichnis, nicht die agent-workbench-Wurzel.
   • Führe git status --short aus, bevor du Claude Code startest.
   • Identifiziere, ob die Aufgabe Neuland, schwergewichtig auf Features, schwergewichtig auf UI, nur Review oder Debugging ist.

2. Starte eine Claude Code-Sitzung für die teure Denkschleife.

   • Für die Planung: Starte Claude Code in einem PTY und setze ein Ziel.
   • Verwende standardmäßig claude --permission-mode plan --name <task-name>.
   • Sende in der interaktiven Sitzung /goal <clear completion condition>.
   • Bitte Claude Code um einen konkreten Implementierungsplan, Abnahmekriterien und UI/Interaktionsleitfaden.
   • Halte dieselbe Sitzung für die späteren Verfeinerungs- und Review-Durchgänge offen, wenn die Aufgabe nicht zu groß ist.
   • Starte keine separate claude -p-Sitzung nur für das Review, nur weil Codex die Implementierung abgeschlossen hat. Das verbraucht Tokens für einen Kaltstart-Kontext und schwächt Claudes Kontinuität.

3. Implementiere hauptsächlich mit Codex.

   • Wandle Claude Codes Plan in eine kurze Checkliste um.
   • Nimm die Codeänderungen direkt in Codex vor, unter Verwendung vorhandener Repository-Muster.
   • Führe die schnellste relevante Prüfung nach riskanten Änderungen durch.
   • Halte Claude Code aus mechanischen Massenänderungen, wiederholten Lint-Korrekturen und langen Befehlsschleifen heraus, es sei denn, der Benutzer bittet darum.

4. Gib den implementierten Zustand an dieselbe Claude Code-Sitzung zur Verfeinerung zurück.

   • Nutze dies besonders für Frontend-UI, Interaktionsqualität, Produktgefühl, Barrierefreiheit und Randzustände.
   • Sende ein begrenztes Paket. Verwende wenn möglich references/handoff-template.md: den ursprünglichen Plan, die Liste der geänderten Dateien, git diff --stat, Test-/Prüfausgaben, Risiken, offene Fragen und nur die wichtigsten Dateiauszüge oder vollständigen Dateien, die Claude benötigt.
   • Bitte um priorisierte Erkenntnisse, nicht um breite Neuschreibungen.
   • Codex wendet akzeptierte Korrekturen an und führt Prüfungen erneut aus.

5. Führe das abschließende Review von derselben Claude Code-Sitzung aus.

   • Verwende in Claude Code /codex:review, wenn verfügbar.
   • Behandle Erkenntnisse zuerst als Fehler/Risiko/Test-Probleme, Stilvorschläge erst danach.
   • Codex behebt blockierende Erkenntnisse, führt Prüfungen erneut aus und meldet den endgültigen Status.
   • Beende mit einer Partner-Sitzungsquittung, damit der Benutzer überprüfen kann, ob der Claude Code-Kontext wiederverwendet wurde.

Sitzungsstrategie

• Kleine oder mittlere Aufgabe: halte eine Claude Code-Sitzung für plan -> polish -> /codex:review offen.
• Behandle eine neue Claude Code-Sitzung als teuer. Öffne eine nur, wenn es keine wiederverwendbare Sitzung gibt, die vorherige Sitzung nicht wiederherstellbar ist oder der Benutzer explizit um einen frischen Claude-Durchlauf bittet.
• Wenn dieselbe Claude-Sitzung in einer Eingabeaufforderung, Berechtigungswartezeit oder im Leerlauf steckt, versuche zuerst, dieselbe Sitzung mit einer begrenzten Nachricht fortzusetzen oder wieder aufzunehmen. Starte keinen Kaltstart-Ersatz-Review, es sei denn, der Wert übertrifft eindeutig die Kontextkosten.
• Große Aufgabe oder großer Diff: Teile Sitzungen nur auf, nachdem Codex eine kompakte Übergabe mit dem Plan, den geänderten Dateien, den wichtigsten Entscheidungen, bekannten Risiken und Prüfergebnissen erstellt hat.
• Wenn dieselbe Claude-Sitzung langsam, verwirrt oder kontextlastig wird, schließe sie und starte mit einer begrenzten Übergabe neu, nachdem der Token-Kompromiss gemeldet wurde.
• Überspringe die Claude-Verfeinerungsphase für UI/Frontend-Arbeiten nicht, es sei denn, der Benutzer bittet explizit um eine schnellere minimale Schleife.
• Wenn /codex:review hängt, eine Zeitüberschreitung hat oder in einer Berechtigungsaufforderung steckt, zeichne dies als Überwachungserkenntnis auf, stoppe den hängenden Unterprozess/die hängende Sitzung und fahre mit der Codex-seitigen Überprüfung fort.
• Wenn Claude Code keine umsetzbare Verfeinerung liefert, fordere es nicht blind weiter auf. Erfasse das leere/signalarme Ergebnis, führe die Codex-Überprüfung durch und melde die Einschränkung.
• claude -p ist nicht der Standard-Partner-Pfad. Verwende es nur für günstige einmalige Fragen, bei denen der Verlust des vorherigen Sitzungskontexts akzeptabel ist.

Berechtigungsrichtlinie

• Standardmäßig --permission-mode plan für die Planung und normale Berechtigungen für die Implementierungsüberprüfung verwenden.
• Überspringen/Umgehen nur verwenden, wenn der Benutzer explizit nach skip, 最高权限, 全部允许, bypass fragt oder wenn die Arbeit in einem bewusst isolierten Worktree stattfindet.
• Für den Überspring-Modus starte Claude Code mit claude --permission-mode bypassPermissions --name <task-name> oder claude --dangerously-skip-permissions --name <task-name>.
• Vor jeder Überspring-Sitzung den Repo-Pfad, den aktuellen Git-Status, den beabsichtigten Umfang und die Stopp-Bedingung angeben.
• Erlaube dem Überspring-Modus niemals, Commits zu erstellen, zu pushen, bereitzustellen, Nachrichten zu senden, zu veröffentlichen oder Geheimnisse zu berühren, es sei denn, der Benutzer gibt eine separate explizite Anweisung.
• Behandle skip niemals als Erlaubnis, Repository-Nachweise zu ignorieren. skip ändert die Berechtigungen von Claude Code, nicht die Überprüfungspflicht von Partner.
• Halte Änderungen der Repository-Sichtbarkeit, Release-Tags, Registrierungsveröffentlichungen und externe Ankündigungen hinter einer separaten expliziten Veröffentlichungsanweisung.

Routing-Regeln

• Route zu Claude Code: Architekturplanung, Implementierungsstrategie, UI/Interaktionskritik, abschließendes Codex-Review, schwierige Produktentscheidungen.
• Route zu Codex: Grundgerüst, Implementierung, langlaufende Code-Änderungen, Tests, Build-Korrekturen, Repository-Inspektion, Überwachung, Zusammenfassungen.
• Route zurück zur selben Claude Code-Sitzung, wenn die UI-Qualität wichtig ist oder die erste Implementierung technisch bestanden hat, aber noch Produktverfeinerung benötigt.
• Halte Kimi Work/Kimi Code Goal getrennt von Claude Code /goal; der vorherige "Goal-Modus"-Kontext kann sich auf Kimi beziehen, nicht auf Claude.

Validierungs-Gatter

Verwende die Darwin-Ratsche in references/darwin-ratchet.md, wenn du diesen Workflow verbesserst oder auf eine umfangreiche Aufgabe anwendest:

• Ändere jeweils nur eine Workflow-Dimension: Planung, Implementierung, UI-Verfeinerung, Review, Überwachung, Berechtigungen oder Berichterstattung.
• Führe Test-Prompts oder eine echte Minischleife aus, bevor du eine Verbesserung als besser bezeichnest.
• Lass denselben Agenten nicht den einzigen Macher und einzigen Richter für risikoreiche Änderungen sein.
• Behalte die Änderung nur, wenn sich die Repository-Nachweise verbessern. Wenn sie sich verschlechtern, verwende einen überprüfbaren Revert, nicht git reset --hard.
• Höre auf, wenn eine weitere Prompt-Schleife wenig Signal oder <1 Punkt erwartete Verbesserung liefert.

Überwachung

Lies für aktive Claude Code-Sitzungen references/monitoring.md. Bevorzuge fünf Signale anstatt allein auf den Chat-Text zu vertrauen:

1. PTY-Ausgabe der laufenden Claude Code-Sitzung.
2. claude agents --json --cwd <repo> Sitzungsstatus.
3. Claude JSONL-Transkriptstruktur, ohne standardmäßig vollständige Nachrichtentexte zu laden.
4. Optionale Aufgabendateien unter ~/.claude/tasks/<sessionId>/.
5. Repository-Nachweise: git status --short, git diff --stat und relevante Test-/Build-Prüfungen.

Ausgabe-Vertrag

Wenn du an den Benutzer berichtest, füge Folgendes ein:

• Aktuelle Phase: Planung, Codex-Implementierung, Claude-Verfeinerung, Review oder endgültige Korrektur.
• Claude Code-Sitzungs-ID, falls vorhanden.
• Geänderte Dateien und durchgeführte Prüfungen.
• Erkenntnisse aus dem Review, die behoben oder noch offen sind.
• Ob die Arbeit bereit zum Committen ist; committe nicht standardmäßig.
• Jede Überwachungsanomalie wie Leerlaufsitzung, Berechtigungswartezeit, leere Review-Ausgabe, kein Diff oder fehlgeschlagene Prüfung.
• Eine Partner-Sitzungsquittung für nicht-triviale Claude Code-Workflows:

[Partner Sitzungsquittung]
phase: <planning | codex implementation | claude polish | review | final fix>
claude_session: <sessionId or none>
claude_session_reused: <yes | no | n/a>
new_claude_p_sessions: <0 | count | unknown>
codex_passes: <Anzahl der Implementierungs-/Korrekturdurchläufe>
checks: <ausgeführte oder nicht ausgeführte Befehle>
anomalies: <none | permission wait | idle | empty review | failed check | other>

Erfinde keine Token-Ersparnisse. Wenn genaue Token-Telemetrie nicht verfügbar ist, melde stattdessen überprüfbares Verhalten: Dieselbe Claude Code-Sitzung wiederverwendet, keine frische claude -p-Sitzung, begrenzte Übergabe verwendet, Prüfungen bestanden.