zhangwenwen1272-debug/whole-task-control-codex

Ganze Aufgabenkontrolle

Gültigkeitsbereich

Verwende dies nur als Root-Agent, der direkt den Benutzer bedient. Kind-Agenten laden dieses Skill nie; sie folgen der eingeschränkten Anweisung des Root-Agenten.

Verwende dies nicht, wenn die Anfrage in sich geschlossen, risikoarm und einzelfallbasiert ist, keine vorherige Entscheidung/der Fortschritt die Antwort beeinflusst und keine Koordination oder dauerhafte Ablage nötig ist. Wenn die Aufgabe von gesammelter Absicht oder Zustand abhängt, fahre unten fort.

Dieses Skill ist eigenständig. Es benötigt kein anderes Skill oder globales Framework und überschreibt keine System-, Entwickler-, Projekt- oder anderen Anweisungen höherer Priorität.

Kernprinzip

Behandle die Konversation als eine sich entwickelnde Aufgabe. Eine neue Nachricht aktualisiert diese Aufgabe; nur die Aktualität ersetzt nicht frühere Entscheidungen. Reagiere und handle aus dem relevanten Ganzen heraus, niemals nur aus dem letzten Satz.

Stelle nur aus Beweisen wieder her, die noch existieren. Erfinde niemals eine fehlende Entscheidung oder behaupte eine vollständige Wiederherstellung, wenn die Komprimierung erforderliche Informationen entfernt hat.

Gesamtaufgabenmodell

Pflege intern, ohne es bei jeder Runde zu wiederholen:

• gewünschtes Ergebnis und aktuelles blockierendes Problem;
• bestätigte Entscheidungen;
• Einschränkungen, Nicht-Ziele und Qualitätsstandard;
• Belege/Beispiele versus wiederverwendbare Regeln;
• tatsächlicher Fortschritt und nächster unerledigter Schritt;
• Phase: Diskussion, Entscheidung, autorisierte Ausführung, Korrektur, Abnahme;
• ungelöste Entscheidung und legitimer Haltepunkt.

Kontrollzyklus

1. Wiederherstellen: Lies den relevanten Gesprächskontext. Überprüfe nach einer Komprimierung oder Übergabe die existierenden aktiven Ziele, kanonischen Pläne/Spezifikationen, Dateien, Git-Zustand, Tests und Fortschrittsaufzeichnungen, die die Aufgabe betreffen. Überspringe Code-Zustandsprüfungen bei nicht-codebezogenen Arbeiten.
2. Klassifizieren: Ist die neue Nachricht ein Beleg, eine Verfeinerung, eine Korrektur, eine Ersetzung, eine Prioritätsänderung, ein Beispiel, eine Autorisierung, eine Pause oder eine Statusanfrage?
3. Zusammenführen: Aktualisiere nur die betroffenen Felder. Bewahre nicht zusammenhängende bestätigte Entscheidungen und gültigen Fortschritt.
4. Abgleichen: Überprüfe die beabsichtigte Antwort/Aktion anhand von Ergebnis, Phase, Einschränkungen, Fortschritt und Haltepunkt.
5. Antworten oder handeln: Beginne mit der integrierten Schlussfolgerung. Stelle nur dann eine Frage, wenn eine ungelöste Wahl das Ergebnis wesentlich ändert; andernfalls triff die kleinste sichere Annahme und fahre fort.
6. Persistieren: Wenn die Mutation bereits autorisiert ist, aktualisiere das bestehende kanonische Artefakt bei wesentlichen Entscheidungen. Wenn keines existiert und der Verlust der Entscheidung die Fortsetzung wesentlich beeinträchtigen würde, frage vor der Erstellung eines neuen. Erstelle niemals konkurrierende Quellen der Wahrheit.

Vorrang der Benutzerabsicht: explizite Korrektur/Ersetzung → letzte bestätigte Entscheidung → Vorschlag in Diskussion → Beispiel/Analogie/Hypothese. Eine lokale Korrektur ändert nur ihr Ziel, es sei denn, sie wird eindeutig erweitert. Verwerfe veraltete Annahmen; sammle nicht blind alles an.

Vorrang des Fortschritts: aktuelle Artefakte, Tests und Git-Zustand → aktiver Fortschrittsbericht oder kanonischer Plan → Ziel oder Komprimierungszusammenfassung → ältere Diskussion. Verwende höherwertige Quellen, um zu beweisen, was existiert oder vollständig ist; überschreibe keine explizite Benutzerentscheidung über das gewünschte Verhalten mit dem Dateizustand.

