omc-plan

<Verwende_Wenn>

• Der Benutzer möchte vor der Implementierung planen -- "plane das", "plane den", "lass uns planen"
• Der Benutzer wünscht eine strukturierte Anforderungserfassung für eine vage Idee
• Der Benutzer möchte einen bestehenden Plan überprüfen lassen -- "überprüfe diesen Plan", --review
• Der Benutzer wünscht einen Konsens aus mehreren Perspektiven zu einem Plan -- --consensus, "ralplan"
• Die Aufgabe ist breit oder vage und benötigt eine Abgrenzung, bevor Code geschrieben wird </Verwende_Wenn>

<Verwende_Nicht_Wenn>

• Der Benutzer wünscht eine autonome End-to-End-Ausführung -- stattdessen autopilot verwenden
• Der Benutzer möchte sofort mit dem Codieren beginnen und hat eine klare Aufgabe -- ralph verwenden oder an einen Ausführenden delegieren
• Der Benutzer stellt eine einfache Frage, die direkt beantwortet werden kann -- einfach antworten
• Die Aufgabe ist eine einzelne, fokussierte Korrektur mit offensichtlichem Umfang -- ein Ausführungsskill verwenden, anstatt ihn über dieses Planungsmodul auszuführen </Verwende_Nicht_Wenn>

<Warum_Das_Existiert> Sich ohne Verständnis der Anforderungen in Code zu stürzen, führt zu Nacharbeiten, schleichender Ausweitung des Umfangs und übersehenen Grenzfällen. Plan bietet strukturierte Anforderungserfassung, Expertenanalyse und qualitätsgesicherte Pläne, sodass die Ausführung auf einer soliden Grundlage beginnt. Der Konsensmodus fügt für risikoreiche Projekte eine Validierung aus mehreren Perspektiven hinzu. </Warum_Das_Existiert>

<Ausführungsrichtlinie>

