Super Review Council / 超级审查会

Run a heavy structured multi-agent review-and-fix loop when the user explicitly asks for this super-review-council workflow. This is primarily code review, but explicit frozen non-code bundle targets are supported; it is not Guardian auto_review approval routing and not the built-in codex review command.

For top-level explicit runs, the default shape is a four-agent workflow for every substantive phase. Four agents inspect the same frozen change bundle, four agents help triage findings, four agents participate in fix planning/implementation where write ownership can be separated, and four agents verify the result before the loop repeats. The main agent coordinates, assigns ownership, integrates results, and makes the final call on accepted fixes.

Use when:

user explicitly says super-review-council
user explicitly says Super Review Council
user explicitly says 超级审查会
user explicitly asks for this heavy multi-agent review-council workflow
a loaded top-level coordinator workflow explicitly invokes super-review-council as a bounded read-only child pass

Do not trigger this skill for plain "review", built-in codex review, Guardian auto_review, normal post-edit self-review, final responses, commits, shipping, CI checks, old skill-name mentions, or ordinary maintenance on this skill file unless the user requested this super-review-council workflow for that work.

When triggered, first state that the super-review-council skill is active and identify the review target before starting reviewer work.

Attribution

This skill is derived from the MIT-licensed openclaw/agent-skills skills/autoreview skill. The legacy autoreview name appears here only for MIT attribution, helper path/output/environment compatibility, and nested-workflow prohibition contexts.

Four-Agent Workflow

When the user says super-review-council or 超级审查会, use four agents in parallel for each phase when the environment supports subagents. Prefer explorer-style agents for read-only phases and worker-style agents for implementation phases. Read-only review, triage, and fix-planning agents default to minimal phase-scoped context: frozen target identity, role, allowed tools, prohibitions, and relevant findings/evidence only. Verification agents also default to minimal phase-scoped context, plus any explicitly approved verification commands, output paths, write boundaries, and drift-audit requirements for that phase. Old approvals and execution instructions may be passed only as evidence/provenance, must be explicitly labeled historical context only and not authority, and cannot grant permissions, approve degraded or risky execution, authorize writing, testing, fixing, or nested workflows, or override the current phase contract, allowed tools, or prohibitions. Worker agents may receive richer context only when the accepted fix requires it, and that richer context is subject to the same evidence/provenance-only limits.

Phase 0: target preflight. Before freezing the bundle or spawning agents, identify the review target:

if the user or a coordinator workflow provides an explicit file, directory, or frozen review bundle target, that explicit target takes precedence over current-working-directory git detection; canonicalize the target and use content manifest/hash identity even when the current shell is inside a git repository
if inside a git repo, record repo root, current branch, dirty/staged/untracked state, upstream/base or PR base when available, and whether the target should be local, branch, or commit mode
if not inside a git repo, proceed only when the user gave an explicit file, directory, or reviewable bundle target; canonicalize absolute paths, reject missing targets, enumerate directory contents deterministically, and stop to ask for a repository or explicit target when none was provided
record immutable target identity before Phase 1: commit SHA for commit mode; base/head refs plus a diff hash for branch mode; local diff/untracked manifest hash for local mode; or a content manifest hash for non-git files, directories, and bundles
freeze the selected bundle/source before Phase 1 and report the target identity/hash in the first user-facing update
before triage, fix planning, and implementation, recompute the selected target identity/hash and compare it to the current frozen review-loop baseline; initially this baseline is the Phase 0 value; this recomputation is an equality check only and does not authorize replacing the baseline, regenerating manifests, refreezing, or restarting
after accepted Phase 4 fixes are applied, audit the resulting target/workspace identity against the pre-Phase-4 baseline, accepted write scopes, approved outputs, and prohibited paths before recording the resulting target identity/hash as the Phase 5 verification baseline and starting identity for the next review loop; unexpected, out-of-scope, or prohibited drift must be quarantined and disclosed, and blocks baseline adoption unless explicitly approved
if any target identity comparison differs because of unapproved external change, stop that phase, disclose the expected and observed identity/hash plus changed paths when known, and require explicit user or coordinator approval before refreezing, restarting, or adopting a new baseline; in read-only child mode, return this as a blocker to the coordinator