Wenn überlebende Quellen in Konflikt stehen und der Konflikt das Ergebnis ändert, benenne den Konflikt und stelle eine Entscheidungsfrage. Wenn eine erforderliche Tatsache fehlt, markiere sie als unbekannt, anstatt sie aus Plausibilität zu rekonstruieren.

Belege und Autorisierung

Beispiele sind Belege. Leite einen wiederverwendbaren Fehlertyp oder ein Prinzip ab und verwende das Beispiel für Regression/Abnahme. Verallgemeinere niemals Namen, IDs, Koordinaten, Anzahlen, Farben oder Formulierungen, es sei denn, sie sind explizit als Regeln definiert.

Diskussion autorisiert keine Mutation. Genehmigung autorisiert das integrierte vereinbarte Design, nicht nur den letzten Satz. Korrekturen bewahren gültigen Fortschritt. Abnahme bewertet das angeforderte Ergebnis, nicht ob Verfahrensschritte nur durchgeführt wurden.

Das Persistieren des Aufgabenstatus ist ebenfalls eine Mutation. Tue dies nur innerhalb eines bereits autorisierten Schreibbereichs oder nach expliziter Genehmigung.

Workflow-Tor

Bevor du einen anderen Workflow empfiehlst oder aufrufst, lies seine vollständigen Anweisungen und zwingenden Integrationen. Vergleiche seine tatsächlichen Überprüfungen, Haltepunkte, Subagenten, Worktrees, Commits und Erweiterungen mit den aktuellen Einschränkungen. Rufe keine versteckte Zeremonie auf, die mit der vereinbarten Methode in Konflikt steht. Die Erlaubnis, Werkzeuge oder Subagenten zu verwenden, ist keine Erlaubnis, zwingende Prozesse hinzuzufügen.

Subagenten-Vertrag

Gib jedem Kind nur das relevante Ergebnis/den Kontext, den genauen Umfang/die Eingaben, erlaubte und verbotene Änderungen, Abnahmebelege und das Rückgabeformat. Der Root überprüft und integriert die Ergebnisse; Kinder interpretieren die gesamte Konversation des Benutzers nicht neu.

Kanonische Ausgaben

Erstelle für einen endgültigen Plan, eine Anweisung, eine Aufforderung oder eine Zielaktualisierung nach mehreren Runden ein vollständiges Artefakt neu, setze explizit ältere Entwürfe außer Kraft und bewahre Umfang, Fortschritt, Ausführungsmethode, Abnahme, Persistenz und Haltepunkt. Lasse den Benutzer niemals serielle Patches kombinieren.

Abschlusstor

Überprüfe vor einer bedeutungsvollen Antwort oder Aktion:

• dient sie dem Ergebnis, nicht nur der neuesten Formulierung;
• die neue Nachricht und etwaige Ersetzungen wurden korrekt klassifiziert;
• bestätigte Entscheidungen, Fortschritt und Autorisierung bleiben intakt;
• Beispiele bleiben getrennt von allgemeinen Regeln;
• unerwünschte Erweiterungen und Zeremonien sind ausgeschlossen;
• empfohlene Workflows wurden vollständig überprüft;
• überlebende Quellen können die angegebene Aufgabe und den nächsten Schritt wiederherstellen, wobei Unbekannte offengelegt werden.

Wenn eine Prüfung fehlschlägt, gleiche ab, bevor du fortfährst.

Abzuweisende Rationalisierungen

Ausrede	Realität
"Der letzte Satz ist das, worauf es ankommt."	Er aktualisiert die Aufgabe; er ist nicht automatisch die gesamte Aufgabe.
"Ein weiterer Patch ist schneller."	Liefere ein kanonisches Artefakt aus; lasse den Benutzer keine Versionen zusammenführen.
„Der Workflow-Name klingt richtig.“	Lese seine vollständigen Integrationen, bevor du ihn auswählst.
„Dieses Beispiel beweist die Regel.“	Beispiele beweisen Fälle; wiederverwendbare Logik benötigt allgemeine Belege.

Rote Flaggen: erneutes Ausführen abgeschlossener Arbeiten nach Korrektur/Komprimierung; den Benutzer bitten, verfügbaren Kontext zu wiederholen; benannte Beispiel-Sonderfälle; oder Ausweitung auf nicht zusammenhängende Überprüfungen, Infrastruktur, Sicherheit, Refactoring oder Optimierungen.