name	cross-tier-review
description	Cross-tier review protocol — chain of verification for REVIEW REQUEST messages from Claude Code (Tier 2). Includes 5-step checklist and REVIEW_JSON output format.
allowed-tools	Bash
user-invocable	false
metadata	{"openclaw":{"always":true}}

Cross-Tier Review Protocol — Chain of Verification

When you see "REVIEW REQUEST:" in an infra room, Claude Code (Tier 2) is asking you to review its work because its confidence was below 0.7. You MUST perform a structured verification before giving your verdict.

Verification Checklist (execute ALL steps)

CLAIM CHECK: What factual claims does the analysis make? Use the exec tool to independently verify at least ONE claim (e.g., check a service status, query YT issue, look up a host in NetBox). Do NOT just read and agree.
ASSUMPTION CHECK: What assumptions are implicit? Flag any that are unsupported by evidence in the analysis.
ALTERNATIVE CHECK: What alternative root causes were NOT considered? Name at least one plausible alternative, even if you think Claude's diagnosis is correct.
RISK CHECK: Could the proposed action cause secondary failures? Check for dependencies (e.g., will restarting X affect Y? Does draining node Z displace SeaweedFS pods?).
RECURRENCE CHECK: If this host/alert has a knowledge base entry, does the proposed fix address the root cause or just patch the symptom again?

Verdict

After verification, reply with ONE of:

REVIEW: AGREE — brief reason why the analysis looks correct after verification
REVIEW: DISAGREE — specific issue found (wrong root cause, unsafe action, missing evidence)
REVIEW: AUGMENT — additional context to add (things Claude missed, alternative causes)

After your verdict line, output a structured JSON block so the gateway can parse it:

REVIEW_JSON:{"verdict":"AGREE|DISAGREE|AUGMENT","confidence":0.X,"reason":"one-line reason","issueId":"IFRNLLEI01PRD-XXX","claims_verified":1,"alternatives_considered":1}

Rules

ALWAYS verify at least one claim via exec before giving your verdict
If confidence was < 0.5, pay extra attention to hallucinated fixes
If you find the proposed action could cause secondary failures, ALWAYS DISAGREE
Do NOT escalate review requests. This is YOUR job as independent critic.

Dev Task Reviews (CUBEOS/MESHSAT)

For development review requests, adjust the checklist:

CLAIM CHECK: Verify at least one code claim via codegraph-lookup
TEST CHECK: Were tests run? Did they pass?
SCOPE CHECK: Did the changes stay within the issue scope?
RISK CHECK: Could changes break other modules?
CONVENTION CHECK: Does the code follow project conventions?

Cross-Tier Review Protocol — Chain of Verification

Verification Checklist (execute ALL steps)

CLAIM CHECK: What factual claims does the analysis make? Use the exec tool to independently verify at least ONE claim (e.g., check a service status, query YT issue, look up a host in NetBox). Do NOT just read and agree.

ASSUMPTION CHECK: What assumptions are implicit? Flag any that are unsupported by evidence in the analysis.

ALTERNATIVE CHECK: What alternative root causes were NOT considered? Name at least one plausible alternative, even if you think Claude's diagnosis is correct.

RISK CHECK: Could the proposed action cause secondary failures? Check for dependencies (e.g., will restarting X affect Y? Does draining node Z displace SeaweedFS pods?).

RECURRENCE CHECK: If this host/alert has a knowledge base entry, does the proposed fix address the root cause or just patch the symptom again?

Verdict

After verification, reply with ONE of:

REVIEW: AGREE — brief reason why the analysis looks correct after verification

REVIEW: DISAGREE — specific issue found (wrong root cause, unsafe action, missing evidence)

REVIEW: AUGMENT — additional context to add (things Claude missed, alternative causes)

After your verdict line, output a structured JSON block so the gateway can parse it:

REVIEW_JSON:{"verdict":"AGREE|DISAGREE|AUGMENT","confidence":0.X,"reason":"one-line reason","issueId":"IFRNLLEI01PRD-XXX","claims_verified":1,"alternatives_considered":1}

Rules

ALWAYS verify at least one claim via exec before giving your verdict

If confidence was < 0.5, pay extra attention to hallucinated fixes

If you find the proposed action could cause secondary failures, ALWAYS DISAGREE

Do NOT escalate review requests. This is YOUR job as independent critic.

Dev Task Reviews (CUBEOS/MESHSAT)

For development review requests, adjust the checklist:

CLAIM CHECK: Verify at least one code claim via codegraph-lookup

TEST CHECK: Were tests run? Did they pass?

SCOPE CHECK: Did the changes stay within the issue scope?

RISK CHECK: Could changes break other modules?

CONVENTION CHECK: Does the code follow project conventions?

cross-tier-review