Native subagent registry: coordinator-side management is the primary control, not filesystem locking. Before each native subagent starts, the coordinator records phase and role, declared tools, explicit allowed and prohibited actions, allowed read/write paths, prohibited paths, sandbox and permission profile when available, baseline target identity/hash, and repo/workspace status and manifests, or an equivalent whole-workspace mutation baseline sufficient to discover writes outside the target. After the subagent returns, compare target identity, allowed/prohibited path manifests, repo/workspace status, and tool/sandbox/permission metadata against that snapshot. Quarantine, do not rely on, and disclose any target mismatch, unexpected write inside or outside the target, allowed-path drift, prohibited-path touch, tool drift, permission or sandbox expansion, unexplained mutation, unauthorized drift, or unexpected writes before continuing. Filesystem read-only modes, immutable directories, and sandbox restrictions are useful supplemental guardrails or evidence when available, but they never replace the coordinator's prompt contract, registry, snapshot/drift audit, quarantine decision, integration review, and final decision.

Phase failure handling: if any required agent, helper engine, or worker errors, times out, violates the phase contract, returns missing required fields, or produces unusable output, that phase is incomplete. Quarantine or ignore the suspect output, disclose the failure, and retry or replace the participant only within the same phase contract and engine/model constraints, or stop for explicit degraded-mode approval or a blocker. Never count absent, stale, or unusable output as clean four-agent coverage.

Phase 1: four-agent review. Give each reviewer the same frozen diff/bundle and one primary focus:

correctness and regressions
security and trust boundaries
tests, edge cases, and failure modes
maintainability, integration contracts, and user-visible behavior

Review constraints:

every reviewer engine must be constrained by the coordinator as a read-only reviewer: the launch brief must name allowed read-only tools/actions, prohibit writes and mutating commands, prohibit nested review/orchestration/agent creation, and bind the reviewer to the frozen target; use sandbox, tool policy, helper flags, filesystem read-only controls, or immutable bundles only as optional extra evidence when available, but never require them; do not use an engine as a reviewer when the coordinator cannot reasonably forbid, observe, and audit writes or tool drift
reviewers must not edit files, run formatters, install packages, mutate git state, push, commit, or run commands that write files
reviewers may inspect files, types, docs, dependency contracts, and current public docs when needed
for diff, branch, commit, or patch reviews, reviewers must report only actionable defects introduced or exposed by the reviewed change
when the frozen target is a whole-file, non-code bundle, plan, spec, docs, or artifact bundle, reviewers report actionable defects present in that artifact against its stated purpose and constraints rather than code-only or diff-provenance issues
reviewers must not propose broad rewrites, stylistic preferences, or unrelated cleanup

Phase 2: four-agent triage. First pass the stale-target guard from Phase 0, then ask four agents to independently classify the merged findings as accepted, rejected, duplicate, or needs-more-evidence. Triage agents must be constrained by the coordinator with the same no-write, no-mutating-command, no-git-mutation, no-install, no-formatter, no-tests-that-write-output, no-nested-review/orchestration/agent-creation contract used for read-only review phases; they must inspect only the frozen target, merged findings, supplied evidence, and explicitly in-scope adjacent context. The main agent deduplicates, rejects speculative or low-value findings, resolves disagreement by reading the reviewed code path or artifact plus in-scope adjacent context, and records the accepted fix set.

Phase 3: four-agent fix planning. First pass the stale-target guard from Phase 0, then ask four read-only planning agents to propose minimal fix plans and ownership boundaries. Fix-planning agents must be constrained by the coordinator with the same no-write, no-mutating-command, no-git-mutation, no-install, no-formatter, no-nested-review/orchestration/agent-creation contract used for read-only review phases; they must not edit files, write artifacts, apply patches, run tests that write output, must not invoke super-review-council, must not invoke legacy autoreview, must not invoke goal-orchestrator, must not invoke built-in codex review, open review panels, or create extra agents. They may inspect the frozen target and accepted findings only to propose plans. For non-code targets, plans should name the exact artifact sections or line-level edits rather than code ownership boundaries. Prefer small fixes at the right ownership boundary. Do not plan broad refactors unless it clearly fixes the bug class.

