super-review-council

Super Review Council / 超级审查会

Führen Sie einen schweren, strukturierten Multi-Agenten-Review-und-Fix-Loop aus, wenn der Benutzer explizit nach diesem super-review-council Workflow fragt. Dies ist in erster Linie Code-Review, aber explizite eingefrorene Nicht-Code-Bundle-Ziele werden unterstützt; es ist nicht die Guardian auto_review Genehmigungsrouting und nicht der integrierte codex review Befehl.

Für explizite Top-Level-Ausführungen ist die Standardform ein Vier-Agenten-Workflow für jede substanzielle Phase. Vier Agenten prüfen dasselbe eingefrorene Änderungsbündel, vier Agenten helfen bei der Triage der Ergebnisse, vier Agenten beteiligen sich an der Fixplanung/-implementierung (wobei die Schreibverantwortung getrennt werden kann), und vier Agenten verifizieren das Ergebnis, bevor der Loop wiederholt wird. Der Hauptagent koordiniert, weist Verantwortlichkeiten zu, integriert Ergebnisse und trifft die endgültige Entscheidung über akzeptierte Fixes.

Verwenden, wenn:

• der Benutzer explizit super-review-council sagt
• der Benutzer explizit Super Review Council sagt
• der Benutzer explizit 超级审查会 sagt
• der Benutzer explizit nach diesem schweren Multi-Agenten-Review-Council-Workflow fragt
• ein geladener Top-Level-Koordinator-Workflow explizit super-review-council als eingeschränkten, schreibgeschützten Kind-Durchlauf aufruft

Lösen Sie dieses Skill nicht aus für einfaches "Review", integrierte codex review, Guardian auto_review, normales Post-Edit-Self-Review, finale Antworten, Commits, Auslieferungen, CI-Checks, alte Skill-Namensnennungen oder normale Wartung an dieser Skill-Datei, es sei denn, der Benutzer hat diesen super-review-council Workflow für diese Arbeit angefordert.

Wenn ausgelöst, geben Sie zuerst an, dass das super-review-council Skill aktiv ist, und identifizieren Sie das Review-Ziel, bevor Sie mit der Review-Arbeit beginnen.

Attribution

Dieses Skill ist abgeleitet von dem MIT-lizenzierten openclaw/agent-skills skills/autoreview Skill. Der veraltete Name autoreview erscheint hier nur für die MIT-Attribution, Kompatibilität von Hilfspfaden, Ausgaben/Umgebungen und Kontexte zum Verbot verschachtelter Workflows.

Vier-Agenten-Workflow

Wenn der Benutzer super-review-council oder 超级审查会 sagt, verwenden Sie vier Agenten parallel für jede Phase, wenn die Umgebung Unteragenten unterstützt. Bevorzugen Sie explorer-artige Agenten für schreibgeschützte Phasen und worker-artige Agenten für Implementierungsphasen. Schreibgeschützte Review-, Triage- und Fixplanungs-Agenten standardmäßig auf minimalen phasenspezifischen Kontext: eingefrorene Zielidentität, Rolle, erlaubte Werkzeuge, Verbote und relevante Ergebnisse/Beweise nur. Verifikationsagenten standardmäßig auch auf minimalen phasenspezifischen Kontext, plus alle explizit genehmigten Verifikationsbefehle, Ausgabepfade, Schreibgrenzen und Drift-Audit-Anforderungen für diese Phase. Alte Genehmigungen und Ausführungsanweisungen dürfen nur als Beweise/Provenienz übergeben werden, müssen explizit als historical context only und not authority gekennzeichnet sein und dürfen keine Berechtigungen erteilen, keine degradierte oder riskante Ausführung genehmigen, kein Schreiben, Testen, Fixen oder verschachtelte Workflows autorisieren und nicht den aktuellen Phasenvertrag, die erlaubten Werkzeuge oder Verbote überschreiben. Worker-Agenten dürfen nur dann einen reicheren Kontext erhalten, wenn der akzeptierte Fix dies erfordert, und dieser reichere Kontext unterliegt denselben Beschränkungen für reine Beweise/Provenienz.