• Automatische Erkennung von Interview- vs. Direktmodus basierend auf der Spezifität der Anfrage
• Während Interviews immer nur eine Frage gleichzeitig stellen -- niemals mehrere Fragen bündeln
• Codebase-Fakten über den explore-Agenten sammeln, bevor der Benutzer danach gefragt wird
• Pläne müssen Qualitätsstandards erfüllen: 80%+ der Behauptungen zitieren Datei/Zeile, 90%+ der Kriterien sind testbar
• Der Konsensmodus läuft standardmäßig vollautomatisch; --interactive hinzufügen, um Benutzereingaben bei Entwurfsprüfung und endgültiger Genehmigung zu ermöglichen
• Der Konsensmodus verwendet standardmäßig den RALPLAN-DR-Kurzmodus; mit --deliberate oder wenn die Anfrage explizit hohes Risiko signalisiert (Authentifizierung/Sicherheit, Datenmigration, destruktive/irreversible Änderungen, Produktionsvorfall, Compliance/PII, Bruch öffentlicher APIs), auf den deliberaten Modus umschalten
• Planungs-/Ausführungsgrenze: Planungsmodi inspizieren den Kontext und erstellen nur Pläne/Spezifikationen/Vorschläge. Sie MÜSSEN Artefakte als pending approval markieren, es sei denn, der Benutzer hat sich im aktuellen Durchlauf oder über die strukturierte Genehmigungs-Benutzeroberfläche explizit für die Ausführung entschieden. Vor expliziter Ausführungsgenehmigung DÜRFEN Planungsmodi KEINE mutationsorientierten Shell-Befehle ausführen, Quelldateien bearbeiten, Commits erstellen, Pushen, PRs eröffnen, Ausführungsskills aufrufen oder Implementierungsaufgaben delegieren.
• Ziel-Workflow-Grenze: Wenn ein Plan Claude Code /goal, Ralph, Team oder Artefakt-Only-Ultragoal vergleicht, genau eine primäre Schleifenautorität identifizieren und die deterministischen Konfliktrichtlinien refuse, adopt_existing und artifact_only anstelle von nicht-deterministischer Warnungsbehandlung verwenden. /goal-Fakten müssen nur Claude Code/Anthropic-Quellen zitieren (Claude Code /goal-Dokumente: https://code.claude.com/docs/en/goal; Anthropic Claude Code-Changelog: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), und Pläne DÜRFEN NICHT behaupten, dass der /goal-Evaluator unabhängig Befehle ausführt oder Dateien liest; erfordern sichtbare Beweise vor jeder Abschlussbehauptung.
• Ziel-Workflow-Dokumentziel: Für benutzerseitige Vergleiche die Beispiele an docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection und docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal ausrichten. </Ausführungsrichtlinie>

Modusauswahl

Modus	Auslöser	Verhalten
Interview	Standard für breite Anfragen	Interaktive Anforderungserfassung
Direkt	--direct oder detaillierte Anfrage	Interview überspringen, Plan direkt erstellen
Konsens	--consensus, "ralplan"	Planer -> Architekt -> Kritiker-Schleife bis zur Einigung mit RALPLAN-DR-strukturierter Deliberation (standardmäßig kurz, --deliberate für hohes Risiko); --interactive für Benutzereingaben bei Entwurf und Genehmigungsschritten hinzufügen
Überprüfung	--review, "überprüfe diesen Plan"	Kritikerbewertung des bestehenden Plans

Interview-Modus (breite/vage Anfragen)

1. Anfrage klassifizieren: Breit (vage Verben, keine spezifischen Dateien, berührt 3+ Bereiche) löst den Interview-Modus aus
2. Eine fokussierte Frage stellen mit AskUserQuestion zu Präferenzen, Umfang und Einschränkungen
3. Zuerst Codebase-Fakten sammeln: Bevor gefragt wird "welche Muster verwendet Ihr Code?", einen explore-Agenten starten, um dies herauszufinden, dann fundierte Folgefragen stellen
4. Auf Antworten aufbauen: Jede Frage baut auf der vorherigen Antwort auf
5. Analysten konsultieren (Opus) für versteckte Anforderungen, Grenzfälle und Risiken
6. Plan erstellen, wenn der Benutzer Bereitschaft signalisiert: "erstelle den Plan", "ich bin bereit", "mach es zu einem Arbeitsplan"

Direktmodus (detaillierte Anfragen)

1. Schnelle Analyse: Optionale kurze Analystenkonsultation
2. Plan erstellen: Sofort einen umfassenden Arbeitsplan generieren
3. Überprüfung (optional): Kritikerüberprüfung, falls angefordert

Konsensmodus (--consensus / "ralplan")

RALPLAN-DR-Modi: Kurz (Standard, begrenzte Struktur) und Deliberat (für --deliberate oder explizite risikoreiche Anfragen). Beide Modi behalten die gleiche Planer -> Architekt -> Kritiker-Sequenz und die gleichen AskUserQuestion-Tore bei.

Anbieter-Override (unterstützt, wenn die Anbieter-CLI installiert ist):

• --architect codex — den Claude-Architekt-Durchlauf mit omc ask codex --agent-prompt architect "..." für eine implementierungsintensive Architekturüberprüfung ersetzen
• --critic codex — den Claude-Kritiker-Durchlauf mit omc ask codex --agent-prompt critic "..." für einen externen Überprüfungsdurchlauf vor der Ausführung ersetzen
• Wenn der angeforderte Anbieter nicht verfügbar ist, kurz darauf hinweisen und mit dem standardmäßigen Claude-Architekt/Kritiker-Schritt für diese Phase fortfahren

Status-Lebenszyklus: Der Stop-Hook des persistenten Modus verwendet ralplan-state.json, um die Fortsetzung während der Konsensschleife zu erzwingen. Der Skill MUSS diesen Status verwalten:

• Beim Eintritt: state_write(mode="ralplan", active=true, session_id=<current_session_id>) vor Schritt 1 aufrufen
• Bei Übergabe an die Ausführung (Genehmigung → ralph/team): state_write(mode="ralplan", active=false, session_id=<current_session_id>) aufrufen. Hier NICHT state_clear verwenden — state_clear schreibt ein 30-Sekunden-Abbruchsignal, das die Stop-Hook-Durchsetzung für ALLE Modi deaktiviert und den neu gestarteten Ausführungsmodus ungeschützt lässt.
• Bei echtem terminalem Beenden (Ablehnung, nicht-interaktive Planausgabe, Fehler/Abbruch): state_clear(mode="ralplan", session_id=<current_session_id>) aufrufen — es folgt kein Ausführungsmodus, daher ist das Abbruchsignalfenster harmlos.
• NICHT während Zwischenschritten wie der Kritiker-Zustimmung oder der Darstellung maximaler Iterationen löschen, da der Benutzer möglicherweise noch "Änderungen anfordern" auswählt.

Ohne Bereinigung blockiert der Stop-Hook alle nachfolgenden Stopps mit [RALPLAN - CONSENSUS PLANNING]-Verstärkungsnachrichten, selbst nachdem der Konsens-Workflow abgeschlossen ist. Immer session_id übergeben, um das Löschen des Status anderer gleichzeitiger Sitzungen zu vermeiden.

1. Planer erstellt den anfänglichen Plan und eine kompakte RALPLAN-DR-Zusammenfassung vor jeder Architekt-Überprüfung. Die Zusammenfassung MUSS Folgendes enthalten:

   • Prinzipien (3-5)
   • Entscheidungstreiber (Top 3)
   • Lebensfähige Optionen (>=2) mit abgewogenen Vor-/Nachteilen für jede Option
   • Wenn nur eine lebensfähige Option übrig bleibt, eine explizite Ungültigkeitsbegründung für die abgelehnten Alternativen
   • Im deliberaten Modus: eine Prä-Mortem (3 Fehlerszenarien) und ein erweiterter Testplan mit Unit / Integration / e2e / Observability

2. Benutzerfeedback (nur --interactive): Wenn mit --interactive ausgeführt, MUSS AskUserQuestion verwendet werden, um den Planentwurf plus die RALPLAN-DR-Prinzipien / Entscheidungstreiber / Optionen-Zusammenfassung zur frühzeitigen Ausrichtungslenkung mit diesen Optionen zu präsentieren:

   • Zur Überprüfung fortfahren — an Architekt und Kritiker zur Bewertung senden
   • Änderungen anfordern — mit Benutzerfeedback zu Schritt 1 zurückkehren
   • Überprüfung überspringen — direkt zur endgültigen Genehmigung gehen (Schritt 7) Wenn NICHT mit --interactive ausgeführt, automatisch zur Überprüfung fortfahren (Schritt 3).

3. Architekt überprüft auf architektonische Solidität mit Task(subagent_type="oh-my-claudecode:architect", ...). Die Architekt-Überprüfung MUSS Folgendes enthalten: stärkstes Stahlmann-Gegenargument (Antithese) gegen die bevorzugte Option, mindestens eine sinnvolle Abwägungsspannung und (wenn möglich) einen Synthesepfad. Im deliberaten Modus sollte der Architekt explizit Prinzipienverletzungen kennzeichnen. Auf die Fertigstellung dieses Schritts warten, bevor mit Schritt 4 fortgefahren wird. Die Schritte 3 und 4 NICHT parallel ausführen. Der Architekt MUSS denselben festen Plan-Snapshot bewerten, der vom Planer in Schritt 1 erstellt wurde, ohne ihn zu mutieren; die Architekt-Ausgabe DARF NICHT an den Kritiker weitergegeben werden.

4. Kritiker bewertet anhand von Qualitätskriterien mit Task(subagent_type="oh-my-claudecode:critic", ...). Der Kritiker MUSS die Prinzipien-Options-Konsistenz, faire Alternativenerkundung, Klarheit der Risikominderung, testbare Abnahmekriterien und konkrete Verifikationsschritte überprüfen. Der Kritiker MUSS oberflächliche Alternativen, Treiberwidersprüche, vage Risiken oder schwache Verifikation explizit ablehnen. Im deliberaten Modus MUSS der Kritiker fehlendes/schwaches Prä-Mortem oder fehlenden/schwachen erweiterten Testplan ablehnen. Nur nach Abschluss von Schritt 3 ausführen. Der Kritiker MUSS denselben festen Plan-Snapshot unabhängig bewerten, als separaten, individuell erwarteten Task-Aufruf; der Kritiker DARF die Architekt-Überprüfung NICHT konsumieren oder erhalten.

   Unabhängige sequenzielle Überprüfungen eines festen Plan-Snapshots. Architekt und Kritiker überprüfen jeweils denselben festen Plan-Snapshot, der vom Planer in Schritt 1 erstellt wurde, und keine der Überprüfungen mutiert ihn. Die Architekt-Ausgabe DARF NICHT an den Kritiker weitergegeben werden. Architekt und Kritiker MÜSSEN sequenziell als separate, individuell erwartete Task-Aufrufe ausgeführt werden — niemals parallel — und der Kritiker-Task DARF NICHT ausgegeben werden, bis der Architekt-Task abgeschlossen und sein Ergebnis erwartet wurde. Der Kritiker DARF die Architekt-Überprüfung NICHT konsumieren oder erhalten. Architekt- und Kritiker-Ergebnisse DÜRFEN nur vom Planer während der Überarbeitung oder Verbesserungssynthese kombiniert werden, und nur nachdem beide Überprüfungen abgeschlossen sind.

5. Erneute Überprüfungsschleife (max. 5 Iterationen): Wenn der Kritiker ablehnt, diese geschlossene Schleife ausführen: a. Alle Ablehnungsrückmeldungen von Architekt + Kritiker sammeln (nur Planer-Synthese: Architekt- und Kritiker-Ergebnisse DÜRFEN nur vom Planer kombiniert werden, und nur nachdem beide Überprüfungen abgeschlossen sind). b. Rückmeldung an den Planer zur Erstellung eines überarbeiteten Plans weitergeben c. Zu Schritt 3 zurückkehren — Architekt überprüft den überarbeiteten Plan d. Zu Schritt 4 zurückkehren — Kritiker bewertet den überarbeiteten Plan e. Wiederholen, bis der Kritiker genehmigt ODER maximal 5 Iterationen erreicht sind f. Wenn maximale Iterationen ohne Genehmigung erreicht sind, die beste Version dem Benutzer mit AskUserQuestion präsentieren und darauf hinweisen, dass kein Expertenkonsens erzielt wurde

6. Verbesserungen anwenden: Wenn Prüfer mit Verbesserungsvorschlägen genehmigen, alle akzeptierten Verbesserungen in die Plandatei einarbeiten, bevor fortgefahren wird. Die endgültige Konsensausgabe MUSS einen ADR-Abschnitt enthalten mit: Entscheidung, Treiber, Alternativen in Betracht gezogen, Warum gewählt, Konsequenzen, Folgeaktionen. Konkret: a. Alle Verbesserungsvorschläge aus den Architekt- und Kritiker-Antworten sammeln b. Die Vorschläge deduplizieren und kategorisieren c. Die Plandatei in .omc/plans/ mit den akzeptierten Verbesserungen aktualisieren (fehlende Details hinzufügen, Schritte verfeinern, Abnahmekriterien stärken, ADR-Aktualisierungen usw.) d. In einem kurzen Änderungsprotokollabschnitt am Ende des Plans vermerken, welche Verbesserungen angewendet wurden

7. Bei Kritiker-Genehmigung (mit angewendeten Verbesserungen): den Planstatus als pending approval markieren, es sei denn, eine explizite Ausführungsgenehmigung wurde bereits erfasst. (nur --interactive) Wenn mit --interactive ausgeführt, AskUserQuestion verwenden, um den Plan mit diesen Optionen zu präsentieren:

   • Ausführung über Team genehmigen (Empfohlen) — explizites Opt-in zur Fortsetzung über koordinierte parallele Team-Agenten (/team). Team ist die kanonische Orchestrierungsoberfläche seit v4.1.7.
   • Ausführung über ralph genehmigen — explizites Opt-in zur Fortsetzung über Ralph-Persistenz mit Verifikation
   • Komprimieren und dann zur Ausführungsgenehmigung zurückkehren — explizites Opt-in, zuerst das Kontextfenster zu komprimieren (empfohlen, wenn der Kontext nach der Planung groß ist), dann beim gespeicherten, auf Genehmigung wartenden Plan anzuhalten und erneut zu fragen, bevor die Ausführung gestartet wird
   • Änderungen anfordern — mit Benutzerfeedback zu Schritt 1 zurückkehren
   • Ablehnen — den Plan vollständig verwerfen Wenn NICHT mit --interactive ausgeführt, den endgültigen Plan als pending approval markieren, state_clear(mode="ralplan", session_id=<current_session_id>) aufrufen und anhalten. Nicht automatisch ausführen.

8. (nur --interactive) Der Benutzer wählt über die strukturierte AskUserQuestion-Benutzeroberfläche aus (niemals nach Genehmigung in Klartext fragen). Wenn der Benutzer Ablehnen auswählt, state_clear(mode="ralplan", session_id=<current_session_id>) aufrufen und anhalten.

9. Bei Benutzer

…

[abgeschnitten für Übersetzung]