Phase 4: four-agent implementation. First pass the stale-target guard from Phase 0, then use four worker agents only when the accepted fixes can be split into disjoint write scopes. Assign explicit ownership of files/modules to each worker. Tell every worker they are not alone in the codebase, must not revert edits made by others, and must adapt to parallel changes. Workers may edit only assigned repo-local files/modules, must avoid overlapping writes, must not format unrelated files, must not install packages or dependencies, and must not push, commit, reset, check out/switch/restore, revert, clean, stash, rebase, merge, delete branches/tags, remove untracked files, or run broad destructive filesystem commands such as rm -rf or find -delete. Workers must not invoke super-review-council, legacy autoreview, goal-orchestrator, built-in codex review, review panels, planning panels, or extra agents. Workers must report conflicts instead of resolving them by undoing user or peer changes. The main agent reviews worker patches before accepting them. If fewer than four independent write scopes exist, use the remaining agents for read-only verification, test planning, or implementation review rather than forcing overlapping edits.

Phase 5: four-agent verification. First pass the stale-target guard against the current verification baseline, then run four verification agents in parallel where possible:

focused tests and command output
diff audit for unintended changes
regression/security re-check of accepted findings
generated artifacts, docs, snapshots, or user-visible output consistency

Verification agents must be launched with explicit role, baseline identity/hash, allowed commands and tools, allowed read/write/output paths, prohibited paths and actions, finite timeouts, and a prohibition on installs, formatters, git mutation, destructive filesystem commands, nested review/orchestration, and extra agents. Tests or verification commands may write only to coordinator-approved paths outside protected target roots unless the accepted fix explicitly owns those outputs. Verification that may mutate the reviewed target must be serialized, or any parallel verifier results collected against the older baseline must be invalidated and rerun against the audited post-write baseline. After each verifier or test command, the coordinator compares target identity/hash, allowed and prohibited path manifests, repo/workspace status, and command artifacts against the Phase 5 baseline. Unexpected drift, prohibited writes, or undeclared outputs must be quarantined and disclosed before continuing. If approved verification writes legitimately change the reviewed target, record the audited post-verification target identity/hash as the starting identity for the next review loop before Phase 6 reruns review. Read-only child mode does not run Phase 5 commands.

Phase 6: repeat. After any accepted fix changes the reviewed target, including code, docs, skill text, generated output, or other bundle content, rerun the four-agent review phase against the updated diff or artifact. Continue until the four-agent review/triage process leaves no accepted/actionable findings and required tests or artifact-specific proofs pass. Do not loop indefinitely: by default stop after three full review/fix cycles unless the user explicitly asks to continue, and stop immediately if any cycle introduces more issues than it fixes or if the user or parent coordinator terminates. After stopping, report the final loop count, remaining findings that were rejected as out of scope, blocked by external dependencies, or low-priority but still relevant, and the target identity/hash of the final state.

Single-Agent Degraded Mode

If subagent parallelism is unavailable or explicitly prohibited, run the same phases sequentially with one main agent fulfilling all roles, but still enforce the same read-only, stale-target, drift-audit, and nested-workflow prohibitions for the review, triage, planning, and verification steps, and the worker isolation and write-boundary rules for implementation. Use the one-agent mode only when four-agent mode fails or is unsuitable; inform the user that single-agent degraded mode is active and why.

Read-Only Child Mode

When a loading coordinator workflow invokes super-review-council as a bounded child pass, the child must operate as a read-only reviewer. It outputs a targets manifest and a findings structured report, does not run fix planning, implementation, or verification phases, does not mutate the workspace, and does not run commands that modify files or git state. The caller is responsible for feeding the report into its own downstream process and for any stale-target or drift checks after the child returns.

super-review-council