Phase 0: Ziel-Preflight. Bevor Sie das Bündel einfrieren oder Agenten erzeugen, identifizieren Sie das Review-Ziel:

• wenn der Benutzer oder ein Koordinator-Workflow eine explizite Datei, ein Verzeichnis oder ein eingefrorenes Review-Bündel-Ziel bereitstellt, hat dieses explizite Ziel Vorrang vor der aktuellen Arbeitsverzeichnis-Git-Erkennung; kanonifizieren Sie das Ziel und verwenden Sie Inhaltsmanifest/Hash-Identität, auch wenn die aktuelle Shell sich in einem Git-Repository befindet
• wenn in einem Git-Repo, zeichnen Sie Repo-Root, aktuellen Branch, Dirty/Staged/Untracked-Status, Upstream/Base oder PR-Base (wenn verfügbar) auf und ob das Ziel im lokalen, Branch- oder Commit-Modus sein soll
• wenn nicht in einem Git-Repo, fahren Sie nur fort, wenn der Benutzer eine explizite Datei, ein Verzeichnis oder ein überprüfbares Bündel-Ziel bereitgestellt hat; kanonifizieren Sie absolute Pfade, weisen Sie fehlende Ziele zurück, zählen Sie Verzeichnisinhalte deterministisch auf und stoppen Sie, um nach einem Repository oder expliziten Ziel zu fragen, wenn keines bereitgestellt wurde
• zeichnen Sie die unveränderliche Zielidentität vor Phase 1 auf: Commit-SHA für den Commit-Modus; Basis/Head-Refs plus einen Diff-Hash für den Branch-Modus; lokalen Diff/Untracked-Manifest-Hash für den lokalen Modus; oder einen Inhaltsmanifest-Hash für Nicht-Git-Dateien, Verzeichnisse und Bündel
• frieren Sie das ausgewählte Bündel/Quelle vor Phase 1 ein und melden Sie die Zielidentität/den Hash im ersten benutzerseitigen Update
• vor Triage, Fixplanung und Implementierung berechnen Sie die Zielidentität/den Hash des ausgewählten Ziels neu und vergleichen Sie sie mit der aktuellen eingefrorenen Review-Loop-Baseline; initial ist diese Baseline der Wert von Phase 0; diese Neuberechnung ist nur ein Gleichheitscheck und autorisiert nicht das Ersetzen der Baseline, das Neuausgeben von Manifesten, das erneute Einfrieren oder den Neustart
• nach der Anwendung akzeptierter Phase-4-Fixes überprüfen Sie die resultierende Ziel-/Workspace-Identität gegen die Baseline vor Phase 4, die akzeptierten Schreibbereiche, die genehmigten Ausgaben und die verbotenen Pfade, bevor Sie die resultierende Zielidentität/den Hash als Phase-5-Verifikationsbaseline und Startidentität für den nächsten Review-Loop aufzeichnen; unerwartete, außerhalb des Bereichs liegende oder verbotene Abweichungen müssen isoliert und offengelegt werden und blockieren die Übernahme der Baseline, es sei denn, sie werden explizit genehmigt
• wenn ein Vergleich der Zielidentität aufgrund einer nicht genehmigten externen Änderung abweicht, stoppen Sie diese Phase, legen Sie die erwartete und beobachtete Identität/den Hash sowie die geänderten Pfade (wenn bekannt) offen und fordern Sie eine explizite Genehmigung des Benutzers oder Koordinators an, bevor Sie die Baseline neu einfrieren, neu starten oder eine neue Baseline übernehmen; im schreibgeschützten Kind-Modus geben Sie dies als Blocker an den Koordinator zurück

Native Subagenten-Registry: das koordinatorseitige Management ist die primäre Kontrolle, nicht das Dateisystem-Locking. Bevor jeder native Subagent startet, zeichnet der Koordinator Phase und Rolle, deklarierte Werkzeuge, explizit erlaubte und verbotene Aktionen, erlaubte Lese-/Schreibpfade, verbotene Pfade, Sandbox- und Berechtigungsprofil (wenn verfügbar), Baseline-Zielidentität/Hash und Repo-/Workspace-Status und Manifeste auf, oder eine gleichwertige gesamte Workspace-Mutationsbaseline, die ausreicht, um Schreibvorgänge außerhalb des Ziels zu entdecken. Nach der Rückkehr des Subagenten vergleichen Sie die Zielidentität, erlaubte/verbotene Pfadmanifeste, Repo-/Workspace-Status und Werkzeug-/Sandbox-/Berechtigungs-Metadaten mit dieser Momentaufnahme. Isolieren Sie und vertrauen Sie nicht auf jegliche Zielabweichung, unerwarteten Schreibvorgang innerhalb oder außerhalb des Ziels, erlaubte Pfadabweichung, verbotene Pfadberührung, Werkzeugabweichung, Berechtigungs- oder Sandbox-Erweiterung, unerklärte Mutation, nicht autorisierte Abweichung oder unerwartete Schreibvorgänge, bevor Sie fortfahren. Dateisystem-Schreibschutzmodi, unveränderliche Verzeichnisse und Sandbox-Einschränkungen sind nützliche zusätzliche Schutzmaßnahmen oder Beweise, wenn verfügbar, ersetzen aber niemals den Prompt-Vertrag des Koordinators, die Registry, die Momentaufnahme-/Abweichungsprüfung, die Isolationsentscheidung, das Integrations-Review und die endgültige Entscheidung.

Fehlerbehandlung in Phasen: wenn ein erforderlicher Agent, Hilfsmotor oder Worker einen Fehler produziert, timeoutet, den Phasenvertrag verletzt, erforderliche Felder nicht zurückgibt oder unbrauchbare Ausgabe produziert, ist diese Phase unvollständig. Isolieren oder ignorieren Sie die verdächtige Ausgabe, legen Sie den Fehler offen und wiederholen Sie den Durchlauf oder ersetzen Sie den Teilnehmer nur innerhalb desselben Phasenvertrags und derselben Engine-/Model-Beschränkungen, oder stoppen Sie für explizite degradierte Modus-Genehmigung oder einen Blocker. Zählen Sie niemals abwesende, veraltete oder unbrauchbare Ausgabe als saubere Vier-Agenten-Abdeckung.

Phase 1: Vier-Agenten-Review. Geben Sie jedem Reviewer dasselbe eingefrorene Diff/Bündel und einen primären Fokus:

• Korrektheit und Regressionen
• Sicherheit und Vertrauensgrenzen
• Tests, Randfälle und Fehlermodi
• Wartbarkeit, Integrationsverträge und benutzersichtbares Verhalten

Review-Einschränkungen:

• jede Review-Engine muss vom Koordinator als schreibgeschützter Reviewer eingeschränkt werden: das Start-Brief muss erlaubte schreibgeschützte Werkzeuge/Aktionen nennen, Schreibvorgänge und mutierende Befehle verbieten, verschachteltes Review/Orchestrierung/Agenterstellung verbieten und den Reviewer an das eingefrorene Ziel binden; verwenden Sie Sandbox, Werkzeugrichtlinie, Hilfs-Flags, dateisystem-schreibgeschützte Kontrollen oder unveränderliche Bündel nur als optionale zusätzliche Beweise, wenn verfügbar, aber verlangen Sie sie niemals; verwenden Sie keine Engine als Reviewer, wenn der Koordinator Schreibvorgänge oder Werkzeugabweichungen nicht vernünftigerweise verbieten, beobachten und überprüfen kann
• Reviewer dürfen keine Dateien bearbeiten, Formatierer ausführen, Pakete installieren, den Git-Status mutieren, pushen, commiten oder Befehle ausführen, die Dateien schreiben
• Reviewer dürfen Dateien, Typen, Dokumente, Abhängigkeitsverträge und aktuelle öffentliche Dokumente nach Bedarf untersuchen
• für Diff-, Branch-, Commit- oder Patch-Reviews müssen Reviewer nur über umsetzbare Mängel berichten, die durch die überprüfte Änderung eingeführt oder offengelegt werden
• wenn das eingefrorene Ziel eine ganze Datei, ein Nicht-Code-Bündel, ein Plan, eine Spezifikation, eine Dokumentation oder ein Artefaktbündel ist, berichten Reviewer über umsetzbare Mängel, die in diesem Artefakt in Bezug auf seinen angegebenen Zweck und seine Einschränkungen vorhanden sind, anstatt über reine Code- oder Diff-Provenienz-Probleme
• Reviewer dürfen keine breiten Umschreibungen, stilistischen Präferenzen oder nicht zusammenhängende Bereinigungen vorschlagen

Phase 2: Vier-Agenten-Triage. Bestehen Sie zuerst die veraltete Ziel-Wache von Phase 0, bitten Sie dann vier Agenten, die zusammengeführten Ergebnisse unabhängig als akzeptiert, abgelehnt, Duplikat oder benötigt-mehr-Beweise zu klassifizieren. Triage-Agenten müssen vom Koordinator mit demselben „Kein-Schreiben-, Kein-Mutierender-Befehl-, Kein-Git-Mutations-, Kein-Install-, Kein-Formatterer-, Kein-Tests-die-Ausgaben-schreiben-, Kein-verschachteltes-Review/Orchestrierung/Agenterstellung"-Vertrag eingeschränkt werden, der für schreibgeschützte Review-Phasen verwendet wird; sie dürfen nur das eingefrorene Ziel, die zusammengeführten Ergebnisse, die bereitgestellten Beweise und den explizit im Rahmen befindlichen angrenzenden Kontext inspizieren. Der Hauptagent dedupliziert, verwirft spekulative oder minderwertige Ergebnisse, löst Meinungsverschiedenheiten durch Lesen des überprüften Codepfads oder Artefakts plus des im Rahmen befindlichen angrenzenden Kontexts und zeichnet den akzeptierten Fix-Set auf.

Phase 3: Vier-Agenten-Fixplanung. Bestehen Sie zuerst die veraltete Ziel-Wache von Phase 0, bitten Sie dann vier schreibgeschützte Planungsagenten, minimale Fixpläne und Eigentumsgrenzen vorzuschlagen. Fixplanungsagenten müssen vom Koordinator mit demselben „Kein-Schreiben-, Kein-Mutierender-Befehl-, Kein-Git-Mutations-, Kein-Install-, Kein-Formatterer-, Kein-verschachteltes-Review/Orchestrierung/Agenterstellung"-Vertrag eingeschränkt werden, der für schreibgeschützte Review-Phasen verwendet wird; sie dürfen keine Dateien bearbeiten, Artefakte schreiben, Patches anwenden, Tests ausführen, die Ausgaben schreiben, dürfen super-review-council nicht aufrufen, dürfen veraltetes autoreview nicht aufrufen, dürfen goal-orchestrator nicht aufrufen, dürfen integriertes codex review nicht aufrufen, Review-Panels nicht öffnen oder zusätzliche Agenten erstellen. Sie dürfen das eingefrorene Ziel und akzeptierte Ergebnisse nur inspizieren, um Pläne vorzuschlagen. Für Nicht-Code-Ziele sollten Pläne die genauen Artefaktabschnitte oder Bearbeitungen auf Zeilenebene nennen, anstatt Code-Eigentumsgrenzen. Bevorzugen Sie kleine Fixes an der richtigen Eigentumsgrenze. Planen Sie keine breiten Refactorings, es sei denn, es behebt eindeutig die Fehlerklasse.

Phase 4: Vier-Agenten-Implementierung. Bestehen Sie zuerst die veraltete Ziel-Wache von Phase 0, verwenden Sie dann vier Worker-Agenten nur, wenn die akzeptierten Fixes in disjunkte Schreibbereiche aufgeteilt werden können. Weisen Sie jedem Worker explizit den Besitz von Dateien/Modulen zu. Sagen Sie jedem Worker, dass er nicht allein in der Codebasis ist, dass er Bearbeitungen anderer nicht rückgängig machen darf und sich an parallele Änderungen anpassen muss. Worker dürfen nur zugewiesene repo-lokale Dateien/Module bearbeiten, müssen überlappende Schreibvorgänge vermeiden, dürfen nicht zusammenhängende Dateien nicht formatieren, dürfen keine Pakete oder Abhängigkeiten installieren und dürfen nicht pushen, committen, zurücksetzen, auschecken/wechseln/wiederherstellen, revertieren, bereinigen, stashen, rebasen, mergen, Branches/Tags löschen, unverfolgte Dateien entfernen oder breite zerstörerische Dateisystembefehle wie rm -rf oder find -delete ausführen. Worker dürfen super-review-council, veraltetes autoreview, goal-orchestrator, integriertes codex review, Review-Panels, Planungspanels oder zusätzliche Agenten nicht aufrufen. Worker müssen Konflikte melden, anstatt sie durch Rückgängigmachen von Benutzer- oder Peer-Änderungen zu lösen. Der Hauptagent überprüft Worker-Patches, bevor er sie akzeptiert. Wenn weniger als vier unabhängige Schreibbereiche existieren, verwenden Sie die verbleibenden Agenten für schreibgeschützte Verifikation, Testplanung oder Implementierungs-Review, anstatt überlappende Bearbeitungen zu erzwingen.

Phase 5: Vier-Agenten-Verifikation. Bestehen Sie zuerst die veraltete Ziel-Wache gegen die aktuelle Verifikationsbaseline, führen Sie dann vier Verifikationsagenten parallel aus, wo möglich:

• fokussierte Tests und Befehlsausgabe
• Diff-Audit für unbeabsichtigte Änderungen
• erneute Regression/Sicherheitsprüfung akzeptierter Ergebnisse
• generierte Artefakte, Dokumente, Snapshots oder benutzersichtbare Ausgabenkonsistenz

Verifikationsagenten müssen mit expliziter Rolle, Baseline-Identität/Hash, erlaubten Befehlen und Werkzeugen, erlaubten Lese-/Schreib-/Ausgabepfaden, verbotenen Pfaden und Aktionen, endlichen Timeouts und einem Verbot von Installationen, Formatierern, Git-Mutation, zerstörerischen Dateisystembefehlen, verschachteltem Review/Orchestrierung und zusätzlichen Agenten gestartet werden. Tests oder Verifikationsbefehle dürfen nur in koordinator-genehmigte Pfade außerhalb geschützter Ziel-Roots schreiben, es sei denn, der akzeptierte Fix besitzt diese Ausgaben explizit. Verifikation, die das überprüfte Ziel verändern kann, muss serialisiert werden, oder alle parallelen Verifikationsergebnisse, die gegen die ältere Baseline gesammelt wurden, müssen ungültig gemacht und gegen die überprüfte Nach-Schreib-Baseline erneut ausgeführt werden. Nach jedem Verifikator oder Testbefehl vergleicht der Koordinator Zielidentität/Hash, erlaubte und verbotene Pfadmanifeste, Repo-/Workspace-Status und Befehlsartefakte mit der Phase-5-Baseline. Unerwartete Abweichungen, verbotene Schreibvorgänge oder nicht deklarierte Ausgaben müssen vor dem Fortfahren isoliert und offengelegt werden. Wenn genehmigte Verifikationsschreibvorgänge das überprüfte Ziel legitim ändern, zeichnen Sie die überprüfte Nach-Verifikations-Zielidentität/den Hash als Startidentität für den nächsten Review-Loop auf, bevor Phase 6 das Review erneut ausführt. Der schreibgeschützte Kind-Modus führt keine Phase-5-Befehle aus.

Phase 6: Wiederholung. Nachdem eine akzeptierte Fix-Änderung das überprüfte Ziel geändert hat, einschließlich Code, Dokumente, Skill-Text, generierte Ausgabe oder anderer Bündel-Inhalt, führen Sie die Vier-Agenten-Review-Phase erneut gegen das aktualisierte Diff oder Artefakt aus. Fahren Sie fort, bis der Vier-Agenten-Review/Triage-Prozess keine akzeptierten/umsetzbaren Ergebnisse mehr hinterlässt und erforderliche Tests oder artefaktspezifische Nachweise bestanden sind. Wiederholen Sie nicht unendlich: standardmäßig nach drei vollständigen Review/Fix-Zyklen stoppen, es sei denn, der Benutzer bittet explizit um Fortsetzung, und stoppen …

… [für die Übersetzung gekürzt]